When trying to send e-mail from my local machine through my remote Virtualmin server I was denied because I was unable to authenticate myself. When I looked in /var/log/mail.log I could see the following message:
Jan 29 12:05:43 neptune postfix/smtpd[9477]: warning: SASL authentication failure: cannot connect to saslauthd server: Permission denied
Jan 29 12:05:43 neptune postfix/smtpd[9477]: warning: SASL authentication failure: Password verification failed
Jan 29 12:05:43 neptune postfix/smtpd[9477]: warning: [my_ip_address]: SASL PLAIN authentication failed: generic failure
Jan 29 12:05:43 neptune postfix/smtpd[9477]: warning: SASL authentication failure: cannot connect to saslauthd server: Permission denied
Jan 29 12:05:43 neptune postfix/smtpd[9477]: warning: [my_ip_address]: SASL LOGIN authentication failed: generic failure
Jan 29 12:05:44 neptune postfix/smtpd[9477]: disconnect from my_ip_address
After Googling around I came across this: http://www.jimmy.co.at/weblog/?p=52
which suggested changing the permissions on /var/spool/postfix/var/run/saslauthd
When I looked, that directory was owned by root (in group sasl) and had permissions of 710. When I changed permissions to 711 I was able to send e-mail from my local machine.
My question is this: are there any security implications in what I’ve done?
Also - I assume this is a glitch in the Virtualmin Pro install script for Ubuntu 8.04.2 since the install script is what installed and setup postfix and related software.
Yeah, this whole issue seems to intermittently work and break on Ubuntu and Debian-based systems.
Making sure the installer does what you performed above would probably be the best solution – I’ll talk to Joe and Jamie about that to see what’s currently being done, and make sure the issue you saw there is being handled correctly.
I have been having the exact same problems, only I have to chmod periodically. Even though the permissions say 751, i have to chmod 751 saslauthd manually in order for it to work again.
Anyone have any clue what’s causing it to change? (It’s nothing we’re doing…so it’s gotta be something in the OS package or standard cronjobs or something.)
Eric, you might be on to something with regard to the Postfix chroot, as it would be creating new files on start. On Red Hat based systems, Postfix does not run anything chrooted (and, as an aside, Postfix’ author doesn’t recommend running chrooted; I trust him on security questions far more than I trust random Debian or Ubuntu packagers, as he’s one of the gods of UNIX security, having created SATAN and the tcpwrappers…so I think the Debian/Ubuntu people are making a mistake by having it run chrooted).
It might be worth watching that process–stop and start postfix, checking the state of that directory at each stage. And then doing the same without chrooting any Postfix services (that’s set in master.cf). Then again, that path seems specific to a chrooted configuration, so it’d probably take additional changes. My head hurts now.