On Tue, Jun 30, 2009 at 2:28 AM, Chris Frey<[email protected]> wrote: > On Tue, Jun 30, 2009 at 03:06:12AM -0400, Chris Frey wrote: >> On Tue, Jun 30, 2009 at 08:21:37AM +0200, Martin Pitt wrote: >> > > But I don't see any of his handling in the new udev rules. >> > >> > Installed udev: >> > /lib/udev/rules.d/70-acl.rules >> > /lib/udev/udev-acl (helper program) >> > >> > Source tree: >> > extras/udev-acl/ >> >> Thank you! This is starting to make sense for the New Way. >> >> Would I be correct in assuming that there is a similar helper program >> somewhere in the HAL Way? Or does HAL do the ACL stuff internally? > > Thank you everyone for your help. I have it working now, and just for > reference in case others stumble across this thread and are lost in a > sea of XML and udev, here's the summary as I understand it, on > Fedora 11: > > > Device gets plugged in -> > udev sees it, runs its own rules -> > udev rules default to 0664 for libusb devices > > hald also sees device (via udev? its own kernel hooks?) ->
From udev. See /etc/udev/rules.d/90-hal.rules, which pokes HAL over a special socket. > hald runs through fdi/information/10freedesktop/* -> > hald runs through fdi/policy/10osvendor/* -> > > > In my case, policy/.../19-blackberry-acl.fdi > must be seen before policy/.../20-acl-management.fdi, > since 19-blackberry-acl.fdi adds "access_control" > to info.capabilities, which 20-acl-management.fdi uses > as a search term. For each access_control entry, it adds: > > info.callouts.add = hal-acl-tool --add-device > info.callouts.remove = hal-acl-tool --remove-device > > And of course, hal-acl-tool is the missing link that I couldn't find for > so long. Just like udev-acl (see above) is the link for the new > architecture. > > hal-acl-tool is a C program which makes use of ConsoleKit and PolicyKit > libraries to determine who to give rights to and whether to give rights, > respectively. For this to work, you need to have an access_control.type > value in 19-blackberry-acl.fdi matching an action in PolicyKit's > /usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy > config file. > > This policy file names the action with a fully qualified name. For example, > "org.freedesktop.hal.device-access.scanner". But this long name never seems > to be used in other config files. For example, 19-blackberry-acl.fdi merely > sets access_control.type to "scanner" like this: > > <merge key="access_control.type" type="string">scanner</merge> > > (Yes, I plan to change this to "pda" which makes more sense here.) > > One of the things that tripped me up was that I had 19-blackberry-acl.fdi > under fdi/policy/20thirdparty. Under Fedora 11, this added > "access_control" to info.capabilities, but actual processing must have > come after 10osvendor/20-acl-management.fdi somehow, because the callouts > never got added. Since 10osvendor comes before 20thirdparty, HAL will scan there first. Seems to be an unfortunate placement of 20-acl-management.fdi, but maybe it was intentional that only the vendor should be deciding who gets to poke the ACLs. > One thing I really wished for was more logging from hal... I wished it > would tell me why it didn't change permissions somewhere... I thought it > was a condition in PolicyKit denying me access somewhere, not realizing > that hal-acl-tool was not getting run at all... and not knowing that it > even existed. I don't know if it will help a ton for ACLs, but you can stop hald and then run "hald --verbose=yes" with or without --daemon=no/--use-syslog from a terminal for testing. -- Dan _______________________________________________ devkit-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/devkit-devel
