Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Jul 2017 15:02:07 +0100
From: Simon McVittie <>
Subject: Re: systemd fails to parse user that should run

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.


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.