Package: chrony Version: 4.0-8 Severity: important Tags: upstream X-Debbugs-Cc: [email protected]
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
