[systemd-devel] Github systemd issue 6237

[Felipe Sateler]

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.


-- 
Saludos,
Felipe Sateler