[systemd-devel] Is there a reason to run systemd Units with root access?

[Reindl Harald]

Am 10.07.2017 um 10:49 schrieb Lennart Poettering:
> On Tue, 04.07.17 20:33, Mariusz Wojcik (M6Wojcik at outlook.com) wrote:
> 
>> Hi,
>>
>> I’m just asking because of the latest “not-a-bug” [1]. As far as I
>> know, there aren’t many services that need full root access (maybe
>> for getting a low port number). Except for that I don’t see many use
>> cases. Therefore, I think it would be useful to make the decision
>> for root access more explicit, e.g. User=root is needed to start
>> units as root. Also I don’t think it is a sane default is to start
>> any unit as root when there is no valid User property. Even the
>> security of systemd would benefit because it would save people from
>> accidentally running services as root.
> 
> Well, UNIX system services traditionally expect to be invoked as "root",
> and then drop privs on their own, if they are well written, and
> systemd was created to run UNIX system services, hence the default.
> 
> But yeah I think today it would be better for services to just let
> systemd drop privs for them wherever possible. But it's hard to get
> that into people's heads, and it needs to be done on a per-service
> basis, so that the right user is used, and the right execution
> parameters (for example ambient caps) are passed otherwise.

it's not only about "get into people's heads"

it just don't make any sense for services like a webserver which needs 
to read certificate private keys but the user after drop privileges 
should not be able to read that files in case someone manages to execute 
code (which is not that hard when scripting langauges with commands like 
exec are part of the game)

the same when you read configurations containing sensible passwords, you 
do that before drop privileges and yes read memory with random executed 
coide is way harder than a file with a known path