Date: Thu, 6 Jul 2017 22:12:58 +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 13:27:53 -0600, Leonid Isaev wrote: > On Thu, Jul 06, 2017 at 03:02:07PM +0100, Simon McVittie wrote: > > > 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. > > OK, but then there is no excuse to silently ignore any kind of error in > User=. If systemd can not start unit as a specified user, it must fail it, just > like ExecStart: if the command specified there is not found I agree, and this was already done for usernames that were parsed as syntactically valid (User=whatever on a system where there is no 'whatever' user). The issue here was a combination of two things: * Usernames that were considered to be syntactically invalid went through the error-handling code path for unknown configuration items (ignored on the assumption that they are some future extension point, rather than causing failure). https://github.com/systemd/systemd/pull/6300 has now been proposed to change this, for User and a few other key directives. This is basically Felipe's suggestion from the systemd-devel thread. * What can be in a valid username is Unix folklore rather than a standard (POSIX defines a subset of usernames that are portable, but does not forbid systems from additionally accepting non-portable usernames, and in practice they do), and systemd's idea of what is a syntactically valid username accepts considerably fewer usernames than common useradd implementations (indeed it doesn't accept all POSIX portable user names either). User="syntax error!" or User=0day (which are treated as equivalently invalid, and go through the same code paths) were never "silently ignored": they were ignored rather noisily, with multiple log messages every time the unit in question was started. > I thought the current behavior of ignoring some syntax "mistakes" was put in > place by design because units have to be backwards copatible with older systemd > versions. Yes, it is: if some future systemd version adds a new directive, perhaps AnonymizeMachineID or StackSizeMax or something, it is a deliberate design choice that current systemd versions will log a warning and ignore it. This lets upstreams be more aggressive about enabling new features (many of which are non-critical but good-to-have security hardening for services), without necessarily having to wait for the systemd version that introduced those features to become available in the oldest, most stable or most "enterprise" distribution that they target. This is a trade-off, and both possibilities (reject unknown directives, or warn and ignore) are plausible design choices: which one is better is a matter of opinion. The systemd developers chose to treat the advantages of the warn-and-ignore approach as larger than its disadvantages. In general the same is true for the *values* of directives: systemd needs to choose something to do about known directives with values that it cannot understand, and in general they are ignored with a warning on the assumption that the new value is something that might have been understood by a newer version of systemd. That isn't appropriate for all directives, hence <https://github.com/systemd/systemd/pull/6300>. 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.