[systemd-devel] Github systemd issue 6237

[Reindl Harald]

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