No subject

special socket.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hald runs through =
fdi/information/10freedesktop/* ->
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hald runs through =
fdi/policy/10osvendor/* ->
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In my case, policy=
/.../19-blackberry-acl.fdi
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0must be seen befor=
e policy/.../20-acl-management.fdi,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0since 19-blackberr=
y-acl.fdi adds "access_control"
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to info.capabiliti=
es, which 20-acl-management.fdi uses
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as a search term. =
=C2=A0For each access_control entry, it adds:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0info.callouts.add =3D hal-acl-tool --add-device
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0info.callouts.remove =3D hal-acl-tool --remove-device
>
> And of course, hal-acl-tool is the missing link that I couldn't find for
> so long. =C2=A0Just 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. =C2=A0For 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. =C2=A0For =
example,
> "org.freedesktop.hal.device-access.scanner". =C2=A0But this long name nev=
er seems
> to be used in other config files. =C2=A0For example, 19-blackberry-acl.fd=
i merely
> sets access_control.type to "scanner" like this:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0<merge key=3D"access_control.type" type=3D"str=
ing">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. =C2=A0Under 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=3Dyes" with or without --daemon=3Dno/--use-syslog
from a terminal for testing.

--
Dan