On Tue, 2011-08-23 at 21:33 +0200, Lennart Poettering wrote: > On Tue, 23.08.11 17:48, JB (jb.1234abcd@xxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
