Default services enabled

[Simo Sorce]

On Tue, 2011-08-23 at 21:33 +0200, Lennart Poettering wrote:
> On Tue, 23.08.11 17:48, JB (jb.1234abcd at gmail.com) wrote:
> 
> > Systemd and security - an example # 2 of an attack venue.
> > ---------------------------------------------------------
> > The above is dangerous as a design idea to achieve "parallelization" of
> > services.
> > Let's assume that service A is a dependency for service B (and others).
> > After A's on-demand socket has been put "on hold" (blocking), the A may die
> > or lock up for any reason, that is never to come up again by itself as
> > an active service.
> > That means there is a system lock-up possibility here while B (and others) are
> > "on hold" too (waiting for A to be unblocked), and wait ..., and wait
> > ...
> 
> A dep loop is a dep loop is a dep loop. Whether systemd is used or not
> does not change this. Services with ordering loops are borked services
> and won't work. If an service A synchronously calls into service B and
> the service B synchronously calls into A you'll have a dealock. No news
> there...

No Lennart, this is not entirely correct.

If you have a daemon that can optionally leverage the services of
another but do not need to fail if the former is not available then even
a synchronous call is not necessarily a deadlock, for the simple reason
that w/o a socket the synchronous call will just return an error
immediately and the process will proceed on its way.

If instead the socket is listening but not really accepting and
processing requests, then yes, you can have a deadlock.

So socket activation is not transparent by any means and needs to be
handled very carefully in terms of circular dependencies as they may
actually introduce deadlocks that weren't there before.

The issue is particularly difficult to handle when connections are made
unbeknown to the application, for example in a pam or nss module (this
is one of the reasons I don't think SSSD should use socket activation,
as the clients are supposed to immediately fail and return nothing
rather then letting application wait for minutes like it happens with
nss_ldap).

Of course this can be handled by changing libraries and daemons so that
they timeout or handle the circular dependency differently, but claiming
there are no potential additional issues in a system so complex as a
modern Linux distribution is not fair.


Simo.

-- 
Simo Sorce * Red Hat, Inc * New York