On 28/05/14 4:03 AM, Otto Moerbeek wrote:
On Wed, May 28, 2014 at 07:32:48AM +0200, Otto Moerbeek wrote:
On Tue, May 27, 2014 at 05:11:16PM -0400, Brad Smith wrote:
On 27/05/14 3:42 PM, Otto Moerbeek wrote:
Hi,
on amd64 I'm seeing out-of-mem errors if I use a nonexistent username
with bsdauth (ottotest1 does not exist in /etc/passwd).
May 27 21:33:28 mx1 dovecot: auth-worker(11223): Fatal:
pool_system_realloc(268435456): Out of memory
May 27 21:33:28 mx1 dovecot: auth: Error: auth worker: Aborted request: Worker
process died unexpectedly
May 27 21:33:28 mx1 dovecot: auth-worker(11223): Fatal: master:
service(auth-worker): child 11223 returned error 83 (Out of memory (service
auth-worker { vsz_limit=256 MB }, you may need to increase it) - set
CORE_OUTOFMEM=1 environment to get core dump)
May 27 21:33:30 mx1 dovecot: imap-login: Disconnected (auth failed, 2 attempts in 10 secs):
user=<ottotest1>, method=PLAIN, rip=XXX, lip=YYY, TLS,
session=<V8+3xGb6UwAgAQmBqvMAAQIkHf/+3uk5>
Existing user with correct password goes ok, existing user with wrong
password is denied access as it should.
[otto@mx1:136]$ pkg_info | grep dove
dovecot-2.2.10p0 compact IMAP/POP3 server
Any clue?
This issue was what spurred fixing getpwnam and getpwuid..
http://marc.info/?l=openbsd-cvs&m=139406310728289&w=2
http://marc.info/?l=openbsd-cvs&m=139429727909338&w=2
not being familiar with the API I'm not sure if the
workaround as was in place for older OpenBSD releases
can be improved at all..
http://www.openbsd.org/cgi-bin/cvsweb/ports/mail/dovecot/patches/patch-src_lib_ipwd_c
Thanks for the pointer.
The current situation is not really nice with it's resource
consumption and log spamming. I'll see if I get a chance to look into
this.
-Otto
Ok, here;'s what happening on 5.5:
getpwnam returns both for no such user and not enough space (ERANGE).
The code assumes always ERANGE and loops expanding the buffer until
out of mem.
On current this is fixed due to changes to getpwnam_r().
It is funny to see calls to getpwnam_r() in code using static buffers....
A fix for 5.5. is indeed tricky, we cannot use the result argument nor
the return value to distinguish ERANGE and no such user.
Have to think about this.
Able to come up with anything?
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
