From: Bill Cole dovecot-20061108@billmail.scconsult.com
(stuff cut out)
That looks like a bug. A program that calls setgroups() must be running as root. It seems to me that a code path leading to such a call should probably be able to identify that issue before the call and provide a better failure message than translating EPERM into its standard meaning....
The interesting question would be: why does deliver want to call setgroups() at all?
I am not sure why it would need to do this either. It (deliver) is
not handing things off to another app to finish things up.
<snip><snip>
I'd love to take credit, but I thought that was about the LDA with Sendmail, which is rather different, and Rich was running 1.0.3...
In any event, I won't go so far as to say that running deliver as setuid root is actively dangerous, but it feels wrong to me and I wouldn't do it. That may be from too much exposure to bizarre attacks through delivery agents in the Dark Ages.
That it works without being setuid on Linux is a touch odd.
The mystery deepens!
I have it (deliver) in a restricted access folder as a standard
safety precaution, but as most of these "jails" end up being only
safe for a short time I have again gone back to using Postfix as the
deliver.
Timo has from time to time mentioned that he was thinking that
deliver needed to be rewritten. hmmm.
I still give you and Rich credit though, if you had not mentioned the
ideas behind Sendmail and LDA, it would most likely taken much longer
before I read that wiki entry and gave that approach a try, instead
of trying to find the missing setting for changing groups that the
error message wants fixed.
-- Bill Cole bill@scconsult.com
Message: 7 Date: Thu, 27 Sep 2007 17:07:28 -1000 (HST) From: Julian Cowley julian@lava.net Subject: [Dovecot] Dovecot raw backtrace when copying to folder To: dovecot@dovecot.org Message-ID: alpine.LRH.0.9999.0709271646190.28814@taurus.cesta.com Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Seeing a problem with a certain user causing dovecot to crash when
copying mail to a folder. This looks similar to a bug someone on the
mailing list posted recently.Since the backtrace mentions the index, I tried deleting all of the
index files for the user (including subfolders) but it had no effect.
Seems that the bug still happens when creating the index for the first time.Unfortunately, I can't pin down if there is a particular message
causing the problem but I'll see if I can track it using strace.Lines are broken for clarity. This is dovecot 1.0.5 on CentOS 4.5.
Sep 27 16:41:42 cookie dovecot: imap-login: Login: user=user@domain, method=PLAIN, rip=::ffff:xx.xx.xx.xx, lip=::ffff:yy.yy.yy.yy, TLS Sep 27 16:41:53 cookie dovecot: IMAP(user@domain): Trying to
allocate 0 bytes Sep 27 16:41:53 cookie dovecot: IMAP(user@domain): Raw backtrace: imap [0x80ad7d4] -> imap [0x80ad239] -> imap [0x80b5624] -> imap(i_malloc+0x1b) [0x80b0e1b] -> imap [0x8083037] -> imap [0x80833e6] -> imap(index_storage_search_init+0xf4) [0x80836f4] -> imap(cmd_copy+0x145) [0x8056d15] -> imap(cmd_uid+0x7c) [0x805a74c] -> imap [0x805b2d5] -> imap [0x805b25e] -> imap(_client_input+0x8c) [0x805b43c] -> imap(io_loop_handler_run+0x169) [0x80b3e09] -> imap(io_loop_run+0x28) [0x80b3178] -> imap(main+0x49f) [0x806384f] -> /lib/tls/libc.so.6(__libc_start_main+0xd3) [0x506de3] -> imap [0x8055db1] Sep 27 16:41:53 cookie dovecot: child 26079 (imap) killed with
signal 6
dovecot mailing list dovecot@dovecot.org http://dovecot.org/cgi-bin/mailman/listinfo/dovecot
End of dovecot Digest, Vol 53, Issue 77