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"._______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
