[Dovecot] AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied
I've been pouring over the documentation for dovecot, but can't find a solution to this problem. I recently took over administration of the dovecot email service at the University where I work, and things were going smoothly. We've been creating email accounts for use with JIRA, a bug reporting/tracking system, and one day recently, when I tried to add a new account to JIRA, I got this error returned from dovecot:
"AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied"
I got help from Atlassian, the creators of JIRA, and they sent me links to some forum posts that said that changing the permissions of that user's /var/mail/ directory to 0600 would solve the problem. I changed that and no longer got the error.
Being satisfied that this was a solution, I created a bunch of new email accounts today to replace exchange accounts, and then changed the permissions on all the /var/mail/ directories to 0600. Now I'm getting that error again, even for pre-existing email addresses, including the one that I had previously fixed by changing the permissions the same way. I tried changing some of the older accounts back to 0660, which is what they had before, and I still get the error even after restarting dovecot.
JIRA uses POP, port 110, to connect to the dovecot mail server. I've also had the same problem trying to connect from Mac Mail.
Our JIRA application is used for tracking issues for the UBC Libraries, and those email addresses are critical for the creation of tickets and adding comments to tickets. I am at a loss for what to do.
Can anyone help? Thank you very much for your time.
dovecot -n
2.0.9: /etc/dovecot/dovecot.conf
OS: Linux 2.6.32-131.0.15.el6.x86_64 x86_64 Red Hat Enterprise Linux Server release 6.4 (Santiago)
auth_debug = yes auth_debug_passwords = yes disable_plaintext_auth = no mail_access_groups = mail mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u mail_privileged_group = mail mbox_write_locks = fcntl passdb { driver = pam } ssl_cert = </etc/pki/dovecot/certs/server.crt ssl_key = </etc/pki/dovecot/private/server.key userdb { driver = passwd } protocol pop3 { pop3_uidl_format = %08Xu%08Xv }
Here's an except of the maillog from a recent attempt:
May 8 17:46:49 moose dovecot: auth: Debug: pam(lib.sysadmin,{ip removed}): lookup service=dovecot May 8 17:46:49 moose dovecot: auth: Debug: pam(lib.sysadmin,{ip removed}): #1/1 style=1 msg=Password: May 8 17:46:49 moose dovecot: auth: Debug: client out: OK#0111#011user=lib.sysadmin May 8 17:46:49 moose dovecot: auth: Debug: master in: REQUEST#0111028653057#01128298#0111#011a60ed90501af39d7e353a14e027255cd May 8 17:46:49 moose dovecot: auth: Debug: passwd(lib.sysadmin,{ip removed}): lookup May 8 17:46:49 moose dovecot: auth: Debug: master out: USER#0111028653057#011lib.sysadmin#011system_groups_user=lib.sysadmin#011uid=523#011gid=524#011home=/home/lib.sysadmin May 8 17:46:49 moose dovecot: pop3-login: Login: user=<lib.sysadmin>, method=PLAIN, rip={ip removed}, lip={ip removed}, mpid=28302 May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error: stat(/var/spool/mail/lib.sysadmin) failed: Permission denied May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error: stat(/var/spool/mail/lib.sysadmin) failed: Permission denied May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Error: Couldn't open INBOX: Permission denied May 8 17:46:49 moose dovecot: pop3(lib.sysadmin): Couldn't open INBOX top=0/0, retr=0/0, del=0/0, size=0 May 8 17:46:50 moose dovecot: auth: Debug: auth client connected (pid=28303) May 8 17:46:50 moose dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=pop3#011lip={ip removed}#011rip={ip removed}#011lport=110#011rport=64420#011resp=AGJ2YXV3LnJlbGFpcwByM2xAaXMuYnZAdXc=
At 12AM +0000 on 9/05/13 you (Earles, Jill) wrote:
I've been pouring over the documentation for dovecot, but can't find a solution to this problem. I recently took over administration of the dovecot email service at the University where I work, and things were going smoothly. We've been creating email accounts for use with JIRA, a bug reporting/tracking system, and one day recently, when I tried to add a new account to JIRA, I got this error returned from dovecot:
"AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied"
This is not a dovecot message: presumably it's from JIRA?
I got help from Atlassian, the creators of JIRA, and they sent me links to some forum posts that said that changing the permissions of that user's /var/mail/ directory to 0600 would solve the problem. I changed that and no longer got the error.
You say '/var/mail directory' but your dovecot.conf suggests you mean a file in /var/spool/mail. You need to be clear about which you mean.
Dovecot changes down to the user's uid to access the mail folders, so assuming the owners are correct either 0600 or 0660 should be fine. (Which you choose depends on how paranoid you are about users reading each others' mail, and what the group ownership is.)
Being satisfied that this was a solution, I created a bunch of new email accounts today to replace exchange accounts, and then changed the permissions on all the /var/mail/ directories to 0600. Now I'm getting that error again, even for pre-existing email addresses, including the one that I had previously fixed by changing the permissions the same way. I tried changing some of the older accounts back to 0660, which is what they had before, and I still get the error even after restarting dovecot. [...]
dovecot -n
2.0.9: /etc/dovecot/dovecot.conf
OS: Linux 2.6.32-131.0.15.el6.x86_64 x86_64 Red Hat Enterprise Linux Server release 6.4 (Santiago)
auth_debug = yes auth_debug_passwords = yes
Careful with this. You end up with passwords in the logs.
[...]
Here's an except of the maillog from a recent attempt: [...]
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.
May 8 17:46:50 moose dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=pop3#011lip={ip removed}#011rip={ip removed}#011lport=110#011rport=64420#011resp=XXXXXXXXXXXXXXXXXXXX
See? You've just posted the password for 'bvauw.relais'. Change it, now.
Ben
Thank you very much for your quick response. Problem solved (see below for details).
On 2013-05-08, at 6:47 PM, Ben Morrow <ben@morrow.me.uk> wrote:
At 12AM +0000 on 9/05/13 you (Earles, Jill) wrote:
I've been pouring over the documentation for dovecot, but can't find a solution to this problem. I recently took over administration of the dovecot email service at the University where I work, and things were going smoothly. We've been creating email accounts for use with JIRA, a bug reporting/tracking system, and one day recently, when I tried to add a new account to JIRA, I got this error returned from dovecot:
"AuthenticationFailedException: [IN-USE] Couldn't open INBOX: Permission denied"
This is not a dovecot message: presumably it's from JIRA?
You're right, that is how JIRA translated the message it got from dovecot. The message I found in the dovecot log was very similar.
I got help from Atlassian, the creators of JIRA, and they sent me links to some forum posts that said that changing the permissions of that user's /var/mail/ directory to 0600 would solve the problem. I changed that and no longer got the error.
You say '/var/mail directory' but your dovecot.conf suggests you mean a file in /var/spool/mail. You need to be clear about which you mean.
Sorry about that. There is a symlink between the two. Yes, I changed it on /var/spool/mail.
Dovecot changes down to the user's uid to access the mail folders, so assuming the owners are correct either 0600 or 0660 should be fine. (Which you choose depends on how paranoid you are about users reading each others' mail, and what the group ownership is.
Being satisfied that this was a solution, I created a bunch of new email accounts today to replace exchange accounts, and then changed the permissions on all the /var/mail/ directories to 0600. Now I'm getting that error again, even for pre-existing email addresses, including the one that I had previously fixed by changing the permissions the same way. I tried changing some of the older accounts back to 0660, which is what they had before, and I still get the error even after restarting dovecot. [...]
dovecot -n
2.0.9: /etc/dovecot/dovecot.conf
OS: Linux 2.6.32-131.0.15.el6.x86_64 x86_64 Red Hat Enterprise Linux Server release 6.4 (Santiago)
auth_debug = yes auth_debug_passwords = yes
Careful with this. You end up with passwords in the logs.
I'll get rid of this - was just grasping at straws trying to find a solution.
[...]
Here's an except of the maillog from a recent attempt: [...]
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.
So glad it was a simple thing after all. And, as stupid as I feel for doing this, it's a much better feeling than having taken down the mail server and not knowing how to fix it.
May 8 17:46:50 moose dovecot: auth: Debug: client in: AUTH#0111#011PLAIN#011service=pop3#011lip={ip removed}#011rip={ip removed}#011lport=110#011rport=64420#011resp=XXXXXXXXXXXXXXXXXXXX
See? You've just posted the password for 'bvauw.relais'. Change it, now.
Damn, and there I was thinking I'd been careful about removing the sensitive stuff. It's been changed.
Ben
Thank you again. Have a great day.
Jill
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
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
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
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@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@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
At 4AM +0000 on 9/05/13 you (Earles, Jill) 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.
These are standard mail jargon, so you'll probably come across them again. MTA is Mail Transfer Agent, that is, the program which receives incoming mail (usually by SMTP) and decides what to do with it. Traditionally on Unix this was Sendmail; nowadays it might be Postfix or Exim or something instead.
MDA is Mail Delivery Agent, and it's the program the MTA hands a mail to when it decides to deliver it to a local user. (You may also see LDA, Local Delivery Agent, used for the same thing.) Traditionally this was often mail(1) or something equally unsuitable; nowadays it might be procmail or maildrop or something else. Dovecot provides an MDA called 'deliver' or 'dovecot-lda' (they're the same program) which it's often worth using if you haven't got a good reason not to.
Other terms are: MUA, Mail User Agent, which is a program users use to read mail; and MSA, Mail Submission Agent, which is the program users use to submit new mail for delivery; traditionally this was sendmail(8), but now it's more usual to have a special-purpose SMTP server, often running on port 587. (Users should not submit mail directly to MX SMTP servers, because generally mail needs to be cleaned up before being sent off-site.)
From the point-of-view of the mail system, a POP/IMAP server like Dovecot is considered part of the MUA, the other part being the user's actual client; this arrangement, and the corresponding actual- client/submission-server split for outgoing mail, is often called 'split-client'.
Ben
Thank you very much for the additional context.
On 2013-05-08, at 9:40 PM, Ben Morrow <ben@morrow.me.uk> wrote:
At 4AM +0000 on 9/05/13 you (Earles, Jill) 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.
These are standard mail jargon, so you'll probably come across them again. MTA is Mail Transfer Agent, that is, the program which receives incoming mail (usually by SMTP) and decides what to do with it. Traditionally on Unix this was Sendmail; nowadays it might be Postfix or Exim or something instead.
MDA is Mail Delivery Agent, and it's the program the MTA hands a mail to when it decides to deliver it to a local user. (You may also see LDA, Local Delivery Agent, used for the same thing.) Traditionally this was often mail(1) or something equally unsuitable; nowadays it might be procmail or maildrop or something else. Dovecot provides an MDA called 'deliver' or 'dovecot-lda' (they're the same program) which it's often worth using if you haven't got a good reason not to.
Other terms are: MUA, Mail User Agent, which is a program users use to read mail; and MSA, Mail Submission Agent, which is the program users use to submit new mail for delivery; traditionally this was sendmail(8), but now it's more usual to have a special-purpose SMTP server, often running on port 587. (Users should not submit mail directly to MX SMTP servers, because generally mail needs to be cleaned up before being sent off-site.)
From the point-of-view of the mail system, a POP/IMAP server like Dovecot is considered part of the MUA, the other part being the user's actual client; this arrangement, and the corresponding actual- client/submission-server split for outgoing mail, is often called 'split-client'.
Ben
participants (2)
-
Ben Morrow
-
Earles, Jill