** Description changed:
[Impact]
- Incorrect ownership of files in saslauthd's run directory can result in
service issues (e.g. failure to authenticate, failure to restart, etc.)
+ 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 permissions,
regressions would be expected to be limited to permission issues relating to
packaging files (configuration, daemons, logs, etc.)
+ 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 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.)
+ 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
** Changed in: cyrus-sasl2 (Ubuntu Noble)
Status: Incomplete => New
** Changed in: cyrus-sasl2 (Ubuntu Noble)
Status: New => In Progress
** Changed in: cyrus-sasl2 (Ubuntu Noble)
Status: In Progress => Fix Committed
--
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
