Kevin Chadwick <ma1l1i...@yahoo.co.uk> writes: > Well I meant that they would be used by systemd and ignored likely > noisily by default by others. However this really should be the job of > the service in any case as depending on a third party service for > security that isn't extra such as potentially PrivateTmp that apache/php > may need (likely in a /var chroot in this case though) is asking for > trouble.
No, it should *not* be the job of each service to reimplement tricky security measures. They should be implemented in one place or a small number of competing places that are thoroughly tested and that have been examined with lots of eyeballs, and then reused by everyone else rather than having them attempt to roll their own strategies. This applies to several features in upstart and systemd. Socket activation is another excellent example. Anyone care to guess how much badly-written code to handle listening to a network socket currently exists in the archive? How much of it causes the daemon to fork and exit in the parent before it's actually listening to the network, thus breaking boot ordering? And that's despite the existence of the inet superserver, which hopefully a lot of packages are using rather than rolling their own. It's one thing to avoid a monoculture. It's quite another to chase avoidance of a monoculture into a nasty case of Not Invented Here. Services should not be responsible for doing things that can be done properly by well-tested and robust system services for exactly the same reason that services should not use their own implementation of AES and should instead rely on one of the several robust and well-tested crypto libraries. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vc0eqo23....@windlord.stanford.edu