[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

Kevin Chadwick <ma1l1ists@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

Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Reply to: