My takeaway from the above is that the daemon service itself still runs as root, just the group name changes, so for the specific scenario raised in question #2 it looks like the daemon's read access to root only files like shadow would be unaffected. Similarly, the issue I raised in "Where Problems May Occur" due to root ownership of files in /var/run/saslauthd would not be exhibited by read (or write) errors by the daemon itself.
Indeed, it appears the contents of /var/run/saslauthd are cleared when the daemon stops, or is restarted, so if there *was* an issue with files in the run directory it should present immediately at service stop/start/restart: $ sudo systemctl stop saslauthd $ sudo ls /var/run/saslauthd/ -l ls: cannot access '/var/run/saslauthd/': No such file or directory $ sudo systemctl start saslauthd $ sudo ls /var/run/saslauthd/ -l total 968 -rw------- 1 root sasl 0 Oct 3 16:38 cache.flock -rw------- 1 root sasl 986112 Oct 3 16:38 cache.mmap srwxrwxrwx 1 root sasl 0 Oct 3 16:38 mux -rw------- 1 root sasl 0 Oct 3 16:38 mux.accept -rw------- 1 root sasl 6 Oct 3 16:38 saslauthd.pid $ sudo systemctl restart saslauthd $ sudo ls /var/run/saslauthd/ -l total 968 -rw------- 1 root sasl 0 Oct 3 16:38 cache.flock -rw------- 1 root sasl 986112 Oct 3 16:38 cache.mmap srwxrwxrwx 1 root sasl 0 Oct 3 16:38 mux -rw------- 1 root sasl 0 Oct 3 16:38 mux.accept -rw------- 1 root sasl 6 Oct 3 16:38 saslauthd.pid $ sleep 60 $ sudo systemctl restart saslauthd $ sudo ls /var/run/saslauthd/ -l total 968 -rw------- 1 root sasl 0 Oct 3 16:39 cache.flock -rw------- 1 root sasl 986112 Oct 3 16:39 cache.mmap srwxrwxrwx 1 root sasl 0 Oct 3 16:39 mux -rw------- 1 root sasl 0 Oct 3 16:39 mux.accept -rw------- 1 root sasl 6 Oct 3 16:39 saslauthd.pid $ sleep 120 $ sudo ls /var/run/saslauthd/ -l total 968 -rw------- 1 root sasl 0 Oct 3 16:39 cache.flock -rw------- 1 root sasl 986112 Oct 3 16:39 cache.mmap srwxrwxrwx 1 root sasl 0 Oct 3 16:39 mux -rw------- 1 root sasl 0 Oct 3 16:39 mux.accept -rw------- 1 root sasl 6 Oct 3 16:39 saslauthd.pid -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cyrus-sasl2 in Ubuntu. https://bugs.launchpad.net/bugs/2078851 Title: saslauthd wrong permission of /var/spool/postfix/var/run/saslauthd Status in cyrus-sasl2 package in Ubuntu: Fix Released Status in cyrus-sasl2 source package in Noble: Incomplete Status in cyrus-sasl2 source package in Oracular: Fix Released Bug description: [Impact] Incorrect ownership of files in saslauthd's run directory can result in service issues (e.g. failure to authenticate, failure to restart, etc.) [Workaround] # systemctl edit saslauthd.service Then, put the following lines inside the file: [Service] Group=sasl Save the file, and restart the service. You should now see the right permissions/owner/group under /run/saslauthd. [Test Case] $ sudo apt-get install postfix sasl2-bin $ sudo systemctl enable saslauthd $ ls -ld /run/saslauthd/ drwx--x--- 2 root sasl 40 Sep 24 23:07 /run/saslauthd/ $ sudo systemctl start saslauthd $ ls -ld /run/saslauthd/ drwxr-xr-x 2 root root 140 Sep 24 23:09 /run/saslauthd [Where Problems Could Occur] Since the fix is only in packaging and deals only with permissions, regressions would be expected to be limited to permission issues relating to packaging files (configuration, daemons, logs, etc.) Notably, the fix corrects permissions on the *directory* itself, but not on its contents. Since the problem is that root ownership of the directory prevents non-root users from adding non-root owned files there, it is unlikely this situation would crop up in practice, and if it did should be reviewed and analyzed by the user. (We would not want to auto-fix unknown root-owned file permissions to non-root.) [Original Report] Folder group permission of /var/spool/postfix/var/run/saslauthd gets reset to "root" (should be "sasl") every time saslauthd gets restarted. This worked fine before upgrading from 22.04 to 24.04 My automated workaround currently is this crontab (root) entry: */1 * * * * /usr/bin/chgrp sasl /var/spool/postfix/var/run/saslauthd 2>&1 ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: postfix 3.8.6-1build2 ProcVersionSignature: Ubuntu 6.8.0-41.41-generic 6.8.12 Uname: Linux 6.8.0-41-generic x86_64 NonfreeKernelModules: zfs ApportVersion: 2.28.1-0ubuntu3.1 Architecture: amd64 CasperMD5CheckResult: unknown Date: Tue Sep 3 19:52:59 2024 SourcePackage: postfix UpgradeStatus: Upgraded to noble on 2024-08-31 (3 days ago) mtime.conffile..etc.init.d.apport: 2024-07-22T16:59:07 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/2078851/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp