[Dovecot] v1.0 vs 1.1b re: Postfix and Dovecot LDA
Jerry Yeager
jerry at scene-naturally.dyndns.org
Fri Sep 28 17:37:34 EEST 2007
>>> From: Bill Cole <dovecot-20061108 at 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 at scconsult.com
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 27 Sep 2007 17:07:28 -1000 (HST)
> From: Julian Cowley <julian at lava.net>
> Subject: [Dovecot] Dovecot raw backtrace when copying to folder
> To: dovecot at dovecot.org
> Message-ID: <alpine.LRH.0.9999.0709271646190.28814 at 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 at 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 at domain): Trying to
> allocate 0 bytes
> Sep 27 16:41:53 cookie dovecot: IMAP(user at 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 at dovecot.org
> http://dovecot.org/cgi-bin/mailman/listinfo/dovecot
>
> End of dovecot Digest, Vol 53, Issue 77
> ***************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2447 bytes
Desc: not available
Url : http://dovecot.org/pipermail/dovecot/attachments/20070928/1cf9db9e/attachment.bin
More information about the dovecot
mailing list