|
Message-ID: <20170706132816.GA3056@takahe.colorado.edu> 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.