[Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied

[Ben Morrow]

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