Am 04.07.2017 um 20:39 schrieb Zbigniew Jędrzejewski-Szmek:
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.
and this is simply *not true* until on each and every system you can't
create a user with that name, as long it is not rejected it is valid and
systemd is hardly the authoritiy to redefine it
Essentially, User=0day is the same as Usre=0day and the same as User="my name is
pretty!".
which is terrible
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.
yes
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.
frankly a new option on the left side is a completly different thing
than a invalid value - just silently continue with invalid values of
existing options is playing a danergous game in a crucial component like
systemd
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
when the value on the right side is invalid you have to fail with a
clear error message instead fire up something with undefined behavior,
in general but especially when it comes to security relevant things
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
