implementing an OLPC authentication agent

Daniel Drake dsd at laptop.org
Wed Jul 2 12:07:09 PDT 2008


Hi,

I'm working on updating OLPC's XO platform from Fedora 7 to Fedora 9.
This involves the addition/integration of ConsoleKit + PolicyKit into
HAL and other such components. The Sugar UI uses HAL to request
shutdown/reboot/USB mount/...

Using ck-xinit-session we have successfully made ConsoleKit "aware" of
sugar, and under a normal boot we can shutdown the system (the default
HAL policy says that the active user can shutdown).

However, if we hit ctrl+alt+F1 and login on the console, a 2nd session
is created, and we can no longer shutdown through sugar because the HAL
policy has the auth_admin requirement for the active user for shutting
down when multiple sessions are active (sugar doesn't interpret the
response and just silently fails to shut down). We'd like to fix this so
that shutting down from sugar works regardless of other sessions.

The first option is to just modify the policies that are installed by
HAL, or modify the PolicyKit conf file to override the policies. But
those files are owned by packages so (I think) we would have to create
an OLPC-3 branch of those packages just to install the alternative
config file. Our main Fedora guy is working hard to cut down the number
of packages we have to branch, so I'm also considering other options.

The second option is to implement an OLPC-specific simple authentication
agent. When sugar receives the dbus exception because it couldn't shut
down, it can interpret it and talk to an OLPC authentication agent for
authorisation. The OLPC auth agent would authorise all auth_admin
requests from the "olpc" user and deny everything else (no UI or
anything, just a straightforward accept/deny). Once sugar has obtained
authorisation it would then retry the shutdown and succeed.

In your opinion(s), which of the above is the most sensible?
I guess the 2nd option is a little nicer in that it is generic. There
may be an increasing number of policies we have to override the
auth_admin requirement for in future, and the 2nd option covers all of
them.

Thanks,
Daniel




More information about the polkit-devel mailing list