future of at_console

[Marcel Holtmann]

Hi Kay,

> >> 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.
> 
> Well, the whole point is not to have two authoritative databases, not
> so much to get rid of of pam_console.
> 
> The entire concept of at_console at the D-Bus level is pretty flawed.
> In most cases you really only want the active session and not some
> rather dumb "it's logged in" state, so I still think if it's possible
> we should kill that thing.
> 
> Care to provide a list of the "quite a few" services so we can take a
> look at them who really might need that.

we would have BlueZ that has currently no concept of PolicyKit support
at all and uses at_console. However that could be fixed if it would be
the only thing standing in the way for the removal.

Regards

Marcel