Am 10.07.2017 um 10:49 schrieb Lennart Poettering:
On Tue, 04.07.17 20:33, Mariusz Wojcik (m6woj...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
