I recently installed a new SSL certificate and then also decided to tighten security a bit by make the private key less readable.

This caused a problem with exim.

The certificate is now 640 with user root and group ssl. The user Debian-exim is in this group.

I can access the private key file just fine from the shell:

#sudo -u Debian-exim cat key

However, the log file of exim says otherwise:

2012-04-21 00:00:00 <Message-id> unable to open private key file for reading: /.../key
2012-04-21 00:00:00 <Message-id> == some@email <some@email> R=dnslookup T=remote_smtp defer (-1): smtp transport process returned non-zero status 0x0100: exit code 1
2012-04-21 00:00:00 <Message-id> Frozen

Using auditd I checked the filesystem access:

time->Sat Apr 21 00:00:00 2012
type=PATH msg=audit(1335027881.290:6): item=0 name="/.../key" inode=1794200 dev=09:01 mode=0100640 ouid=0 ogid=105 rdev=00:00
type=CWD msg=audit(1335027881.290:6):  cwd="/var/spool/exim4"
type=SYSCALL msg=audit(1335027881.290:6): arch=c000003e syscall=2 success=no exit=-13 a0=16184f8 a1=0 a2=0 a3=0 items=1 ppid=11831 pid=11847 auid=4294967295 uid=100 gid=102 euid=100 suid=100 fsuid=100 egid=102 sgid=102 fsgid=102 tty=pts1 ses=4294967295 comm="exim4" exe="/usr/sbin/exim4" key="sslkey"

Which shows that it indeed fails (though I don't know why). In comparison an as-identical-as-possible successfull calle (file group is changed to Debian-exim as opposed to ssl)

time->Sat Apr 21 00:00:00 2012
type=PATH msg=audit(1335028586.882:34): item=0 name="/.../key" inode=1794200 dev=09:01 mode=0100640 ouid=0 ogid=102 rdev=00:00
type=CWD msg=audit(1335028586.882:34):  cwd="/var/spool/exim4"
type=SYSCALL msg=audit(1335028586.882:34): arch=c000003e syscall=2 success=yes exit=11 a0=24f74f8 a1=0 a2=0 a3=0 items=1 ppid=13958 pid=13961 auid=4294967295 uid=100 gid=102 euid=100 suid=100 fsuid=100 egid=102 sgid=102 fsgid=102 tty=(none) ses=4294967295 comm="exim4" exe="/usr/sbin/exim4" key="sslkey"

I have no idea what goes wrong. Why can the exim daemon access the "key" file when the file group is Debian-exim (primary group of Debian-exim user) but not when the file group is ssl (a secondary group of Debian-exim user)?


The groups that a user is in are granted by the login process. When a daemon switches to a user and group after launch, it typically only switches to this user and group (with setgid followed by setuid), and doesn't take on any other group implied by /etc/passwd (primary group) and /etc/group (supplementary group). I haven't checked that exim behaves this way, but if it doesn't, it's unusual.

You can check what groups the exim process is running as by running grep '^Groups:' /proc/1234/status where 1234 is the PID of an exim process.

You need to make the key file readable by either the Debian-exim user or the Debian-exim group. Make sure ACLs are turned on, then add Debian-exim to the ACL of the key file and any non-public directory leading to it:

setfacl -m group:Debian-exim:r /path/to/key
setfacl -m group:Debian-exim:x /path/to
  • Good explanation. I had thought of ACL but the filesystems currently doesn't have it enabled so I guess I'll start working on that. – dtech Apr 22 '12 at 8:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.