To wrap up this subthread, I want to state clearly for the record that the answers that have been given here have addressed my concerns about the raciness of systemd socket activation. It appears that the state of the art is rather substantially improved since the last time I had looked at Fedora's systemd deployment - I suspect as a result of continued feature development in systemd upstream that closed the gaps I'd previously identified. Whatever the cause, while I don't believe that socket-based activation is strictly a necessary feature for the next generation init solution, I am satisfied that the systemd implementation of it isn't actively detrimental to the reliability or security of our systems. (With my upstream hat, I am also convinced that further development is warranted on upstart's socket activation implementation, to bring it to feature parity with systemd's.) On Sun, Dec 29, 2013 at 10:37:10AM -0800, Russ Allbery wrote: > > Indeed, when I looked at this problem on an earlier version of Fedora, I > > found what I believe to be a latent security problem in the cups units, > > because it was nondeterministic whether the service would start with > > sockets passed from systemd, or a different set of sockets as defined in > > the cups config! > Did the cups service unit explicitly depend on its socket unit? At this point, I certainly can't remember - bearing in mind that at the time I was doing a comparative analysis for purposes of improving upstart, not to evaluate systemd for adoption, so having identified a critical problem I didn't dig very much farther to determine if this was fixable within the constraints of systemd's dependency system. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature