[systemd-devel] Github systemd issue 6237

Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl
Tue Jul 4 18:39:15 UTC 2017


On Tue, Jul 04, 2017 at 07:36:02PM +0200, Reindl Harald wrote:
> 
> 
> Am 04.07.2017 um 19:21 schrieb Zbigniew Jędrzejewski-Szmek:
> >>My question is:
> >>
> >>Is this a bug with a BZ against rhel/centos7 (as my understanding is that
> >>this affects EL7 too)?
> >>
> >>If there is no BZ and based on the wording of the second to last comment
> >>by poettering, will this be fixed/changed in a future update?
> >>
> >>I personally see this as a security issue and thus as a bug.
> >If you need root permissions to create a unit, then it's not a
> >security issue. An annoyance at most.
> >(You do know that you're not supposed to copy&paste random stuff
> >from the internet as root, right?)
> 
> no - when there is a "User=" statement in the unitfile it's a strong
> reason to refuse start that unit if that user don't exist instead
> silently fall back to root and casting "0day" to a int 0 is just a
> sloppy implementation with no good reason

It doesn't evaluate "0day" as 0 or cast anything, it (as designed)
finds that "0day" is not match the pattern for a valid user name and
rejects the whole line.

Essentially, User=0day is the same as Usre=0day and the same as User="my name is pretty!".

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.

When new configuration options are added, the same unit file can
almost always be used with older systemd, and it'll just warn & ignore
the parts it doesn't understand. Similarly, various configuration
options might be unavailable on some architectures and with some
compilation options. The current behaviour of warn&ignore provides
for "soft degradation" in those cases.

To do this properly, we would need to figure out which options are
a) important enough, b) supported on all compilation variants and
architectures, and then add a generic mechanism to make errors in
them fatal.

Zbyszek


More information about the systemd-devel mailing list