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

[Earles, Jill]

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 at 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
>