[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 6 Jul 2017 07:28:16 -0600
From: Leonid Isaev <leonid.isaev@...a.colorado.edu>
To: oss-security@...ts.openwall.com
Subject: Re: systemd fails to parse user that should run
service
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. In contrast, init scripts are specific to a distibution
(would you just run init scripts from Debian on a CentOS or ArchLinux?)
For example, if I maintain a backup script that drops privileges via su(1), I
can use the wonderful systemD unit syntax, specify User=xxx and have my package
manager install that user in post_install. The problem is that my new and shiny
script won't work as intended on old systemD versions which silently ignore
User= directive. This situation is far worse than a simple failure to properly
parse User= config string that seems to so much excite ppl, as it obsoletes
the User= directive and perhaps others too. I'm far from sysadmin culture, but
is this called "sh*t hitting the fan"?
So, the lesson for all developers would be to rely on systemD features as
LITTLE as possible and do all important privilege stuff inside their software.
SystemD units should therefore only contain Exec{Start,Stop,Restart}=.
Cheers,
--
Leonid Isaev
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.
