[systemd-devel] Github systemd issue 6237

[Michael Chapman]

On Thu, 6 Jul 2017, Felipe Sateler wrote:
> On Tue, 04 Jul 2017 18:39:15 +0000, Zbigniew Jędrzejewski-Szmek wrote:
>
>> Essentially, User=0day is the same as Usre=0day and the same as User="my
>> name is pretty!".
>
> I think this is the root of the disagreement. Systemd tries to allow
> units written for version X to run on versions earlier than X. I think
> that is a good idea, and I don't think anyone is claiming it isn't. Which
> is why invalid lvalues should be warned about but ignored, and I don't
> think anyone is disputing this.
>
> OTOH, invalid rvalues are a different thing: systemd recognizes the
> setting it is trying to apply, but it can't. I think the argument that
> systemd should fail the unit here is strong. Or at least for a certain
> subset of the settings.
>
>>
>> I do agree that we might want to completely reject unit files when some
>> crucial lines fail to parse, for example ExecStart or WorkingDirectory
>> or User, but it's not as obvious as one would think at first.
>
> Indeed. Marking invalid rvalues as failing the unit does bring backwards-
> compatibility issues. Suppose systemd X+1 adds a new @ shortcut for
> SystemCallFilter: should systemd X fail a unit that uses it? The problem
> would be the same as with User=0day, as the service would run with higher
> privileges than expected.
>
> A possibility would be to make systemd have its preemptive validations[1]
> be fatal. Setting `User=idontexist` would then be equal to `User=whoa!`,
> because neither of the usernames (should) exist.
>
> [1] That is, validations for things it does not control itself. systemd
> does not control the username format, the uid range, allowed directories,
> etc, but rather validates against an external standard. That is, assume
> that things that don't validate would fail at application time with a non-
> ignorable EINVAL. This is different from things it defines itself, such
> as @ settings for SystemCallFilter.

Note that the semantic validations you're talking about here -- things 
like "does the user exist?" -- are _not_ preemptive. They are fatal: the 
child process will exit unsuccessfully as the command is executed if the 
settings will not be able to be applied.

User=0day fails a syntactic validation, not a semantic validation. systemd 
never even checks to see whether the user exists when the unit is loaded. 
And nor should it! The user must be allowed to not exist at unit-load 
time.

Contrary to some of the comments in this thread, there is no point in 
systemd's operation where it goes "oh look, that user actually exists but 
I'm going to pretend it doesn't".