Wrong permissions on saslauthd

8 posts / 0 new
Last post
#1 Thu, 01/29/2009 - 09:31
hillb

Wrong permissions on saslauthd

Wrong permissions on saslauthd

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.

Thu, 01/29/2009 - 10:41
andreychek

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.

Thanks!
-Eric

Tue, 03/03/2009 - 08:25
plahpoy@gmail.com

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.

anything been fixed on this issue?

I'm running the latest vmin pro

Tue, 03/03/2009 - 08:39 (Reply to #3)
Joe
Joe's picture

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.)

--

Check out the forum guidelines!

Tue, 03/03/2009 - 08:46 (Reply to #4)
andreychek

And which distro is it that you're having troubled with?

While I've frequently seen this problem on Ubuntu -- it was only once. Once the permissions were changed, it worked.
-Eric

Tue, 03/03/2009 - 08:49
plahpoy@gmail.com

ubuntu, but for example, if i reboot i need to re chmod it again in order for email to work.

Tue, 03/03/2009 - 08:55 (Reply to #6)
andreychek

Well, first, I'll offer that I'm not seeing that behavior on my Ubuntu server.

However, it sounds like something during startup -- or perhaps Postfix as it copies over the chroot files -- might be resetting those permissions.

What you could do is put something in the saslauthd init script to fix the perms automatically.

That'd just be a matter of editing "/etc/init.d/saslauthd", and adding a line in there somewhere along the lines of:

chmod 751 /var/spool/postfix/var/run/saslauthd

You may consider putting that into /etc/default/saslauthd instead, I'm not sure which would be better.

Of course, there's nothing like actually solving the root of the problem, but I'm not sure what that is at the moment :-)
-Eric

Tue, 03/03/2009 - 09:28 (Reply to #7)
Joe
Joe's picture

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.

--

Check out the forum guidelines!

Topic locked