previously on this list Russ Allbery contributed: > > 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.
Well I completely disagree, yes they should use or atleast reference good well audited shared references but code for security should be tailored to the almost always simpler job at hand otherwise you will always be less secure and doing so actually increases eyeballs on the code. Bringing it back to PrivateTmp what you are certainly doing is adding complexity about whether systemd is running and has done this or not and for what good reason, which then raises questions and less audited code for all the other use cases. If you analyse the really secure packages on the two sides guess which has the extremely low vulnerability track record. You may also stop the dev from providing extra layers of security because the generalised behaviour is out of their domain and they don't need to think about it. If on the other hand you are talking about making it easier for some programmers who are not willing to take the time to be careful then you may have a point for backing things like polkit but I would say they should stick to unpriviledged user operations then as this generalisation and misunderstanding/unfamiliarity does and will lead to more exploits and they shouldn't be doing anything risky as root if they are not willing to be careful anyway. And no it isn't exactly the same reason as well defined libraries with very specific low level jobs at all, often even standard c libraries functions are the right tool but sometimes you take part of it and make something more correct. -- _______________________________________________________________________ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd _______________________________________________________________________ -- 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/68396.31640...@smtp104.mail.ir2.yahoo.com