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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2078851
Title:
saslauthd wrong permission of /var/spool/postfix/var/run/saslauthd
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/2078851/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
