0

After upgrading Ubuntu from 14.04 to 16.04, I can no longer use dovecot's deliver program in procmail for system deliveries as root, because it claims it cannot open the auth-userdb file, even though normal users can and the imap server is otherwise working fine.

I purged and re-installed dovecot with no effect. File permissions seem fine, but invoking dovcot's deliver as root fails and the only error that gets logged (with all dovecot debug flags enabled) is:

%# cat /tmp/testmail | /usr/lib/dovecot/deliver -d username
Error 75
%# tail -n2 /var/log/dovecot.log
Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Permission denied (euid=0(root) egid=8(mail) UNIX perms appear ok (ACL/MAC wrong?))
Aug 24 22:05:14 lda: Fatal: Internal error occurred. Refer to server log for more information.

The file permissions on the socket are set so anyone can read/write to it. The error message even says the permissions look fine.

%# ls -l /var/run/dovecot/auth-userdb
srwxrwxrwx 1 root mtagroup 0 Aug 24 00:47 /var/run/dovecot/auth-userdb=

Running strace on deliver when running as root shows a failure to connect to the socket just before the program aborts, but the r/w permissions are then tested and are fine:

connect(7, {sa_family=AF_LOCAL, sun_path="/var/run/dovecot/auth-userdb"}, 110) = -1 EACCES (Permission denied)
close(7)                                = 0
...
stat("/var/run/dovecot", {st_mode=S_IFDIR|0755, st_size=740, ...}) = 0
getuid()                                = 0
geteuid()                               = 0
access("/var/run/dovecot", X_OK)        = 0
getuid()                                = 0
geteuid()                               = 0
access("/var/run/dovecot/auth-userdb", R_OK) = 0
getuid()                                = 0
geteuid()                               = 0
access("/var/run/dovecot/auth-userdb", W_OK) = 0
geteuid()                               = 0
getegid()                               = 0
open("/etc/localtime", O_RDONLY|O_CLOEXEC) = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=3585, ...}) = 0
fstat(7, {st_mode=S_IFREG|0644, st_size=3585, ...}) = 0
read(7, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\7\0\0\0\7\0\0\0\0"..., 4096) = 3585
lseek(7, -2281, SEEK_CUR)               = 1304
read(7, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\7\0\0\0\7\0\0\0\0"..., 4096) = 2281
close(7)                                = 0
write(6, "Aug 24 00:01:05 lda(cwolf): Erro"..., 180) = 180
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3585, ...}) = 0
write(6, "Aug 24 00:01:05 lda: Fatal: Inte"..., 95) = 95
exit_group(75)                          = ?
+++ exited with 75 +++

There are no helpful messages in syslog, and ALL apparmor profiles are in complain-only mode. I can connect to the socket as root using a small perl program.

Netstat shows the socket is active:

%# netstat -nvlap | fgrep auth-userdb
unix  2      [ ACC ]     STREAM     LISTENING     1874526  12031/auth [0 wait, /var/run/dovecot/auth-userdb

Since the socket/file permissions seem fine and the socket is active, I don't know how to debug this any deeper. Anyone have some ideas on how to fix this?

simpleuser
  • 274
  • 1
  • 4
  • 14

1 Answers1

0

Dovecot tries to deliver every email with the user's permission on their filesystem mailbox.

So that the user can read their email without being root through IMAP or POP or via a webmail client.

So the permission errors on delivery on your system is that dovecot tries to change itself to the users permissions to deliver the email on their folder.

To do that, dovecot-deliver program tries to read from the auth-userdb the proper permissions. If that is not setup correctly, then it fails with the above msg.

PS: I do think that running everything as root user is the proper way to do that.

ebal
  • 187
  • 3
  • Thanks for answering, but I don't understand why you say it does not have the proper permission? The socket is owned by root, which has r/w/x owner permission as well as r/w/x other permission. I can connect to it as root using a simple perl program. deliver is trying to connect as user root. There are no sticky bits set on the socket file, it is just srwxrwxrwx (where 's' in the designator field means 'socket'). Changing the socket owner to root:mail has no effect. – simpleuser Aug 25 '16 at 17:06
  • @user9999999 You are right, there is not a sticky bit. This is my mistake and I am sorry. I re-edit my answer above. – ebal Aug 26 '16 at 06:46