2

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
-----BEGIN RSA PRIVATE KEY-----
...
-----END RSA PRIVATE 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)?

1 Answer 1

2

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
1
  • 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
    Commented Apr 22, 2012 at 8:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .