Bug#995201: chrony: No clue as to why CLI cannot find UNIX socket

[Steve Egbert]

Package: chrony
Version: 4.0-8
Severity: important
Tags: upstream
X-Debbugs-Cc: s.eg...@sbcglobal.net

Dear Maintainer,


The Crony CLI (chronyc) client couldn't do anything because
it could not find that UNIX socket that gets created by chronyd
daemon.

And I wanted to prove that these 'cmddeny'/'cmdallow' commands work
with my custom config settings using various drop-in config files
in different lexiographical-ordering in that drop-in 'conf.d' subdirectory.
The 'deny all'/'cmddeny all' was in effect.

So I loosen some file permissions before I went GDB as the '_chrony' UID:
Perhaps a bit too much.

UNIX socket should have been created by the chronyd (regardless
of who is able to run the Chrony 'chronyc' CLI client.)

UNIX socket was missing despite having a good service start of
Chrony daemon.

But no log message saying why such a socket was not being created, much less
a simple log message of this creation failure of the UNIX socket.

Caveat: What leaded up to all this, was that I had been
doing some switching back and forth between 'ntp' package
and 'chrony' package. (I truly do have a use-case for running both,
but that's another bug issue here.) But my package switching
isn't this bug problem.

I applied some liberal file permission settings toward /run/chrony
(amongst other files) so that I can study this issue by performing
the GDB debugging against the chronyd daemon.

So much convoluted GDB setup was required to get that chronyd start at root
then fork off (twice) into a Debian-created UID '_chrony' before
I could then see what the problem of this missing "UNIX socket" was.

The problem is NOT the currently defensive security measure of NOT creating
the UNIX socket if it encountered a undesired directory permission of
OTHER-READ-WRITE-EXECUTE on /run/chrony directory; the problem is
that there was absolutely NO log message indicating WHY it did NOT open
this UNIX socket.

No clue. Just took a deep debugging to find out just why.

It would be nice to see a log message (at least at permanent non-compiled-out
LOG_DEBUG) saying something to the effect of:

"No UNIX socket for you; see why ....".

== WORKAROUND ==
Oh, of course... the workaround is to run:

chown _chrony:_chrony /run/chrony
chmod 0750 /run/chrony

And voila, its UNIX socket is back; and chronyc is now working (for authorized
users).



-- System Information:
Debian Release: 11.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.46 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chrony depends on:
ii adduser 3.118
ii init-system-helpers 1.60
ii iproute2 5.10.0-4
ii libc6 2.31-13
ii libcap2 1:2.44-1
ii libedit2 3.1-20191231-2+b1
ii libgnutls30 3.7.1-5
ii libnettle8 3.7.3-1
ii libseccomp2 2.5.1-1
ii tzdata 2021a-1
ii ucf 3.0043

chrony recommends no packages.

Versions of packages chrony suggests:
ii bind9-dnsutils [dnsutils] 1:9.16.15-1
pn networkd-dispatcher <none>

-- no debconf information

[root]

Package: chrony
Version: 4.0-8+deb11u1
Followup-For: Bug #995201
X-Debbugs-Cc: s.eg...@sbcglobal.net


Also, the client-side 'chronyc' is NOT able to use a custom UNIX socket
path.

We can configure or change such UNIX socket path on the server side
using 'bindcmdaddress'

But we cannot lead the horse (chronyc) by the nose (UNIX socket path) to the watering hole (chronyd socket path).

Perhaps, remove support for UNIX socket path altogether (just kidding
there) or provide a command-line option for chronyc to select its
own non-compiled-in/non-default UNIX socket pathway.

Real world example: I've got 3 separate instances of chronyd running
(using a custom chr...@netdev.service instances). I can only view
exactly and at most ONE instance of those three(3) chrony daemons by
the virtue of its compiled in default (/run/chrony/chrony.sock).
And none of those are viewable by chrony client if using 'bindaddress'
directive non-default setting at each instance of the chrony servers.

General idea is to ensure that UDP packets go into a specific interface
as indicated by the 'ss' util:

# ss -lu | grep ntp
UNCONN 0 0 172.16.1.1%enp4s0:ntp 0.0.0.0:*
UNCONN 0 0 172.17.2.1%vmbr0:ntp 0.0.0.0:*
UNCONN 0 0 172.18.1.1%br0:ntp 0.0.0.0:*

-- System Information:
Debian Release: 11.2

APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-11-amd64 (SMP w/4 CPU threads)

Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chrony depends on:
ii adduser 3.118
ii init-system-helpers 1.60
ii iproute2 5.10.0-4

ii libc6 2.31-13+deb11u2

ii libcap2 1:2.44-1
ii libedit2 3.1-20191231-2+b1
ii libgnutls30 3.7.1-5
ii libnettle8 3.7.3-1

ii libseccomp2 2.5.1-1+deb11u1
ii tzdata 2021a-1+deb11u2

ii ucf 3.0043

chrony recommends no packages.

Versions of packages chrony suggests:

ii bind9-dnsutils [dnsutils] 1:9.16.22-1~deb11u1 (Using latest ISC Bind9 9.17+
pn networkd-dispatcher <none> (this is a bare-boned appliance server)

-- Configuration Files:
/etc/chrony/conf.d/README [Errno 2] No such file or directory: '/etc/chrony/conf.d/README'
/etc/chrony/sources.d/README [Errno 2] No such file or directory: '/etc/chrony/sources.d/README'
/etc/default/chrony changed [not included] (not applicable)
/etc/dhcp/dhclient-exit-hooks.d/chrony changed [not included] (not
applicable)

-- no debconf information