Ubuntu
courier-authlib package

insufficient access permission for /var/run/courier/authdaemon

Bug #483170 reported by Michael Jastram
72
This bug affects 11 people
Affects Status Importance Assigned to Milestone
courier-authlib (Ubuntu)
Fix Released
Undecided
Unassigned
Lucid
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: courier-authlib

Summary:

The directory /var/run/courier/authdaemon had permission 750. In order to get courier-mta to work, I had to change it to 755.

Details:

I am running a mail server with imap and smtp, both served by courier. Configuring imap was fairly straightforward. Configuring smtp (with courier-mta) gave me a headache. The following simple test failed:

root@pluto:/etc/courier# echo "To: michael@localhost" | sendmail
ERR: authdaemon: s_connect() failed: Permission denied
450-Service temporarily unavailable.
450 Headers specify no receipients.
sendmail: Unable to submit message.

This was strange for two reasons: First, I didn't expect sendmail to communicate with authdaemon, and second, authdaemon worked just fine for imap.

it took me a long time to find out that not all processes had access to the authdaemon socket. The socket itself had proper permissions:

root@pluto:/var/run/courier/authdaemon# ls -l
srwxrwxrwx 1 root root 0 2009-11-15 17:55 socket
...

... but the folder containing it didn't:

root@pluto:/var/run/courier# ls -l
drwxr-x--- 2 root root 100 2009-11-15 17:55 authdaemon
...

A chmod to 755 of the containing directory did the trick. I am not sure whether this is the best solution (vs. changing ownership of the folder).

ProblemType: Bug
Architecture: amd64
Date: Sun Nov 15 18:20:27 2009
DistroRelease: Ubuntu 9.10
Package: courier-authlib 0.62.2-1
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-server
SourcePackage: courier-authlib
Uname: Linux 2.6.31-14-server x86_64

Revision history for this message
Michael Jastram (jastram) wrote :
Revision history for this message
Michael Jastram (jastram) wrote :

One more thing: the permissions are reset after a reboot - thus, the described fix is not permanent.

Revision history for this message
Rickard Lind (rickard-lind) wrote :

I'll second this bug. I recently ran into this problem after upgrading 9.04 to 9.10 (also amd64).

Revision history for this message
Andreas Scott (ubuntu-scott-net) wrote :

In /etc/init.d/courier-authdaemon line 31:

- mkdir -p -m 0750 $rundir
+ mkdir -p -m 0755 $rundir

will set the correct permissions permantly.

This bug is very annoying, because mail isn't working after a reboot.

Revision history for this message
Dan Burke (dan-burke) wrote :

I too can confirm this on a 9.04 to 9.10 amd64 upgrade. Another work around I found via Google was doing a chown -R daemon:daemon on the /var/run/courier directory, but those permissions are also lost after a reboot and are changed to root on the next boot.

Revision history for this message
Wladimir Mutel (mwg) wrote :

I confirm that this is still true for 10.04 upgrade. The upgrade replaces courier-authdaemon startup script , and in the new official version of the script, the permissions on created directory are left unchanged. They should be changed to be readable for at least daemon:daemon user&group, like this :

--- /etc/init.d/courier-authdaemon 2009-12-06 01:05:50.000000000 +0200
+++ /backup/tag/etc/init.d/courier-authdaemon 2009-10-27 13:36:58.000000000 +0200
@@ -28,7 +28,12 @@
        cd /
        log_daemon_msg "Starting Courier authentication services" "authdaemond"
        if [ ! -d "$rundir" ]; then
+ if [ ! -d $(dirname "$rundir") ]; then
+ mkdir -p -m 0750 $(dirname $rundir)
+ chown daemon.daemon $(dirname $rundir)
+ fi
                mkdir -p -m 0750 $rundir
+ chown daemon.daemon $rundir
        fi
        $daemonscript start
        log_end_msg 0

Revision history for this message
Wladimir Mutel (mwg) wrote :

Related Debian bugs : 429866 and 394779 . Probably their solutions should be combined in a creative way :>

Revision history for this message
widu (widu) wrote :

This Bug still exists, as well on i386. Very anoying, hard to track down.

Revision history for this message
C. Alex. North-Keys (erlkonig-talisman) wrote :

I'd like to second Mutel comment that it's not the permissions that are the problem, but the owner/group combo. At least one of them needs to be daemon, it doesn't actually matter which (or both). Setting the permissions to 0755 is a bad idea, since then any arbitrary process can poke at the socket.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

This was fixed in Debian, here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429866

Which was included in Maverick and is in Natty.

Nominating this for Lucid.

Changed in courier-authlib (Ubuntu):
status: New → Fix Released
Revision history for this message
Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in courier-authlib (Ubuntu Lucid):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.