[systemd-devel] Github systemd issue 6237

Michael Chapman mike at very.puzzling.org
Wed Jul 5 10:10:15 UTC 2017


On Wed, 5 Jul 2017, Colin Guthrie wrote:
> Reindl Harald wrote on 04/07/17 19:50:
>>> When new configuration options are added, the same unit file can
>>> almost always be used with older systemd, and it'll just warn & ignore
>>> the parts it doesn't understand. Similarly, various configuration
>>> options might be unavailable on some architectures and with some
>>> compilation options. The current behaviour of warn&ignore provides
>>> for "soft degradation" in those cases.
>>
>> frankly a new option on the left side is a completly different thing
>> than a invalid value - just silently continue with invalid values of
>> existing options is playing a danergous game in a crucial component like
>> systemd
>
> It's a rare thing :p but I have to agree with you here!
>
> I'd say if "User=-notauser" then silently failing and using root is
> acceptable as per the usual semantics of "- prefix suppresses errors",
> but "User=notauser" should fail IMO.

I'm pretty sure you'll find that it does. Specifically, it will fail when 
the child process for the command being executed attempts to map the 
username to a UID.

The issue being discussed here is that systemd considers "0day" to be 
_syntactically_ invalid for a username. See the valid_user_group_name() 
function in basic/user-util.c.

(In my opinion, we shouldn't be this restrictive. POSIX permits usernames 
that start with a digit, and just because certain other utilities can't 
deal with them doesn't mean systemd need forbid them.)

So the directive fails the syntactic check for User=, just like 
Zbigniew's example of User="my name is pretty!".

I do think we ought to have a list of "critical" directives, such that any 
syntactic error in those directives causes the unit load state to be 
"error". For better or worse, people simply don't look at logs, so 
they'll never notice that important directives in their units are being 
ignored.


More information about the systemd-devel mailing list