future of at_console

[Lennart Poettering]

On Thu, 06.08.09 05:29, Michael Biebl (mbiebl at gmail.com) wrote:

> 
> 2009/8/6 Lennart Poettering <mzqohf at 0pointer.de>:
> > Heya!
> >
> > So, what's the plan for at_console in D-Bus?
> >
> > There are two options:
> >
> > 1) deprecate it and get rid of it because it was a bad idea, and this
> > should really be happening in polkit not in dbus itself. I'd be
> > willing to prep a patch for that, which sets at_console for all users
> > to FALSE and prints a warning if someone still uses that in the XML
> > config files.
> >
> > 2) Keep it but replace the dreaded pam_atconsole /var/run/console
> > checking mess we still have there with a tiny bit of code that
> > actually reads the ckit database. We don't need to maintain that
> > database twice and this would allow us to get fully rid of
> > pam_atconsole. I'd be wiling to prep a patch for this, too.
> >
> 
> 3.) Keep support for at_console in D-Bus. Write pam_console compatible
> tag files using a small session.d script in ConsoleKit [1] as we use
> in Debian/Ubuntu. This still allows you to get rid of pam_console and
> requires minimal effort.

I am aware of that script, Suse has another one of those. Very similar
but sucks, too.

> There seem to be quite a few (smaller) D-Bus services where linking
> against libpolkit would be a bit heavy weight and the coarse grained
> at_console policy is sufficient. So imho it would make sense to keep
> support for it.

I believe this would be the worst solution for a couple of reasons:

The whole idea of Polkit is to unify policy decisions and the database
they are stored in. Hardcoding policy checks by using the current
at_console directory is hence counterproductive, because it cannot be
controlled by the administrator, nor manipluated centrally on the
network, has no centralized UI, no integrated documentation system and
so on, and so on. Using at_console's directory usually means either
hardcoding policy or duplicateing policy languages.

Also, I'd argue that a policy of "every locally logged in user" is
just bogus. If it all it needs to be "user actvie on this console" or
something suchlike. at_console can only do the former. Polkit can do
both (and a lot of other mechanisms too).

Thirdly, I never bought into "heavy-weight" vs "light-weight"
arguments. Really, this is nonsense. The new polkit just requires you
to issue a single (i.e. ONE!) D-Bus call for checking
authentication. This is trivial.

Fourthly: it requires us to maintain the database twice. Which by
itself is already ugly, but also sucks because the two databases
cannot be updated in one atomic step, but need to be updated
one after the other, opening the door for races and other messes.

Also, please explain which "quite a few (smaller) D-Bus services" you
are referring too. I mean, if someone already uses D-Bus it should be
trivial to add that single call into polkit for authorization.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4