[systemd-devel] [RFC] merging the rest of CK into systemd
Lennart Poettering
lennart at poettering.net
Tue May 3 08:47:56 PDT 2011
On Tue, 03.05.11 10:12, Bill Nottingham (notting at redhat.com) wrote:
>
> Lennart Poettering (lennart at poettering.net) said:
> > Heya,
> >
> > here's a little document Kay and I put together outlining our rough
> > plans for systemd for the next Fedora cycle:
> >
> > https://docs.google.com/document/d/1_ev4f0gwBuvs6SH_N8fN5LO4LV3sbwtJsLq52F_wwpU/edit?hl=en&authkey=CObM_7UI
> >
> > It mostly focusses on cleaning up seat and login management for users,
> > i.e. the first big steps in bringing systemd to user sessions. On the
> > way want to fix multi-seat support properly and running services outside
> > of a session, and we will get rid of CK.
> >
> > The good news for embeded folks: all of this will be implemented in a
> > tiny new dbus service "systemd-logind", which can easily be removed for
> > minimal setups, when tracking unprivileged user logins is unnecessary.
> >
> > Anway, we post this here as RFC, and to give you folks an idea what
> > we'll do next.
>
> ...
> There will be no public CK database. However we will provide a tiny library
> (drop-in or .so) which allows NM, PK and D-Bus query whether a PID or user
> is currently on an active sesssion without involving D-Bus, as fast path for
> auth checks
> ...
>
> It would be nice if the ck-for-admins binaries still have an analog
> (ck-list-sessions, etc.).
Yes we'll try to keep them around, with exceptions (i.e. instead of
ck-history people should just use last/lastlog and similar commands,
even they are slightly less powerful).
>
> ...
> udev-acl will move into this dbus service
> ...
>
> I would hope that the interface for the udev rules themselves is not going
> to change, merely the mechanism that's used to apply the ACLs?
Exactly. The tag will stay the same, just the code that interprets it
will move.
> ...
> CK's shutdown/reboot handling moves into a tiny bus service ...
> ...
>
> Would the shutdown/reboot/halt binaries remain separate from this servce?
Yes, I would assume so, but now you got me thinking. It might make sense
to talk to this service, for example when UID != 0 or so. Dunno. We'll
see.
Lennart
--
Lennart Poettering - Red Hat, Inc.
More information about the systemd-devel
mailing list