Ok, this bug snowballed. And it looked so easy :)
Disclaimer: I did review the branch for oracular, and thought this group
change was the final fix, but looks like it's not... See below.
a) The sasl2-bin postinst sets permissions on /run/saslauthd as follows:
# Create a statoverride for the default saslauthd run directory,
# unless one already exists
if ! dpkg-statoverride --list $FALLBACK_RUN_DIR >/dev/null 2>&1; then
install -d --owner="root" --group="sasl" --mode="710" \
$FALLBACK_RUN_DIR
dpkg-statoverride --update --add root sasl 710 $FALLBACK_RUN_DIR
fi
That, together with the fact that saslauthd.service is shipped DISABLED,
is why we get:
drwx--x--- 2 root sasl 40 Oct 17 20:00 /run/saslauthd
b) The problematic interaction with postfix is a bit more subtle: it's because
postfix runs as chroot in debian/ubuntu.
Note from the reporter how his workaround is to adjust the permissions
on /var/spool/postfix/var/run/saslauthd, and not /run/saslauthd.
The postfix chroot is /var/spool/postfix, and it's created
automatically. But by default we don't get the saslauthd runtime dir in
the chroot.
I believe we are missing this bit of the setup from the reporter and in
the test case, because just installing postfix doesn't make it include
the saslauthd socket in the chroot. Either the reporter has a
/etc/default/saslauthd file specifying a different location for the
saslauthd socket, or a /etc/default/postfix config indicating extra
files to be copied into the postfix chroot.
c) The fix being proposed here just changes the group ownership of the runtime
directory, i.e., we get:
drwxr-xr-x 2 root sasl 140 Oct 17 19:59 /run/saslauthd
Compare that to what the package postinst did:
drwx--x--- 2 root sasl 40 Oct 17 20:00 /run/saslauthd
So we are not 100% going back to what we had in jammy. Furthermore, the
directory is still open to any user. I'm not sure that matters even,
because the saslauthd mux socket is 777 in both cases.
d) I changed the saslauthd socket location in /etc/default/saslauthd following
the instructions there (the "-m" parameter) to
/var/spool/postfix/var/run/saslauthd, but things got a bit messy... I suspect
the migration to a systemd service is not fully done... It seems like the -m
option also changes the location of the PID file to be in that same directory,
and that will then disagree with the systemd PIDFile setting which is
/var/run/saslauthd. So systemd keeps waiting for the PID file to appear, but is
checking the wrong place...
So what I think we need here is:
- a better test case. Just installing postfix is not enough. Either a new test
case, perhaps with testsaslauthd, or the missing bits to reproduce the postfix
problem.
- this bug made the directory (/run/saslauthd) more *open* (755 root:root),
instead of more restrictive (710 root:sasl), so what exactly broke in postfix's
case? The mux file from saslauthd inside that runtime directory is 777 in all
cases.
- what's the right way to have chrooted postfix integrate with saslauthd
The plot thickens...
--
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:
Fix Committed
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.)
saslauthd itself will appear to start successfully, but e.g. postfix will be
unable to authenticate, effectively preventing outgoing mail submitted via
smtp. This worked properly on prior LTS releases, but breaks outgoing mail
service on upgrade to 24.04.
[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 group ownership,
regressions would be expected to be limited to permission issues relating to
packaging files (configuration, daemons, logs, etc.)
Notably, the fix corrects group ownership permissions on the
*directory* itself, but not on its contents. The service itself
continues to run as the same user, so it should not cause any
read/write problems, but if there are any issues pertaining to *group*
ownership, those may be relate to this change.
[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
