previously on this list Jonathan Dowland contributed: > > Couldn't they just be ignored not to mention already having existing or > > far more functional and robust *options* that work with any init system. > > A cursory glance at the example above… > > > > PrivateTmp=yes > > > InaccessibleDirectories=/home > > …would suggest that simply ignoring such things could be a major > security concern. So, no. >
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. > > and on another matter I personally much prefer a setcap (again or other > > options like RBAC) shell line to > > > > CapabilityBoundingSet=CAP_SYS_TIME > > Presumably your preference is not purely down to syntax. What is it > down to? For something that is as long and no more descriptive than the shell it replaces it is simply adding obfuscation that fails to teach anything useful to users for use in other contexts and doesn't have a man page which like so often on Linux needs improving for setcap but that is of no importance to the better practice of empowering users who may become the next generation of devs. > > No it isn't and has been argued over not long ago, so as I have been > > requested to and am now trying (even harder) it would be good if we > > could keep the S/N ratio down. > I'm afraid you're failing with sentences such as the above. True and certainly could have been worded more tactfully. I was referring to the thread from the 27th Aug entitled Custom Reload command/signal in upstart -- _______________________________________________________________________ '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/818151.66282...@smtp124.mail.ir2.yahoo.com
