[Dovecot] problems with dotlock
I have to make dotlock work because this openwebmail thing
only supports one of dotlock or flock, but procmail delivery
does dotlock and fcntl. procmail correctly creates a
dotlock file in /var/spool/mail/username.lock when
delivering, I can watch this with while :; do ls -la | grep lock; done.
It works fine when lock_method=fcntl, but no dotlock file shows up in /var/spool/mail. mbox_write_locks are working correctly with mbox_write_locks = dotlock fcntl, the dotlock file shows up in the user's mail directory.
However, dotlocking /var/spool/mail doesn't work:
$ ls -la /var/spool/mail total 44 drwxrwxr-x 2 root mail 4096 Feb 25 17:39 .
$ grep mail_privileged_group /etc/mail/dovecot.conf mail_privileged_group = mail
Feb 25 17:45:45 anubis dovecot: POP3(despam_test_anubis): Effective uid=511, gid=100
Feb 25 17:45:45 anubis dovecot: POP3(despam_test_anubis): mbox: data=/home/anubis/despam_test_anubis/mail:INBOX=/var/spool/mail/despam_test_anubis
Feb 25 17:45:45 anubis dovecot: POP3(despam_test_anubis): mbox: root=/home/anubis/despam_test_anubis/mail, index=/home/anubis/despam_test_anubis/mail, inbox=/var/spool/mail/despam_test_anubis
Feb 25 17:45:45 anubis dovecot: POP3(despam_test_anubis): file_lock_dotlock() failed with mbox file /var/spool/mail/despam_test_anubis: Permission denied
Feb 25 17:45:45 anubis dovecot: POP3(despam_test_anubis): Couldn't open INBOX: Internal error occurred. Refer to server log for more information. [2009-02-25 17:45:45]
Feb 25 17:45:45 anubis dovecot: POP3(despam_test_anubis): Couldn't open INBOX top=0/0, retr=0/0, del=0/0, size=0
Feb 25 17:45:45 anubis dovecot: pop3-login: Login: user=
gid=100 = group 'users'.
I tried making all of the binaries root:mail with g+s, same as /usr/bin/lockfile, but this was no help.
It also does not help to chmod +t /var/spool/mail.
$ dovecot --version 1.0.7
kernel 2.6.18-92.1.22.el5 centos
mmap_disable = yes (req'd for ~/mail dotlocks, makes no difference either way for /var/spool/mail)
Any ideas?
Thanks, Mark
On Feb 25, 2009, at 8:55 PM, Mark Hedges wrote:
I tried making all of the binaries root:mail with g+s, same as /usr/bin/lockfile, but this was no help.
It doesn't, because Dovecot starts them as root and then changes the
privileges.
It also does not help to chmod +t /var/spool/mail.
Maybe not alone, but this should work:
chmod 0777 /var/spool/mail chmod +t /var/spool/mail
Or you could set mail_access_groups (or perhaps it's still called
mail_extra_groups in your version) to "mail", assuming /var/spool/mail
was owned by group mail and was group-writable.
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Feb 25, 2009, at 8:55 PM, Mark Hedges wrote:
I tried making all of the binaries root:mail with g+s, same as /usr/bin/lockfile, but this was no help.
It doesn't, because Dovecot starts them as root and then changes the privileges.
Or you could set mail_access_groups (or perhaps it's still called mail_extra_groups in your version) to "mail", assuming /var/spool/mail was owned by group mail and was group-writable.
Setting mail_access_groups works, but the documentation says this is what the mail_privileged_group setting was for:
# Group to enable temporarily for privileged operations. Currently this is # used only for creating mbox dotlock files when creation fails for INBOX. # Typically this is set to "mail" to give access to /var/mail. mail_privileged_group = mail
# Grant access to these supplementary groups for mail processes. Typically # these are used to set up access to shared mailboxes. Note that it may be # dangerous to set these if users can create symlinks (e.g. if "mail" group is # set here, ln -s /var/mail ~/mail/var could allow a user to delete others' # mailboxes, or ln -s /secret/shared/box ~/mail/mybox would allow reading it). #mail_access_groups =
I don't want to set up access for shared mailboxes. Now I am depending on the webmail system not to allow access outside their home directory, which it seems to do okay, so this works, but it doesn't seem as secure.
Is it possible that dovecot internally forgets that creating the dotlock file is a "privileged operation"?
Mark
On Thu, 2009-02-26 at 10:01 -0800, Mark Hedges wrote:
Or you could set mail_access_groups (or perhaps it's still called mail_extra_groups in your version) to "mail", assuming /var/spool/mail was owned by group mail and was group-writable.
Setting mail_access_groups works, but the documentation says this is what the mail_privileged_group setting was for:
Oh, right, that's what I meant.
Is it possible that dovecot internally forgets that creating the dotlock file is a "privileged operation"?
So you're saying that setting mail_privileged_group doesn't work? Perhaps this setting is then buggy in Redhat's version?
On Thu, 26 Feb 2009, Timo Sirainen wrote:
Setting mail_access_groups works, but the documentation says this is what the mail_privileged_group setting was for:
Oh, right, that's what I meant.
Is it possible that dovecot internally forgets that creating the dotlock file is a "privileged operation"?
So you're saying that setting mail_privileged_group doesn't work? Perhaps this setting is then buggy in Redhat's version?
Right, mail_privileged_group does not work. Setting mail_access_groups = mail does work.
The problem is the same in v1.1.11, which is the latest stable version from the atrpms site linked from dovecot.org download for binary packages.
Also, how do I get imap to use a dotlock file when accessing the inbox? Similar to pop3_lock_session. Am I confused on how imap works?
Mark
On Thu, 2009-02-26 at 12:59 -0800, Mark Hedges wrote:
Right, mail_privileged_group does not work. Setting mail_access_groups = mail does work.
The problem is the same in v1.1.11, which is the latest stable version from the atrpms site linked from dovecot.org download for binary packages.
Would it be possible for you to try a patched v1.1.11 version? http://hg.dovecot.org/dovecot-1.1/raw-rev/51f4b25c7bd3 should give a better error message that could help figuring out why it doesn't work.
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 12:59 -0800, Mark Hedges wrote:
Right, mail_privileged_group does not work. Setting mail_access_groups = mail does work.
The problem is the same in v1.1.11, which is the latest stable version from the atrpms site linked from dovecot.org download for binary packages.
Would it be possible for you to try a patched v1.1.11 version? http://hg.dovecot.org/dovecot-1.1/raw-rev/51f4b25c7bd3 should give a better error message that could help figuring out why it doesn't work.
I tried building from the 1.1.11 source with your patch, and
copied the same config file into
/usr/local/etc/dovecot/dovecot.conf, but now pop3 doesn't
start when I run /usr/local/sbin/dovecot. imap-login is
running, but pop3-login is not. What do I do to get pop3 to
run so I can check out the problem?
Mark
On Thu, 26 Feb 2009, Mark Hedges wrote:
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 12:59 -0800, Mark Hedges wrote:
Right, mail_privileged_group does not work. Setting mail_access_groups = mail does work.
The problem is the same in v1.1.11, which is the latest stable version from the atrpms site linked from dovecot.org download for binary packages.
Would it be possible for you to try a patched v1.1.11 version? http://hg.dovecot.org/dovecot-1.1/raw-rev/51f4b25c7bd3 should give a better error message that could help figuring out why it doesn't work.
Somehow it ran okay when I copied and modified the example conf file with the same changes. I guess you have to explicitly turn on pop3 now. Here is the log output:
Feb 26 14:14:06 anubis dovecot: auth(default): client in: AUTH 1 PLAIN service=pop3 secured lip=127.0.0.1 rip=127.0.0.1 lport=110 rport=48531 resp=<hidden>
Feb 26 14:14:06 anubis dovecot: auth-worker(default): pam(despam_test_anubis,127.0.0.1): lookup service=dovecot
Feb 26 14:14:06 anubis dovecot: auth-worker(default): pam(despam_test_anubis,127.0.0.1): #1/1 style=1 msg=Password:
Feb 26 14:14:06 anubis dovecot: auth(default): client out: OK 1 user=despam_test_anubis
Feb 26 14:14:06 anubis dovecot: auth(default): master in: REQUEST 1 25788 1
Feb 26 14:14:06 anubis dovecot: auth(default): passwd(despam_test_anubis,127.0.0.1): lookup
Feb 26 14:14:06 anubis dovecot: auth(default): master out: USER 1 despam_test_anubis system_user=despam_test_anubis uid=511 gid=100 home=/home/anubis/despam_test_anubis
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
Feb 26 14:14:06 anubis dovecot: POP3(despam_test_anubis): Effective uid=511, gid=100
Feb 26 14:14:06 anubis dovecot: POP3(despam_test_anubis): mbox: data=~/mail:INBOX=/var/spool/mail/despam_test_anubis
Feb 26 14:14:06 anubis dovecot: POP3(despam_test_anubis): fs: root=/home/anubis/despam_test_anubis/mail, index=, control=, inbox=/var/spool/mail/despam_test_anubis
Feb 26 14:14:06 anubis dovecot: POP3(despam_test_anubis): file_dotlock_create(/var/spool/mail/despam_test_anubis) failed: Permission denied (euid=511(despam_test_anubis) egid=100(users) missing +w perm: /var/spool/mail) (set mail_privileged_group=mail)
Feb 26 14:14:06 anubis dovecot: pop3-login: Login: user=
It isn't setting egid to 12(mail) like it should.
Thanks for your help.
What about IMAP and dotlock files? I need dotlock files for inbox and all the folders to keep openwebmail from trying to change the folders while an IMAP connection is open. It's probably not too likely in our scenario anyway so it won't be a showstopper, but is that possible?
Mark
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
It shouldn't be crashing. Could you get a gdb backtrace from this? http://dovecot.org/bugreport.html
Feb 26 14:14:06 anubis dovecot: POP3(despam_test_anubis): file_dotlock_create(/var/spool/mail/despam_test_anubis) failed: Permission denied (euid=511(despam_test_anubis) egid=100(users) missing +w perm: /var/spool/mail) (set mail_privileged_group=mail) .. It isn't setting egid to 12(mail) like it should.
One more try, what does it log after applying also this patch: http://hg.dovecot.org/dovecot-1.1/raw-rev/8c99c4d2eaad
What about IMAP and dotlock files? I need dotlock files for inbox and all the folders to keep openwebmail from trying to change the folders while an IMAP connection is open. It's probably not too likely in our scenario anyway so it won't be a showstopper, but is that possible?
No. That would break multiple IMAP connections and it would also prevent new mail from being delivered to the mailboxes.
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
It shouldn't be crashing. Could you get a gdb backtrace from this? http://dovecot.org/bugreport.html
I set mail_drop_priv_before_exec = yes, and I did ulimit -c unlimited and echo "/tmp/core" > /proc/sys/kernel/core_pattern before starting dovecot, but
I still didn't get a core dump anywhere. Seems like the
home directory is okay. No core file. Even looked
everywhere with locate after updatedb. Is this a reason
I can say that CentOS sucks too much to use in production?
;-)
Feb 26 14:14:06 anubis dovecot: POP3(despam_test_anubis): file_dotlock_create(/var/spool/mail/despam_test_anubis) failed: Permission denied (euid=511(despam_test_anubis) egid=100(users) missing +w perm: /var/spool/mail) (set mail_privileged_group=mail) .. It isn't setting egid to 12(mail) like it should.
One more try, what does it log after applying also this patch: http://hg.dovecot.org/dovecot-1.1/raw-rev/8c99c4d2eaad
Feb 26 14:52:05 anubis dovecot: auth(default): client in: AUTH 1 PLAIN service=pop3 secured lip=127.0.0.1 rip=127.0.0.1 lport=110 rport=37079 resp=<hidden>
Feb 26 14:52:05 anubis dovecot: auth-worker(default): pam(despam_test_anubis,127.0.0.1): lookup service=dovecot
Feb 26 14:52:05 anubis dovecot: auth-worker(default): pam(despam_test_anubis,127.0.0.1): #1/1 style=1 msg=Password:
Feb 26 14:52:05 anubis dovecot: auth(default): client out: OK 1 user=despam_test_anubis
Feb 26 14:52:05 anubis dovecot: auth(default): master in: REQUEST 1 28152 1
Feb 26 14:52:05 anubis dovecot: auth(default): passwd(despam_test_anubis,127.0.0.1): lookup
Feb 26 14:52:05 anubis dovecot: auth(default): master out: USER 1 despam_test_anubis system_user=despam_test_anubis uid=511 gid=100 home=/home/anubis/despam_test_anubis
Feb 26 14:52:05 anubis dovecot: POP3(despam_test_anubis): Effective uid=511, gid=100
Feb 26 14:52:05 anubis dovecot: POP3(despam_test_anubis): mbox: data=~/mail:INBOX=/var/spool/mail/despam_test_anubis
Feb 26 14:52:05 anubis dovecot: POP3(despam_test_anubis): fs: root=/home/anubis/despam_test_anubis/mail, index=, control=, inbox=/var/spool/mail/despam_test_anubis
Feb 26 14:52:05 anubis dovecot: POP3(despam_test_anubis): file_dotlock_create(/var/spool/mail/despam_test_anubis) failed: Permission denied (euid=511(despam_test_anubis) egid=100(users) missing +w perm: /var/spool/mail) (under root dir /home/anubis/despam_test_anubis/mail -> no privileged locking)
Feb 26 14:52:05 anubis dovecot: pop3-login: Login: user=
on 2-26-2009 3:04 PM Mark Hedges spake the following:
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11 It shouldn't be crashing. Could you get a gdb backtrace from this? http://dovecot.org/bugreport.html
I set mail_drop_priv_before_exec = yes, and I did
ulimit -c unlimitedandecho "/tmp/core" > /proc/sys/kernel/core_patternbefore starting dovecot, but I still didn't get a core dump anywhere. Seems like the home directory is okay. No core file. Even looked everywhere withlocateafterupdatedb. Is this a reason I can say that CentOS sucks too much to use in production? ;-)
Thousands (if not hundreds of thousands) of people are using CentOS in production. What makes you think it is CentOS? Just because you are trying to use a poorly (maybe inadequately is a better word) written application like openwebmail doesn't fault the OS.
Openwebmail was written to use setuid perl which has been less than safe for years. It doesn't do fcntl locking, which it probably should at least be able to do to stay current with many MTA's. It also does direct access to the mail store instead of going through an IMAP daemon. So that adds another point of contention.
It would probably be fine if it was the only access for mail, or maybe along with pop3. But throw in an IMAP mua, and maybe sieve or fancy procmail scripts and you have an accident waiting to happen.
I still have openwebmail running on one of my older servers, but it will go away when I get migrated to the replacement. It works only because the people that are using it don't access their mail with anything else. Even usermin from the webmin stable of progs does better access to mail in terms of versatility, although it is kind of ugly looking.
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
on 2-26-2009 3:25 PM Scott Silva spake the following:
on 2-26-2009 3:04 PM Mark Hedges spake the following:
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11 It shouldn't be crashing. Could you get a gdb backtrace from this? http://dovecot.org/bugreport.html I set mail_drop_priv_before_exec = yes, and I did
ulimit -c unlimitedandecho "/tmp/core" > /proc/sys/kernel/core_patternbefore starting dovecot, but I still didn't get a core dump anywhere. Seems like the home directory is okay. No core file. Even looked everywhere withlocateafterupdatedb. Is this a reason I can say that CentOS sucks too much to use in production? ;-)Thousands (if not hundreds of thousands) of people are using CentOS in production. What makes you think it is CentOS? Just because you are trying to use a poorly (maybe inadequately is a better word) written application like openwebmail doesn't fault the OS.
Openwebmail was written to use setuid perl which has been less than safe for years. It doesn't do fcntl locking, which it probably should at least be able to do to stay current with many MTA's. It also does direct access to the mail store instead of going through an IMAP daemon. So that adds another point of contention.
It would probably be fine if it was the only access for mail, or maybe along with pop3. But throw in an IMAP mua, and maybe sieve or fancy procmail scripts and you have an accident waiting to happen.
I still have openwebmail running on one of my older servers, but it will go away when I get migrated to the replacement. It works only because the people that are using it don't access their mail with anything else. Even usermin from the webmin stable of progs does better access to mail in terms of versatility, although it is kind of ugly looking.
I just wanted to back off a little since the OP is only using openwebmail by "suggestion" from the one who signs his paycheck. We have all been backed into that corner before!
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
On Thu, 26 Feb 2009, Scott Silva wrote:
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11 It shouldn't be crashing. Could you get a gdb backtrace from this? http://dovecot.org/bugreport.html
I set mail_drop_priv_before_exec = yes, and I did
ulimit -c unlimitedandecho "/tmp/core" > /proc/sys/kernel/core_patternbefore starting dovecot, but I still didn't get a core dump anywhere. Seems like the home directory is okay. No core file. Even looked everywhere withlocateafterupdatedb. Is this a reason I can say that CentOS sucks too much to use in production? ;-)Thousands (if not hundreds of thousands) of people are using CentOS in production. What makes you think it is CentOS? Just because you are trying to use a poorly (maybe inadequately is a better word) written application like openwebmail doesn't fault the OS.
This particular facet of the problem doesn't have anything to do with openwebmail. Do you know how to get core files to work for dovecot under CentOS 5.2? Because it's not working according to the dovecot instructions. If you happen to have any useful information, thank you.
Mark
on 2-26-2009 3:29 PM Mark Hedges spake the following:
On Thu, 26 Feb 2009, Scott Silva wrote:
On Thu, 26 Feb 2009, Timo Sirainen wrote:
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11 It shouldn't be crashing. Could you get a gdb backtrace from this? http://dovecot.org/bugreport.html I set mail_drop_priv_before_exec = yes, and I did
ulimit -c unlimitedandecho "/tmp/core" > /proc/sys/kernel/core_patternbefore starting dovecot, but I still didn't get a core dump anywhere. Seems likeOn Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote: the home directory is okay. No core file. Even looked everywhere with
locateafterupdatedb. Is this a reason I can say that CentOS sucks too much to use in production? ;-) Thousands (if not hundreds of thousands) of people are using CentOS in production. What makes you think it is CentOS? Just because you are trying to use a poorly (maybe inadequately is a better word) written application like openwebmail doesn't fault the OS.This particular facet of the problem doesn't have anything to do with openwebmail. Do you know how to get core files to work for dovecot under CentOS 5.2? Because it's not working according to the dovecot instructions. If you happen to have any useful information, thank you.
Mark
http://kbase.redhat.com/faq/docs/DOC-4897 shows how to enable core dumps in RedHat and CentOS. It is set in /etc/profile, so it would need to be temporarily edited there.
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
On Thu, 2009-02-26 at 15:04 -0800, Mark Hedges wrote:
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
It shouldn't be crashing. Could you get a gdb backtrace from this? http://dovecot.org/bugreport.html
I set mail_drop_priv_before_exec = yes, and I did
ulimit -c unlimitedandecho "/tmp/core" > /proc/sys/kernel/core_patternbefore starting dovecot, but I still didn't get a core dump anywhere. Seems like the home directory is okay. No core file.
When Dovecot starts up, it logs a line:
Info: Dovecot v1.1.11 starting up
Do you see it, or do you see:
Info: Dovecot v1.1.11 starting up (core dumps disabled)
Feb 26 14:52:05 anubis dovecot: POP3(despam_test_anubis): file_dotlock_create(/var/spool/mail/despam_test_anubis) failed: Permission denied (euid=511(despam_test_anubis) egid=100(users) missing +w perm: /var/spool/mail) (under root dir /home/anubis/despam_test_anubis/mail -> no privileged locking)
Well, that is weird. What does it log with the attached patch?
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 15:04 -0800, Mark Hedges wrote:
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11
It shouldn't be crashing. Could you get a gdb backtrace from this? http://dovecot.org/bugreport.html
I set mail_drop_priv_before_exec = yes, and I did
ulimit -c unlimitedandecho "/tmp/core" > /proc/sys/kernel/core_patternbefore starting dovecot, but I still didn't get a core dump anywhere. Seems like the home directory is okay. No core file.When Dovecot starts up, it logs a line:
Info: Dovecot v1.1.11 starting up
Do you see it, or do you see:
Info: Dovecot v1.1.11 starting up (core dumps disabled)
Feb 27 13:32:37 anubis dovecot: dovecot v1.1.11 starting up Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2610 Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2611 Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2613 Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2614 Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2615 Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2612
On Thu, 26 Feb 2009, Scott Silva wrote:
http://kbase.redhat.com/faq/docs/DOC-4897 shows how to enable core dumps in RedHat and CentOS. It is set in /etc/profile, so it would need to be temporarily edited there.
Thanks for trying to help, I tried this too, but as I reported earlier, I had tried according to the dovecot bug report instructions by setting ulimit from the shell before I started this build. Still no core. (Debian rules! *ahem*)
On Thu, 26 Feb 2009, Timo Sirainen wrote:
Well, that is weird. What does it log with the attached patch?
Patch didn't work. Attached rej. I think you forgot some {}'s so I think I did what you wanted with the attached diff. Here's the log output now:
Feb 27 13:33:59 anubis dovecot: auth(default): client in: AUTH 1 PLAIN service=pop3 secured lip=127.0.0.1 rip=127.0.0.1 lport=110 rport=49669 resp=<hidden>
Feb 27 13:33:59 anubis dovecot: auth-worker(default): pam(despam_test_anubis,127.0.0.1): lookup service=dovecot
Feb 27 13:33:59 anubis dovecot: auth-worker(default): pam(despam_test_anubis,127.0.0.1): #1/1 style=1 msg=Password:
Feb 27 13:33:59 anubis dovecot: auth(default): client out: OK 1 user=despam_test_anubis
Feb 27 13:33:59 anubis dovecot: auth(default): master in: REQUEST 1 2611 1
Feb 27 13:33:59 anubis dovecot: auth(default): passwd(despam_test_anubis,127.0.0.1): lookup
Feb 27 13:33:59 anubis dovecot: auth(default): master out: USER 1 despam_test_anubis system_user=despam_test_anubis uid=511 gid=100 home=/home/anubis/despam_test_anubis
Feb 27 13:33:59 anubis dovecot: child 2634 (pop3) killed with signal 11
Feb 27 13:33:59 anubis dovecot: POP3(despam_test_anubis): Effective uid=511, gid=100
Feb 27 13:33:59 anubis dovecot: POP3(despam_test_anubis): mbox: data=~/mail:INBOX=/var/spool/mail/despam_test_anubis
Feb 27 13:33:59 anubis dovecot: POP3(despam_test_anubis): fs: root=/home/anubis/despam_test_anubis/mail, index=, control=, inbox=/var/spool/mail/despam_test_anubis
Feb 27 13:33:59 anubis dovecot: POP3(despam_test_anubis): file_dotlock_create(/var/spool/mail/despam_test_anubis) failed: Permission denied (euid=511(despam_test_anubis) egid=100(users) missing +w perm: /var/spool/mail) (under root dir /home/anubis/despam_test_anubis/mail -> no privileged locking)
Feb 27 13:33:59 anubis dovecot: pop3-login: Login: user=
Mark
On Fri, 2009-02-27 at 13:40 -0800, Mark Hedges wrote:
It shouldn't be crashing. Could you get a gdb backtrace from this? http://dovecot.org/bugreport.html
I set mail_drop_priv_before_exec = yes, and I did
ulimit -c unlimitedandecho "/tmp/core" > /proc/sys/kernel/core_patternbefore starting dovecot, but .. Feb 27 13:32:37 anubis dovecot: dovecot v1.1.11 starting up
OK, so core dumps are enabled, but for some reason they don't get written. There are really only two possibilities then:
a) You don't really have mail_drop_priv_before_exec=yes. You could verify this with dovecot -n.
b) Kernel doesn't want to write the core to /tmp/core or before changing that it didn't want to write it to user's home directory.
Well, that is weird. What does it log with the attached patch?
Patch didn't work. Attached rej. I think you forgot some {}'s so I think I did what you wanted with the attached diff. Here's the log output now:
Your version of the patch looked ok, but why didn't the warning get written to the log? If you didn't somehow forget make install or something similar, the only reason is then if mbox->mbox_privileged_locking=TRUE. But the later code says that it's FALSE.
Try adding one more thing before the return line:
i_warning("privileged=%d", mbox->mbox_privileged_locking);
Also are you using any plugins? Paste your dovecot -n output?
On Fri, 27 Feb 2009, Timo Sirainen wrote:
OK, so core dumps are enabled, but for some reason they don't get written. There are really only two possibilities then:
a) You don't really have mail_drop_priv_before_exec=yes. You could verify this with dovecot -n.
[root@anubis etc]# /usr/local/sbin/dovecot -n | grep drop mail_drop_priv_before_exec: yes
b) Kernel doesn't want to write the core to /tmp/core or before changing that it didn't want to write it to user's home directory.
[root@anubis etc]# grep -i core /boot/config-2.6.18-92.1.22.el5 CONFIG_ELF_CORE=y # Core Netfilter Configuration CONFIG_MLX4_CORE=m CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_I2C_OCORES is not set # CONFIG_I2C_DEBUG_CORE is not set CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y
Is that informative? I would not be surprised if the kernel is buggy. It also indefinitely holds onto network connections in CLOSE_WAIT state, never times them out, and after some list research it seems there's no option to control that, could be wrong, but I gave up.
Your version of the patch looked ok, but why didn't the warning get written to the log? If you didn't somehow forget make install or something similar, the only reason is then if mbox->mbox_privileged_locking=TRUE. But the later code says that it's FALSE.
Try adding one more thing before the return line:
i_warning("privileged=%d", mbox->mbox_privileged_locking);
I added that in mbox-storage.c. Looks like it didn't get
that far. Yes, I did make and make install again, and
watched it recompile mbox-storage.c. Just to verify, I did
make clean and ./configure; make; make install again.
Nothing different.
Feb 27 14:13:16 anubis dovecot: auth(default): client in: AUTH 1 PLAIN service=pop3 secured lip=127.0.0.1 rip=127.0.0.1 lport=110 rport=37310 resp=<hidden>
Feb 27 14:13:16 anubis dovecot: auth(default): client out: OK 1 user=despam_test_anubis
Feb 27 14:13:16 anubis dovecot: auth-worker(default): pam(despam_test_anubis,127.0.0.1): lookup service=dovecot
Feb 27 14:13:16 anubis dovecot: auth-worker(default): pam(despam_test_anubis,127.0.0.1): #1/1 style=1 msg=Password:
Feb 27 14:13:16 anubis dovecot: auth(default): master in: REQUEST 1 18328 1
Feb 27 14:13:16 anubis dovecot: auth(default): passwd(despam_test_anubis,127.0.0.1): lookup
Feb 27 14:13:16 anubis dovecot: auth(default): master out: USER 1 despam_test_anubis system_user=despam_test_anubis uid=511 gid=100 home=/home/anubis/despam_test_anubis
Feb 27 14:13:16 anubis dovecot: child 18346 (pop3) killed with signal 11
Feb 27 14:13:16 anubis dovecot: POP3(despam_test_anubis): Effective uid=511, gid=100
Feb 27 14:13:16 anubis dovecot: POP3(despam_test_anubis): mbox: data=~/mail:INBOX=/var/spool/mail/despam_test_anubis
Feb 27 14:13:16 anubis dovecot: POP3(despam_test_anubis): fs: root=/home/anubis/despam_test_anubis/mail, index=, control=, inbox=/var/spool/mail/despam_test_anubis
Feb 27 14:13:16 anubis dovecot: POP3(despam_test_anubis): file_dotlock_create(/var/spool/mail/despam_test_anubis) failed: Permission denied (euid=511(despam_test_anubis) egid=100(users) missing +w perm: /var/spool/mail) (under root dir /home/anubis/despam_test_anubis/mail -> no privileged locking)
Feb 27 14:13:16 anubis dovecot: pop3-login: Login: user=
Also are you using any plugins? Paste your dovecot -n output?
I only compiled fresh 1.1.11 source and left it in /usr/local/. The yum/rpm version is under /usr and it is not running when I do these tests.
A look at lsof shows it's using the right libs for dovecot stuff... hrmm but /lib/libselinux.so.1 is linked, I wonder if that is the problem behind core dumps and these permissions. Hrmm, I set the boot flag selinux=0 and rebooted, but I still get the same errors and see /lib/libselinux.so.1 in lsof. How do I tell if I've turned selinux off?
[root@anubis etc]# /usr/local/sbin/dovecot -n # 1.1.11: /usr/local/etc/dovecot.conf # OS: Linux 2.6.18-92.1.22.el5 i686 CentOS release 5.2 (Final) syslog_facility: local0 protocols: pop3 imap ssl_ca_file: /etc/mail/certs/ca.crt ssl_cert_file: /etc/mail/certs/thishost.crt ssl_key_file: /etc/mail/certs/thishost.key login_dir: /usr/local/var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login mail_privileged_group: mail mail_uid: 8 mail_gid: 12 mail_location: mbox:~/mail:INBOX=/var/spool/mail/%u mail_debug: yes lock_method: dotlock mail_drop_priv_before_exec: yes mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 pop3_lock_session(default): no pop3_lock_session(imap): no pop3_lock_session(pop3): yes auth default: debug: yes passdb: driver: pam userdb: driver: passwd
On Fri, 2009-02-27 at 14:28 -0800, Mark Hedges wrote:
b) Kernel doesn't want to write the core to /tmp/core or before changing that it didn't want to write it to user's home directory.
[root@anubis etc]# grep -i core /boot/config-2.6.18-92.1.22.el5 CONFIG_ELF_CORE=y # Core Netfilter Configuration CONFIG_MLX4_CORE=m CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_I2C_OCORES is not set # CONFIG_I2C_DEBUG_CORE is not set CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y
Is that informative?
core dumping functionality is there, but I guess the problem has more to do with directory owner/permissions where it's writing the core file.
pop3_lock_session(pop3): yes
Ah, this explains everything. Fixed both your problem and the segfault: http://hg.dovecot.org/dovecot-1.1/rev/f831d12187d1
Words by Timo Sirainen [Fri, Feb 27, 2009 at 05:41:39PM -0500]:
On Fri, 2009-02-27 at 14:28 -0800, Mark Hedges wrote:
b) Kernel doesn't want to write the core to /tmp/core or before changing that it didn't want to write it to user's home directory.
[root@anubis etc]# grep -i core /boot/config-2.6.18-92.1.22.el5 CONFIG_ELF_CORE=y # Core Netfilter Configuration CONFIG_MLX4_CORE=m CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_I2C_OCORES is not set # CONFIG_I2C_DEBUG_CORE is not set CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y
Is that informative?
core dumping functionality is there, but I guess the problem has more to do with directory owner/permissions where it's writing the core file.
echo /tmp/core > /proc/sys/kernel/core_pattern
I guess /tmp should be writeable :)
-- Jose Celestino | http://japc.uncovering.org/files/japc-pgpkey.asc
"One man’s theology is another man’s belly laugh." -- Robert A. Heinlein
Words by Jose Celestino [Sat, Feb 28, 2009 at 12:17:24AM +0000]:
Words by Timo Sirainen [Fri, Feb 27, 2009 at 05:41:39PM -0500]:
core dumping functionality is there, but I guess the problem has more to do with directory owner/permissions where it's writing the core file.
echo /tmp/core > /proc/sys/kernel/core_pattern
I guess /tmp should be writeable :)
Oh, that was already suggested. My fault for starting reading the thread from the middle.
-- Jose Celestino | http://japc.uncovering.org/files/japc-pgpkey.asc
"One man’s theology is another man’s belly laugh." -- Robert A. Heinlein
Mark Hedges wrote:
On Fri, 27 Feb 2009, Timo Sirainen wrote:
OK, so core dumps are enabled, but for some reason they don't get written. There are really only two possibilities then:
a) You don't really have mail_drop_priv_before_exec=yes. You could verify this with dovecot -n.
[root@anubis etc]# /usr/local/sbin/dovecot -n | grep drop mail_drop_priv_before_exec: yes
b) Kernel doesn't want to write the core to /tmp/core or before changing that it didn't want to write it to user's home directory.
[root@anubis etc]# grep -i core /boot/config-2.6.18-92.1.22.el5 CONFIG_ELF_CORE=y # Core Netfilter Configuration CONFIG_MLX4_CORE=m CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_I2C_OCORES is not set # CONFIG_I2C_DEBUG_CORE is not set CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y
Is that informative? I would not be surprised if the kernel is buggy. It also indefinitely holds onto network connections in CLOSE_WAIT state, never times them out, and after some list research it seems there's no option to control that, could be wrong, but I gave up.
Totally unrelated to your Dovecot issues, but are you using an Intel card with that kernel? Specifically the e1000 driver is buggy enough in that version that I gave up and use at least kernel 2.6.20.3 with e1000 cards. I wouldn't be surprised if there were other network related issues.
~Seth
on 2-27-2009 1:40 PM Mark Hedges spake the following:
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 15:04 -0800, Mark Hedges wrote:
On Thu, 26 Feb 2009, Timo Sirainen wrote:
On Thu, 2009-02-26 at 14:23 -0800, Mark Hedges wrote:
Feb 26 14:14:06 anubis dovecot: child 25810 (pop3) killed with signal 11 It shouldn't be crashing. Could you get a gdb backtrace from this? http://dovecot.org/bugreport.html I set mail_drop_priv_before_exec = yes, and I did
ulimit -c unlimitedandecho "/tmp/core" > /proc/sys/kernel/core_patternbefore starting dovecot, but I still didn't get a core dump anywhere. Seems like the home directory is okay. No core file. When Dovecot starts up, it logs a line:Info: Dovecot v1.1.11 starting up
Do you see it, or do you see:
Info: Dovecot v1.1.11 starting up (core dumps disabled)
Feb 27 13:32:37 anubis dovecot: dovecot v1.1.11 starting up Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2610 Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2611 Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2613 Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2614 Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2615 Feb 27 13:32:39 anubis dovecot: auth(default): new auth connection: pid=2612
On Thu, 26 Feb 2009, Scott Silva wrote:
http://kbase.redhat.com/faq/docs/DOC-4897 shows how to enable core dumps in RedHat and CentOS. It is set in /etc/profile, so it would need to be temporarily edited there.
Thanks for trying to help, I tried this too, but as I reported earlier, I had tried according to the dovecot bug report instructions by setting ulimit from the shell before I started this build. Still no core. (Debian rules! *ahem*)
Did you do it like that kb article said, or did you just try; ulimit -c unlimited [enter] service dovecot start [enter]
in a shell, because the latter won't work in CentOS because of the way it is setup.
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
On Feb 27, 2009, at 6:31 PM, Scott Silva wrote:
When Dovecot starts up, it logs a line:
Info: Dovecot v1.1.11 starting up
Do you see it, or do you see:
Info: Dovecot v1.1.11 starting up (core dumps disabled) .. Did you do it like that kb article said, or did you just try; ulimit -c unlimited [enter] service dovecot start [enter]
in a shell, because the latter won't work in CentOS because of the
way it is setup.
The startup message that Dovecot v1.1.11 and later give removes this
ulimit confusion. If ulimit -c is 0, Dovecot adds the "core dumps
disabled" message at startup. Although I'm now wondering if it should
also check that the limit is some reasonable size, rather than only 0.
On Fri, 27 Feb 2009, Scott Silva wrote:
On Thu, 26 Feb 2009, Scott Silva wrote:
http://kbase.redhat.com/faq/docs/DOC-4897 shows how ...
Thanks for trying to help, I tried this too, but as I reported earlier, I had tried according to the ...
Did you do it like that kb article said, or did you just try; ulimit -c unlimited [enter] service dovecot start [enter] in a shell, because the latter won't work in CentOS because of the way it is setup.
Thanks for trying to help, but "I tried this too" in response to your suggestion would seem to imply that I tried it the way you suggested.
On Fri, 27 Feb 2009, Timo Sirainen wrote:
core dumping functionality is there, but I guess the problem has more to do with directory owner/permissions where it's writing the core file.
I was never able to get the cores to work. Yes, /tmp was publically writeable and I tried changing kernel_pattern and all that, but none of it worked.
On Fri, 27 Feb 2009, Timo Sirainen wrote:
Ah, this explains everything. Fixed both your problem and the segfault: f831d12187d1
Yes, this patch fixed the problem when applied to pristine 1.1.11 source.
Will there be an update of the RPM at http://atrpms.net/dist/el5/dovecot/? It's hard enough for automating deployment of new servers that I have to use a downloaded RPM instead of using yum, since I doubt CentOS's two-year-old version of 1.0.7 will ever be updated. Compiling from source is a pain but I'll use it for now.
Mark
On Mon, 2009-03-02 at 13:25 -0800, Mark Hedges wrote:
On Fri, 27 Feb 2009, Timo Sirainen wrote:
core dumping functionality is there, but I guess the problem has more to do with directory owner/permissions where it's writing the core file.
I was never able to get the cores to work. Yes, /tmp was publically writeable and I tried changing kernel_pattern and all that, but none of it worked.
I was rather thinking that maybe the kernel doesn't want to write core files to directories that are writable by everyone.
Will there be an update of the RPM at http://atrpms.net/dist/el5/dovecot/?
I guess I'll release 1.1.12 in not too distant future and it should get updated there.
On Mon, 2 Mar 2009, Timo Sirainen wrote:
I was rather thinking that maybe the kernel doesn't want to write core files to directories that are writable by everyone.
Could it be that dovecot uses setuid to change permissions? Application would need 'prctl(PR_SET_DUMPABLE, 1);' according to http://kbase.redhat.com/faq/docs/DOC-4897, since this distro doesn't have /proc/sys/kernel/core_setuid_ok
I tried using a pristine 1.1.11 source build with a core_pattern directory that was owned by root, or by dovecot, or by the user, but I still didn't see a core there.
Mark
On Mar 2, 2009, at 7:32 PM, Mark Hedges wrote:
On Mon, 2 Mar 2009, Timo Sirainen wrote:
I was rather thinking that maybe the kernel doesn't want to write core files to directories that are writable by everyone.
Could it be that dovecot uses setuid to change permissions? Application would need 'prctl(PR_SET_DUMPABLE, 1);'
Interesting. I hadn't known about this before. I'll definitely look
into this and enable it if it appears to work.
Anyway, with mail_drop_priv_before_exec=yes this isn't necessary.
I tried using a pristine 1.1.11 source build with a core_pattern directory that was owned by root, or by dovecot, or by the user, but I still didn't see a core there.
In my setups it core dumps to the user's home directory just fine.
Can you make any program dump core? For example:
sleep 5 & kill -SEGV %1
On Mar 2, 2009, at 8:22 PM, Timo Sirainen wrote:
On Mar 2, 2009, at 7:32 PM, Mark Hedges wrote:
On Mon, 2 Mar 2009, Timo Sirainen wrote:
I was rather thinking that maybe the kernel doesn't want to write core files to directories that are writable by everyone.
Could it be that dovecot uses setuid to change permissions? Application would need 'prctl(PR_SET_DUMPABLE, 1);'
Interesting. I hadn't known about this before. I'll definitely look
into this and enable it if it appears to work.
Done, also improved logging:
On Mon, 2 Mar 2009, Timo Sirainen wrote:
I tried using a pristine 1.1.11 source build with a core_pattern directory that was owned by root, or by dovecot, or by the user, but I still didn't see a core there.
In my setups it core dumps to the user's home directory just fine.
Can you make any program dump core? For example:
sleep 5 & kill -SEGV %1
Yes, that dumps a core, even as this user. I had to change core_pattern back to 'core' though, using /tmp didn't work, even though I can dump the core in /tmp. Well, a core pattern of '/tmp/core.%p' does work for sleep/kill, but still not for the test user with the dovecot failure.
Could it be that dovecot uses setuid to change permissions? Application would need 'prctl(PR_SET_DUMPABLE, 1);'
Interesting. I hadn't known about this before. I'll definitely look into this and enable it if it appears to work.
Done, also improved logging:
Nope. Applied this to a pristine source. Still nothing.
I don't have time to work on this anymore. I have learned that fighting malfunctioning systems like this is a waste of time/money. Thanks for fixing the actual problem, though! I look forward to 1.1.12.
Mark
On Tue, 2009-03-03 at 08:34 -0800, Mark Hedges wrote:
Done, also improved logging:
Nope. Applied this to a pristine source. Still nothing.
It should have logged something different though? Like appending "(core not dumped - is the home dir ok?)"
I don't have time to work on this anymore.
Sure, no problem. :) I was mainly now interested in being able to answer similar core dumping problems more easily in future.
On Tue, 3 Mar 2009, Timo Sirainen wrote:
Nope. Applied this to a pristine source. Still nothing.
It should have logged something different though? Like appending "(core not dumped - is the home dir ok?)"
Ah yes.
Mar 3 12:34:14 anubis dovecot: child 27262 (pop3) killed with signal 11 (core not dumped - is home dir set?)
FWIW finger and getpwnam in perl report the correct home
directory for this user. Dovecot is using the default pam
config.
Mark
On Tue, 2009-03-03 at 12:36 -0800, Mark Hedges wrote:
It should have logged something different though? Like appending "(core not dumped - is the home dir ok?)"
Ah yes.
Mar 3 12:34:14 anubis dovecot: child 27262 (pop3) killed with signal 11 (core not dumped - is home dir set?)
Great.
FWIW
fingerand getpwnam in perl report the correct home directory for this user. Dovecot is using the default pam config.
PAM doesn't matter. Home is looked up from userdb. With mail_debug=yes Dovecot logs at startup the home (although not with pop3 without this patch: http://hg.dovecot.org/dovecot-1.1/rev/b58f72ccdfe3 )
On Mon, Mar 02, 2009 at 01:25:43PM -0800, Mark Hedges wrote:
On Fri, 27 Feb 2009, Timo Sirainen wrote:
Ah, this explains everything. Fixed both your problem and the segfault: f831d12187d1
Yes, this patch fixed the problem when applied to pristine 1.1.11 source.
Will there be an update of the RPM at http://atrpms.net/dist/el5/dovecot/?
dovecot has a healthy release cycle, so any patches are picked directly through upgrading to the next dovecot release.
It's hard enough for automating deployment of new servers that I have to use a downloaded RPM instead of using yum, since I doubt CentOS's two-year-old version of 1.0.7 will ever be updated. Compiling from source is a pain but I'll use it for now.
Actually the packages at ATrpms are in a yum repo, and even if you don't want to point yum to it for any reason (maybe you don't trust the rest of the content), you can create your own local repo and place the downloaded rpm there. This will automate the deployment of new servers again, you will only need to touch the setup for rpm upgrades.
Axel.Thimm at ATrpms.net
on 2-25-2009 5:55 PM Mark Hedges spake the following:
I have to make dotlock work because this openwebmail thing only supports one of dotlock or flock, but procmail delivery does dotlock and fcntl. procmail correctly creates a dotlock file in /var/spool/mail/username.lock when delivering, I can watch this with
while :; do ls -la | grep lock; done. I am moving away from openwebmail because of its wanting to access the mailstore directly. It has caused many problems through the years, and I want to move to Maildir anyway.
-- MailScanner is like deodorant... You hope everybody uses it, and you notice quickly if they don't!!!!
participants (6)
-
Axel Thimm
-
Jose Celestino
-
Mark Hedges
-
Scott Silva
-
Seth Mattinen
-
Timo Sirainen