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

[Earles, Jill]

I should have done more work myself before writing that last message.  I quickly found that MTA is Mail Transfer Agent.  In my case, this is Postfix.  And MDA is Mail Delivery Agent, in my case, this is Dovecot LDA.  More details to read at http://wiki.dovecot.org/LDA/Postfix.

Thanks again, Ben, for writing all you have about this.  I know a lot more about this system that I did before I made this mistake, which is great. 

Cheers

On 2013-05-08, at 9:25 PM, "Earles, Jill" <jdearles at mail.ubc.ca>
 wrote:

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