[systemd-devel] Parallel startup with sockets and without killing the machine?

[Lennart Poettering]

On Tue, 10.05.11 09:25, Scott James Remnant (scott at netsplit.com) wrote:

> On Tue, May 10, 2011 at 7:41 AM, Gustavo Sverzut Barbieri <
> barbieri at profusion.mobi> wrote:
> 
> > I'm not following all the user-session discussion, but AFAIU this
> > management will be done by the same code, but not same process (it's not
> > PID1). PAM (or another entity that has a role in the login/logout) will talk
> > to systemd (PID1) and ask for a new service to be started to handle this
> > user-session. This will still be the same code, but of course on the user
> > context and not handle things like actual reboot/halt of the machine,
> > mounting system filesystems. But again, I'm not following it closely and I
> > might be wrong here.
> >
> That's a shame. Having it as a separate process would mean the user session
> would be started all at once in one go at the end of the boot, rather than
> with the rest of the boot :-(

We have considered doing all of this in the same process, however
ultimiately stepped away from it for security reasons. Adopting a
PID1-for-everything scheme also means that you need to add a fairly
complex authorization and credentials system to systemd, because you
need to validate every single bus call and other operation and map it to
a specific user context.

Since the kernel and D-Bus are fairly good at doing access control and
privilege separation between users we hence decided to make the best of
it in systemd and went for the one-systemd-for-each-user scheme.

Note that you need to delay execution of user code after the base system
is set up anyway, in order to ensure that the right perms are set on the
volatile and other directories. That means having a single transaction
for both user and system services effectively wins you very little.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.