implementing an OLPC authentication agent

[Matthias Clasen]

On Wed, Jul 2, 2008 at 3:07 PM, Daniel Drake <dsd at laptop.org> wrote:
> 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.

Another option might be to split the policy off as a separate (sub)
package that you could then replace by a customized olpc policy. But
having the outlined agent sounds like a good idea, too.