oss-sec mailing list archives
Re: systemd fails to parse user that should run service
From: Simon McVittie <smcv () debian org>
Date: Thu, 6 Jul 2017 22:12:58 +0100
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
Current thread:
- Re: systemd fails to parse user that should run service, (continued)
- Re: systemd fails to parse user that should run service Kristian Fiskerstrand (Jul 05)
- Re: systemd fails to parse user that should run service Simon McVittie (Jul 05)
- Re: systemd fails to parse user that should run service Ben Tasker (Jul 06)
- Re: systemd fails to parse user that should run service Perry E. Metzger (Jul 05)
- Re: systemd fails to parse user that should run service Robert Scheck (Jul 05)
- Re: systemd fails to parse user that should run service Patrick J. Volkerding (Jul 06)
- Re: systemd fails to parse user that should run service Simon McVittie (Jul 06)
- Re: systemd fails to parse user that should run service Leonid Isaev (Jul 06)
- Re: systemd fails to parse user that should run service Simon McVittie (Jul 06)
- Re: systemd fails to parse user that should run service Leonid Isaev (Jul 06)
- Re: systemd fails to parse user that should run service Simon McVittie (Jul 06)
- Re: systemd fails to parse user that should run service Martin Steigerwald (Jul 06)
- Re: systemd fails to parse user that should run service Martin Steigerwald (Jul 06)