Wrong permissions on /var/run/chrony

Since my last update I see in the boot log:


chronyd[942]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG)
chronyd[942]: Wrong permissions on /var/run/chrony
chronyd[942]: Disabled command socket /var/run/chrony/chronyd.sock

Checked an old log and see that chrony was updated from version 3.3 to 3.4

It is a pity that the error is not giving hints on what is wrong, but the good thing of open source is that you can look into the sources and there I found that the permissions are and-ed with 0770 and if that gives a non-zero result you get this error.

Had a look and my system and saw, the permission were indeed not right and corrected them:


> ls -ld /var/run/chrony
drwxr-xr-x 2 chrony chrony 60 Nov  3 17:28 /var/run/chrony
> sudo chmod o-rx /var/run/chrony
[sudo] password for root:
> ls -ld /var/run/chrony
drwxr-x--- 2 chrony chrony 60 Nov  3 17:28 /var/run/chrony

Did reboot but still the error, checked again /var/run/chrony and saw the old permissions were back and the time-stamp updated to 2 minutes after the last boot.
What is going on?

Searching a bit further I found /run and /var/run are created run-time so seeing the file with the updated timestamp makes sense.

Next question is which process creates /var/run/chrony, in the sources I see chrony will make the directory if it does not exist but I would expect it then to have the right permissions.

Likely systemd does create the directory but with the wrong permissions. Checked /usr/lib/tmpfiles.d but some /var/run directories are specified there but not /var/run/chrony

In /usr/lib/systemd/system/chronyd.service there is:


[Unit]
Description=NTP client/server
Documentation=man:chronyd(8) man:chrony.conf(5)
After=ntpdate.service sntp.service ntpd.service
Conflicts=ntpd.service systemd-timesyncd.service
ConditionCapability=CAP_SYS_TIME

[Service]
Type=forking
PIDFile=/var/run/chrony/chronyd.pid
EnvironmentFile=-/etc/sysconfig/chronyd
ExecStart=/usr/sbin/chronyd $OPTIONS
ExecStartPost=/usr/share/chrony-helper update-daemon
PrivateTmp=yes
ProtectHome=yes
ProtectSystem=full

[Install]
WantedBy=multi-user.target

Will systemd because of “PIDFile=/var/run/chrony/chronyd.pid” create /var/run/chrony/? If so, how to have it set the right permissions?

Run

chkstat --system

to restore all permissions.

I am seeing the same error messages for “chronyd”. It does not appear to cause problems. That is to say, “chronyd” is still running and apparently keeping the time synchronized.

From the error message, it looks as if “chronyd” opens a control socket, but it is not doing that when the permissions are wrong. So you lose the ability to use the control socket, but it otherwise works.

Maybe a bug report is in order. Let the maintainers of “chronyd” for openSUSE look into a solution.

I do not know if they are related, but I had a similar problem with sshfs after recent updates, wrong permissions. Running the command I gave above fixed the problem.

Thanks for the feedback!

Tried restoring the permissions using “chkstat --system” and that fixed some not related permissions but after a reboot I still see the problem.

Created Bug 1115529](https://bugzilla.opensuse.org/show_bug.cgi?id=1115529) - chronyd version 3.4 has problems starting the command socket

Yes, that’s a good move at this stage. I’ve added myself to the “cc:” list for that bug.

See the update of Aleksandar in Bug 1115529](https://bugzilla.opensuse.org/show_bug.cgi?id=1115529), the problem is now understood and with the described modification the problem is gone for me.

Thanks for that update.

My guess is that we will see a fix for this in a future Tumbleweed release.