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