Blackberry device permissions

Chris Frey cdfrey at foursquare.net
Tue Jun 30 02:28:12 PDT 2009


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?) ->
		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.

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.

Otherwise, HAL is well behaved under Fedora 11 for testing.  Its policy and
fdi cache gets updated automatically after manual editing and replugging
the device.  All the way through this debugging process, I wondered if I
had to reboot or restart the hald service, but thankfully this was not
the case.

I'm no hal expert, but I hope this helps someone in the future.

Thanks again,
- Chris



More information about the devkit-devel mailing list