You are not logged in.
Pages: 1
Hello everyone,
I am currently setting up my new Arch setup and one thing I never paid much attention to was the user/groups with which the .service / processes are running.
For example the ntp wiki page states that ntp should be run as ntp:ntp but the .service will run as root when enabled anyway.
So I am curious, which .service shouldn't run as root?
Examples that I am thinking of:
ntp
dnscrypt-proxy
mpd
Setup 1: Thinkpad T14s G3, 14" FHD - R7 6850U - 32GB RAM - 2TB Solidigm P44 Pro NVME
Setup 2: Thinkpad X1E G1, 15.6" FHD - i7-8850H - 32GB RAM - NVIDIA GTX 1050Ti - 2x 1TB Samsung 970 Pro NVME
Accessories: Filco Majestouch TKL MX-Brown Mini Otaku, Benq XL2420T (144Hz), Lo(w)gitech G400, Puretrak Talent, Sennheiser HD800S + Meier Daccord FF + Meier Classic FF
Offline
Did you already looked into
/usr/lib/systemd/system/ntpd.serviceand in the other units ? I think this will answer your question.
Also you could read https://wiki.archlinux.org/index.php/Systemd/User - which mentions mpd as example.
Last edited by ua4000 (2018-12-16 11:17:31)
Offline
Thanks but my question was not on "how to run it as user" but instead "what should be run as user".
Setup 1: Thinkpad T14s G3, 14" FHD - R7 6850U - 32GB RAM - 2TB Solidigm P44 Pro NVME
Setup 2: Thinkpad X1E G1, 15.6" FHD - i7-8850H - 32GB RAM - NVIDIA GTX 1050Ti - 2x 1TB Samsung 970 Pro NVME
Accessories: Filco Majestouch TKL MX-Brown Mini Otaku, Benq XL2420T (144Hz), Lo(w)gitech G400, Puretrak Talent, Sennheiser HD800S + Meier Daccord FF + Meier Classic FF
Offline
Only things that have to be.
Offline
I think there may be a confusion between which user a service's process runs as and which user enables the service. For example, ntpd.service does run as user 'ntp'. But to start or enable the service, you run systemctl as root. The ntp process also technically starts with root privileges, but quickly drops them switching to ntp. This starting as root and dropping privileges after initializing some resources is common to many services. Web servers, for example, generally need to start as root to bind low numbered ports (e.g. 80 for http) but then imediately after binding the port, they drop root privilege and run as a low-privilege user (sometimes even in their own chroot).
So what are you really trying to understand? How to write system daemons, how to write service files to start those daemons, or how to use systemctl to enable those service files?
Last edited by Trilby (2018-12-16 17:16:31)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Oh I didn't know that services will drop privileges.
I was just worried that I had several .services run as "root" and wondered if there is a general recommendation on what to force to be started as a different user.
Setup 1: Thinkpad T14s G3, 14" FHD - R7 6850U - 32GB RAM - 2TB Solidigm P44 Pro NVME
Setup 2: Thinkpad X1E G1, 15.6" FHD - i7-8850H - 32GB RAM - NVIDIA GTX 1050Ti - 2x 1TB Samsung 970 Pro NVME
Accessories: Filco Majestouch TKL MX-Brown Mini Otaku, Benq XL2420T (144Hz), Lo(w)gitech G400, Puretrak Talent, Sennheiser HD800S + Meier Daccord FF + Meier Classic FF
Offline
I was just worried that I had several .services run as "root"
A vast majority of services are intended to be started by systemd which does start them as root (or at least root access is needed to enable them, the service file can also specify a User= which drops privileges even earlier). The only exception are those that can be run under a systemd --user session. The potential to run these services as a user is clearly indicated in their respective wiki pages. So if not specified otherwise, when the wiki advises to start/enable a service, it means to do so as root.
Last edited by Trilby (2018-12-17 19:59:23)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Note: ntpd should be started as non-root (default in the Arch Linux package) before attempting to jail it in a chroot, since chroots are relatively useless at securing processes running as root.
I think you may have been confused by this line from Network_Time_Protocol_daemon. It does mention default in the Arch Linux package is to be started as none root.
If you changed the service to start as ntp:ntp rather than root it would not be able to adjust the clock or bind to port 123.
After ntpd has accessed the clock and opened its network sockets it will change its user and group to ntp due to the the -u option which the supplied usr/lib/systemd/system/ntpd.service uses.
Last edited by loqs (2018-12-17 21:25:27)
Offline
If you changed the service to start as ntp:ntp rather than root it would not be able to adjust the clock or bind to port 123.
The port could be granted via a systemd.socket(5) file, and CAP_SYS_TIME can be used to grant permissions to modify the hardware clock. Does ntp already use capabilities(7) to grant itself CAP_SYS_TIME before it drops its privileges down to the "ntp" user? If so, then I suspect one could already configure the service to start as non-root.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Yes ntpd uses CAP_SYS_TIME and is aware to preserve it across setuid.
https://github.com/ntp-project/ntp/blob … tpd.c#L623
uid = getuid();
if (uid && !HAVE_OPT( SAVECONFIGQUIT )) {
msyslog_term = TRUE;
msyslog(LOG_ERR,
"must be run as root, not uid %ld", (long)uid);
exit(1);
}Then there is https://serverfault.com/questions/47563 … -0123?rq=1 it needs to bind to a routeable interface or it will not talk to remote servers.
Last edited by loqs (2018-12-18 04:35:45)
Offline
The only exception are those that can be run under a systemd --user session. The potential to run these services as a user is clearly indicated in their respective wiki pages.
which is the case for mpd,
and this is why I mentioned this in my first post here :-)
Offline
Oh I didn't know that services will drop privileges.
Looking at /usr/lib/systemd/system/ntpd.service could have saved you the ??? :-)
Offline
Yes ntpd uses CAP_SYS_TIME and is aware to preserve it across setuid.
https://github.com/ntp-project/ntp/blob … tpd.c#L623
uid = getuid(); if (uid && !HAVE_OPT( SAVECONFIGQUIT )) { msyslog_term = TRUE; msyslog(LOG_ERR, "must be run as root, not uid %ld", (long)uid); exit(1); }
Interesting. I guess someone motivated to do so, could submit a feature request to upstream, requesting that it also check if it already has CAP_SYS_TIME && a bound port, and if so, skip the root check.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Utini wrote:Oh I didn't know that services will drop privileges.
Looking at /usr/lib/systemd/system/ntpd.service could have saved you the ??? :-)
You are right, how ever, I believed I had started the .service and ntpd was still run as root.
I now enabled the service again and checked.. after a reboot its run by ntp:ntp.. so everything is fine.
But then again, the main question wasn't just about ntp but in general:
Are there any .services that should explicity run as non-root but currently do not do it by default?
Setup 1: Thinkpad T14s G3, 14" FHD - R7 6850U - 32GB RAM - 2TB Solidigm P44 Pro NVME
Setup 2: Thinkpad X1E G1, 15.6" FHD - i7-8850H - 32GB RAM - NVIDIA GTX 1050Ti - 2x 1TB Samsung 970 Pro NVME
Accessories: Filco Majestouch TKL MX-Brown Mini Otaku, Benq XL2420T (144Hz), Lo(w)gitech G400, Puretrak Talent, Sennheiser HD800S + Meier Daccord FF + Meier Classic FF
Offline
Are there any .services that should explicity run as non-root but currently do not do it by default?
You are asking whether any one reading this thread considers that the package maintainer or upstream has produced a service that is incorrectly running a service as root?
Offline
You are asking whether any one reading this thread considers that the package maintainer or upstream has produced a service that is incorrectly running a service as root?
For which the answer depends on your philosophical view of truth. Certainly there are no examples that we are aware of, or we would have opened bug reports on said examples to have them fixed; so the answer would be 'No'. On the flipside, bugs do exist, and I personally find it extrodinarily unlikely that there could not be a single problematic case out there somewhere; so the answer would be 'Yes'.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Pages: 1