0750 seems to work just fine.
I would like to know about MTA and MDA if you're willing to give me a quick rundown.
Thank you very much for all of your help.
On 2013-05-08, at 9:11 PM, "Earles, Jill" jill.earles@ubc.ca wrote:
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 ben@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