[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
