User=0day considered harmful in systemd
User=0day considered harmful in systemd
Posted Jul 14, 2017 10:47 UTC (Fri) by dskoll (subscriber, #1630)In reply to: User=0day considered harmful in systemd by drag
Parent article: User=0day considered harmful in systemd
I cannot imagine a scenario in which "fall back to root" would be desirable. It seems to me intentionally abetting that sort of behaviour is verging on the criminal.
Posted Jul 14, 2017 15:17 UTC (Fri)
by drag (guest, #31333)
[Link] (2 responses)
Maybe it should be something that should be fixed, but it'll end up breaking things if it is.
Posted Jul 14, 2017 15:31 UTC (Fri)
by mchapman (subscriber, #66589)
[Link] (1 responses)
If you're talking about initscripts, I think you'll be hard-pressed to find an initscript that tries to run a program as an unprivileged user, but if that fails continues to run that program instead as root. I really don't think this has ever been "the way things have been done".
> Systemd isn't responsible for introducing this behavior.
systemd doesn't even have that behaviour. There is no "fallback to root" logic in systemd.
What systemd did have was a situation where the User= directive was ignored if it could not be parsed. I can understand why people keep mistaking this as some kind of "fallback" -- it certainly looks and acts like one, especially if you don't look at your logs. But it has nothing to do with whether a particular user exists on the system or not. If the User= directive is successfully parsed but the user it identifies does not exist on the system, systemd will fail the unit when it attempts to run a command for it.
Anyway, "0day" was (and still is) one of the unparsable values for this directive, however since a recent commit [1] this parse error now results in the unit failing to load rather than the directive being ignored.
[1] https://github.com/systemd/systemd/commit/bb28e68477a3a39...
Posted Jul 14, 2017 16:57 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link]
Question the first:
I would think however that a local admin may want to use their discretion and local system knowledge to treat specific supplemental directives as sensitive and have the units fail to start if the directives fail to parse to avoid unexpected behavior.
I would also naively think that distributors who are supplying unit files to end users might find it useful to use some automation and audit for parse errors on a much larger set of directives. Since these distributors generally set the compile options, they are in the best position to test to make sure supplemental directives outside the default set of sensitive directives fire correctly.
Question the second:
User=0day considered harmful in systemd
User=0day considered harmful in systemd
User=0day considered harmful in systemd
That seems reasonable. As a short hand I'll refer to this subclass as "sensitive directives"
Would it make sense to give local admins the ability to extend the set of sensitive directives with more directives of their choosing?
The commit comment refers to other supplemental directives that can't be guaranteed to parse correctly across all system configurations in the general case from a unit writer perspective.
What's the best practice for local admins/unit writers/distribution integrator to be notified of directive parse errors in the unit files on system? Is there a way to automatically audit the disabled/inactive units for these sorts of errors?
Question the third:
Should this be taken further and create a subclass of directives for local admins to populate which much be present and parse correctly in all units?