[solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

dawnofman · 2019-07-27 23:25:13

I have the ntp package installed which (by default) starts as following:

ExecStart=/usr/bin/ntpd -g -u ntp:ntp

I also have the required configuration file as following;

ls -l /etc/ntp.conf;

-rw-r--r-- 1 root root 2162 2019-07-27 /etc/ntp.conf

The service starts and works as expected; however:

If I change the permissions of the configuration file as following:

chgrp ntp /etc/ntp.conf;
chmod 640 /etc/ntp.conf;
ls -l /etc/ntp.conf;

-rw-r----- 1 root ntp 2162 2019-07-27 /etc/ntp.conf

systemctl restart ntpd;
systemctl status ntpd;

The service keeps working as expected; now:

chgrp root /etc/ntp.conf;
chmod 600 /etc/ntp.conf;
ls -l /etc/ntp.conf;

-rw------- 1 root root 2162 2019-07-27 /etc/ntp.conf

systemctl restart ntpd;
systemctl status ntpd;

The service keeps working and now this is (at least to me) not expected: I do not understand why it can read the configuration file being running with the ntp user ... ?

So ... why am I doing this if it all works by default ?

Because I currently have a permission issue with BIND (not) accessing its configuration file and I choose to tinker a bit with a far more simpler service like ntp to understand how such services are configured/started with different user names other than root. I have a long-time running installation with arch and ntp and bind and although I now installed a new machine with the same exact configuration and permissions I am getting (at least one) service not starting due to (wrong ?) permissions. So in the first place I choose to try to understand what happens when one starts a service configured with another user.

Last edited by dawnofman (2019-07-28 23:42:44)

loqs · 2019-07-27 23:30:15

cat /usr/lib/systemd/system/ntpd.service 
[Unit]
Description=Network Time Service
After=network.target nss-lookup.target
Conflicts=systemd-timesyncd.service

[Service]
Type=forking
PrivateTmp=true
ExecStart=/usr/bin/ntpd -g -u ntp:ntp
Restart=always

[Install]
WantedBy=multi-user.target

The service is started as root by systemd due to there not being a User entry in the service file. The -u option of ntpd is used after it has read its config file found which port to bind to e.t.c.

dawnofman · 2019-07-27 23:52:33

First and foremost thanks for your quick reply !

the service is started as root by systemd ...

Crystal-clear and this explains what's happening then.

... due to there not being a User entry in the service file

So this means that if a service unit is (somehow) installed/configured with any given account there will be no root involvement in the process right ?

Reading the systemd.unit(5) man page I find only two references that maybe are related to what you're describing; namely:

- Condition[User|Group]
- Assert[User|Group]

But if I get thinks more or less right they are dealing with setting/asserting conditions before the service is started, not with specifying any given user/group with whom the service should be started ... am I understanding things correctly ?

loqs · 2019-07-27 23:56:04

Yes ConditionUser and AssertUser are for exactly that. The User directive is convered in systemd.exec, systemd has so many directives it has systemd.directives to document which man page each is covered in.

dawnofman · 2019-07-28 00:20:52

OK. I'll investigate the matter further then.

Could you provide (or point me to) a real-world example of a service unit configured with a given user/group if it quickly comes to mind ?

loqs · 2019-07-28 00:30:04

Sure postgresql.service

dawnofman · 2019-07-28 01:00:09

Thanks for the link to the postgresql.service unit !

After checking it I did the following:

cp --preserve /usr/lib/systemd/system/ntpd.service /etc/systemd/system/;

and then replace the following line:

ExecStart=/usr/bin/ntpd -g -u ntp:ntp

with

ExecStart=/usr/bin/ntpd -g

and added the following lines under [Service]:

User=ntp
Group=ntp

then:

systemctl disable ntpd;
systemctl enable ntpd; ### now ntpd starts with my custom service unit @ /etc/systemd/system/ntpd.service
systemctl status ntpd;

It is working albeit my /etc/ntp.conf remains as 600 root:root

Upon closer inspection I see that systemctl status ntpd reports: /usr/bin/ntpd -g -u ntp:ntp

So it seems that systemd took my User/Group entries and automatically placed them as arguments to the -u switch.

Evidently it keeps starting as root ... back to square one ?

Trilby · 2019-07-28 01:06:15

No, disable/enable is not the same as stop/start or restart.

Last edited by Trilby (2019-07-28 01:06:32)

dawnofman · 2019-07-28 03:09:51

No, disable/enable is not the same as stop/start or restart.

Indeed. My mistake !

Still no luck; so definitely I am doing something wrong:

cat /etc/systemd/system/ntpd.service;

[Unit]
Description=Network Time Service
After=network.target nss-lookup.target
Conflicts=systemd-timesyncd.service

[Service]
Type=forking
PrivateTmp=true
ExecStart=/usr/bin/ntpd -g
Restart=always
User=ntp
Group=ntp

[Install]
WantedBy=multi-user.target

stat /etc/ntp.conf;

  File: /etc/ntp.conf
  Size: 910       	Blocks: 8          IO Block: 4096   regular file
Device: 802h/2050d	Inode: 1310988     Links: 1
Access: (0640/-rw-r-----)  Uid: (    0/    root)   Gid: (   87/   ntp)
Access: 2019-07-27 20:07:46.039486742 -0300
Modify: 2019-07-24 00:00:00.000000000 -0300
Change: 2019-07-27 22:30:13.092298466 -0300
 Birth: 2019-07-25 16:36:25.084994946 -0300

cat /etc/ntp.conf; ### a sanitized version

server #.#.#.# iburst
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log

systemctl enable ntpd; ### after rebooting (with ntpd disabled before rebooting)
systemctl start ntpd;
systemctl status ntpd;

● ntpd.service - Network Time Service
   Loaded: loaded (/etc/systemd/system/ntpd.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sat 2019-07-27 23:42:29 -03; 8min ago

Jul 27 23:42:29 whatever systemd[1]: ntpd.service: Service RestartSec=100ms expired, scheduling restart.
Jul 27 23:42:29 whatever systemd[1]: ntpd.service: Scheduled restart job, restart counter is at 5.
Jul 27 23:42:29 whatever systemd[1]: Stopped Network Time Service.
Jul 27 23:42:29 whatever systemd[1]: ntpd.service: Start request repeated too quickly.
Jul 27 23:42:29 whatever systemd[1]: ntpd.service: Failed with result 'exit-code'.
Jul 27 23:42:29 whatever systemd[1]: Failed to start Network Time Service.

Trilby · 2019-07-28 03:18:17

So in that case you expect it *should* work, but doesn't right? It should work as the config file is readable by group ntp. But the status output suggests it failed. So this is a very different case than before when you thought it should fail to read the file but succeeded anyways - so it's really not a related problem.

But if you want to track the error from this last post, I'd check the log file. First check if the log file is even writable by the ntp user/group. If it's not, then there'd be nothing to see in it - but if it's not, that may itself explain the error.

dawnofman · 2019-07-28 03:21:16

Further info about 15 minutes later (without doing anything else):

systemctl status ntpd;

● ntpd.service - Network Time Service
   Loaded: loaded (/etc/systemd/system/ntpd.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2019-07-28 00:06:46 -03; 8min ago
  Process: 760 ExecStart=/usr/bin/ntpd -g (code=exited, status=200/CHDIR)

Jul 28 00:06:46 whatever systemd[1]: ntpd.service: Service RestartSec=100ms expired, scheduling restart.
Jul 28 00:06:46 whatever systemd[1]: ntpd.service: Scheduled restart job, restart counter is at 5.
Jul 28 00:06:46 whatever systemd[1]: Stopped Network Time Service.
Jul 28 00:06:46 whatever systemd[1]: ntpd.service: Start request repeated too quickly.
Jul 28 00:06:46 whatever systemd[1]: ntpd.service: Failed with result 'exit-code'.
Jul 28 00:06:46 whatever systemd[1]: Failed to start Network Time Service.

journactl _PID=760

-- Logs begin at Thu 2019-07-25 17:02:47 -03, end at Sun 2019-07-28 00:13:09 -03. --
Sun 2019-07-28 00:06:46 -03 whatever systemd[760]: ntpd.service: Failed to connect stdout to the journal socket, ignoring: Permission denied

Please, note the (code=exited, status=200/CHDIR) ... this is exactly what I got while starting BIND and what made me starting this "research" with ntpd.

dawnofman · 2019-07-28 03:29:40

Trilby wrote:

So in that case you expect it *should* work, but doesn't right? It should work as the config file is readable by group ntp. But the status output suggests it failed. So this is a very different case than before when you thought it should fail to read the file but succeeded anyways - so it's really not a related problem.

Exactly. Now I am expecting it to work but it seems it is not working. The whole point of this thread (starting with the opposite case) was to understand why a service is successfully reading a configuration file that has no access to (with its configured user/group that is). From an earlier reply now I understand why (no User/Group entries in the service unit makes the service start as root and then switches to appropriate user/group after reading the configuration file). When this was crystal-clear I tried the opposite: assigned a given user/group to the service unit, made /etc/ntp.conf readable to this user (but kept it owned by root). Problem is that the service should now work (without using the root user at all) but it seems it doesn't.

But if you want to track the error from this last post, I'd check the log file. First check if the log file is even writable by the ntp user/group. If it's not, then there'd be nothing to see in it - but if it's not, that may itself explain the error.

I'll investigate. Let me check.

dawnofman · 2019-07-28 03:46:31

Trilby wrote:

First check if the log file is even writable by the ntp user/group. If it's not, then there'd be nothing to see in it - but if it's not, that may itself explain the error.

Indeed /var/log/ntp.log has write permissions for the ntp group but has nothing new in it since more or less three hours ago (presumably when I started using /etc/systemd/system/ntpd.service)

dawnofman · 2019-07-28 06:00:40

Thanks everyone: I learned a lot of things today !

While researching this issue I attempted to login as another user and it was a no-go: login refused. At this point I started suspecting a wider permission problem that could be causing the issues I am having with the unexpected behavior of the services discussed in this thread. The key finally appeared in the journal in the form of Failed to connect stdout to the journal socket, ignoring: Permission denied messages which triggered a reminder of the (code=exited, status=200/CHDIR) message I got earlier in the day with the ntpd service.

So after looking for references I encountered the following (sorry, it is in german only): Nach Update kein User-Login mehr möglich und weitere Fehler

Long-story short (and in plain english): I had an unrelated problem causing all my issues: somehow the root directory ended as 700 instead of 755 !

A single chmod 755 /; resolved all my issues at once !

So why this happened in the first place ?

I am installing (an automating the installation) on a second machine. I wrote some scripts and yesterday one broke and I did not pay the attention I should have payed: it was working from / doing some chmod's to files on another place and somehow I managed to left a space after some file name and before an asterisk. I suspect this was what caused the problem. Causes aside, all this issues are solved.

Back to the services in question:

I learned that the ntpd service will not work using a [User|Group] under the [Service] entry: upon start it will explicitly ask to be run as root.
I learned that the named service will not work using a [User|Group] under the [Service] entry: upon start it will complain about not able to create the required IPv4 interface (to listen for UDP).

Bottom line: I now have all the services working but better yet; I know why they are working and why they were not working to begin with ... which was the whole point of this thread.

Thanks everybody for tipping me in the right direction --sometimes I wonder how helpful is to write about an issue: it helps clear the mind and (with some outside help) a solution is often around the corner

2ManyDogs · 2019-07-28 13:55:50

Please remember to mark your thread [SOLVED] (edit the title of your first post).

Arch Linux

#1 2019-07-27 23:25:13

[solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#2 2019-07-27 23:30:15

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#3 2019-07-27 23:52:33

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#4 2019-07-27 23:56:04

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#5 2019-07-28 00:20:52

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#6 2019-07-28 00:30:04

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#7 2019-07-28 01:00:09

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#8 2019-07-28 01:06:15

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#9 2019-07-28 03:09:51

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#10 2019-07-28 03:18:17

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#11 2019-07-28 03:21:16

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#12 2019-07-28 03:29:40

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#13 2019-07-28 03:46:31

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#14 2019-07-28 06:00:40

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

#15 2019-07-28 13:55:50

Re: [solved] ntpd -u ntp:ntp reading 600 root:root /etc/ntp.conf ... why ?

Board footer