Wow, that is a lot of detail. Thank you very much. I appreciate the Unix security perspective - that's something I'm trying to learn more about and be more in tune with as a new systems administrator.
We are not using dotlocks, and the adduser command does create all the mailbox files with the correct ownership automatically. I don't know what MTA or MDA are. Based on what you've said, I think I'll try changing it to 0750 and see how things go. Best to start with the least privileges and go from there. On 2013-05-08, at 8:30 PM, Ben Morrow <b...@morrow.me.uk> wrote: > At 2AM +0000 on 9/05/13 you (Earles, Jill) wrote: >>>> >>>> May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error: >>>> stat(/var/spool/mail/lib.sysadmin) failed: Permission denied >>> >>> This is interesting: normally stat only fails if the permissions on the >>> directory (that is, /var/spool/mail itself) are wrong. Check you haven't >>> changed them by mistake. >> >> Yes, that was it. Thank you! Do you know what the permissions should >> be on that directory? I used 0770 for now, but could change it if >> that's not ideal. > > Well, there are basically three possibilities. If Dovecot is not using > dotlocks (see http://wiki2.dovecot.org/MailboxFormat/mbox), and nothing > else is either, you can probably get away with 0755, provided you > precreate mailbox files for all users with the correct ownership. (On > some systems the 'adduser' command or local equivalent will do this for > you, or can be instructed to.) If all mail-reading and -writing programs > will run with group 'mail', you can reduce that to 0750 root:mail; I > noticed before you were using mail_privileged_group, so the Dovecot > mail processes will run with group mail; you would need to check your > MTA's configuration to see what rights your MDA runs with, and also > check if there are any other processes accessing the mailboxes directly. > > If you are using dotlocks, then anything accessing the mbox files needs > to be able to create .lock files, which means it needs write access to > the directory. If all the relevant programs run with the 'mail' group, > either by being setgid mail or by being given that group some other way, > then 1770 root:mail is the safest option. This at least limits the > potential damage to processes running with the 'mail' group, but it's > worth having the sticky bit to ensure users can't delete each others' > mail: see below. > > If you can't arrange for this, you have to use 1777, that is, world- > writable and sticky. The sticky bit (bit 1000) provides some minimal > protection against the insanity of making the directory world-writable, > by forbidding a process from deleting a file it didn't create. This at > least stops a rogue process from deleting some else's mail, but it > doesn't stop them from creating a mailbox for someone that doesn't have > one, nor does it stop them from (dot-)locking a mailbox which isn't > locked, and leaving it locked indefinitely. > > All of this is dreadfully insecure, especially if you're using dotlocks, > and the contortions Dovecot has to go through to delete a message from a > mailbox without needing write access to the directory are just > grotesque. In general, it's worth avoiding mbox if you can. > > [Note: I currently have my 'Unix security' hat on. It's not actually > *that* insecure, on the scale of 'silly insecure things people routinely > do without realising they're insecure'... :)] > > Ben >
