|
Message-ID: <20170706140207.ywcfdtsmmrh2dxmm@perpetual.pseudorandom.co.uk> Date: Thu, 6 Jul 2017 15:02:07 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: systemd fails to parse user that should run service On Thu, 06 Jul 2017 at 07:28:16 -0600, Leonid Isaev wrote: > On Thu, Jul 06, 2017 at 01:17:55PM +0100, Simon McVittie wrote: > > systemd units are analogous to LSB init scripts, > > which all start as root, and drop privileges internally if they want to. > > Hmm, no, no and once again no. SystemdD units are sold as something simple and > transparent, and hence *associated with a software they launch*, not a given > systemD/OS version. It is entirely possible that systemd units as distributed by upstream projects might assume features of systemd (>= some version), just like upstream projects might assume features of glibc (>= some version) or coreutils (>= some version) or bash (>= some version). systemd does not magically cause dependency relationships to go away. Some upstreams are very conservative in what dependencies they will accept, while others are quick to add dependencies on new things if they see an advantage. That doesn't mean the conservative projects have no dependencies at all. > The problem is that my new and shiny > script won't work as intended on old systemD versions which silently ignore > User= directive. I am not aware of any such version existing. The 2010 commit "first attempt at proper service/socket logic", which was 6 months before the release of systemd version 1 and was the first commit to introduce ExecStart, also introduced User. S
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.