Missing tmp directory for GSSAPI authentication
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
postfix (Debian) |
New
|
Unknown
|
|||
postfix (Ubuntu) |
New
|
Low
|
Unassigned |
Bug Description
I had some trouble getting GSSAPI authentication in postfix working when moving my mail system to a new machine. GSSAPI is a bit complicated with postfix since it runs in a chroot jail. There are several guides available for this process (in particular, getting the keytab and krb5.conf files in the right place), and I did have it working on my previous machine, so I was pretty sure I had the configuration correct and that there was something wrong with the newly installed system.
Postfix was producing the following errors in the system log:
postfix/
postfix/
That error was not terribly useful, but strace-ing the smtpd process produced the source of the real error:
lstat("
unlink(
open("/
unlink(
The process was unable to create a credential cache because the /var/tmp directory did not exist under the chroot filesystem. Creating the directory /var/spool/
I'm not exactly sure why the gssapi library was using /var/tmp instead of /tmp (which didn't exist either). kerberos credentials for the rest of my system are stored in /tmp.
I think the postfix package should be altered to include a /var/tmp directory in the chroot file hierarchy. If that is not possible, the gssapi configuration within the chroot should be setup to use a different directory for the credential cache, which does exist and has the proper permissions.
tags: | removed: needs-upstream-report |
Changed in postfix (Debian): | |
status: | Unknown → New |
Thank you for taking the time to report this bug and helping to make Ubuntu better.
Your report sounds reasonable and I appreciate the detail and diagnostics that you performed.
Since I believe GSSAPI is an uncommon end-user configuration for postfix, I'm marking this bug with Low importance.
It seems to me that this bug would equally affect Debian, and if so then this bug would probably best be raised in Debian, and then Ubuntu will sync or merge in time as appropriate.
Please could you check that this bug reproduces in Debian, and then file a bug there if so? Thanks!