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

[Earles, Jill]

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