Hi, this happens since a few days on a Gentoo hardened system using a grsecurity enabled kernel running Dovecot 1.0.10, only to 2 of 10 users though: --8<-- kernel: grsec: From 192.168.0.1: denied resource overstep by \ requesting 537325568 for RLIMIT_AS against limit 536870912 \ for /usr/libexec/dovecot/imap[imap:15708] uid/euid:30010/30010 \ gid/egid:30006/30006, parent /usr/sbin/dovecot[dovecot:15574] \ uid/euid:0/0 gid/egid:0/0 kernel: grsec: From 192.168.0.1: denied resource overstep by \ requesting 537321472 for RLIMIT_AS against limit 536870912 \ for /usr/libexec/dovecot/imap[imap:15708] uid/euid:30010/30010 \ gid/egid:30006/30006, parent /usr/sbin/dovecot[dovecot:15574] \ uid/euid:0/0 gid/egid:0/0 kernel: grsec: From 192.168.0.1: denied resource overstep by \ requesting 537456640 for RLIMIT_AS against limit 536870912 \ for /usr/libexec/dovecot/imap[imap:15708] uid/euid:30010/30010 \ gid/egid:30006/30006, parent /usr/sbin/dovecot[dovecot:15574] \ uid/euid:0/0 gid/egid:0/0 kernel: grsec: From 192.168.0.1: denied resource overstep by \ requesting 537321472 for RLIMIT_AS against limit 536870912 \ for /usr/libexec/dovecot/imap[imap:15708] uid/euid:30010/30010 \ gid/egid:30006/30006, parent /usr/sbin/dovecot[dovecot:15574] \ uid/euid:0/0 gid/egid:0/0 dovecot: IMAP(info): block_alloc(): Out of memory dovecot: child 15708 (imap) returned error 83 (Out of memory) --8<-- grsecurity only logs the attempted resource overstep. I already increased mail_process_size to 512M and deleted the index.cache* files inside the users maildir -- didn't help :/ Any idea why this is happening or how I could find out? TIA :) -- Regards, Wolfram Schlich <wschlich at gentoo.org> Gentoo Linux * http://dev.gentoo.org/~wschlich/
On Tue, 2008-01-15 at 14:51 +0100, Wolfram Schlich wrote:> this happens since a few days on a Gentoo hardened system using a > grsecurity enabled kernel running Dovecot 1.0.10, only to 2 of 10 > users though: > > --8<-- > > kernel: grsec: From 192.168.0.1: denied resource overstep by \ > requesting 537325568 for RLIMIT_AS against limit 536870912 \If it's trying to allocate 500MB of memory, there's a bug somewhere. Could you get gdb backtrace of this? The attached patch changes Dovecot to call abort() so it should write core files to user's home dir. See http://dovecot.org/bugreport.html -------------- next part -------------- A non-text attachment was scrubbed... Name: outofmem-panic.diff Type: text/x-patch Size: 491 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20080120/aa85ef2b/attachment-0004.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20080120/aa85ef2b/attachment-0005.bin>
* Timo Sirainen <tss at iki.fi> [2008-01-20 08:49]:> On Tue, 2008-01-15 at 14:51 +0100, Wolfram Schlich wrote: > > this happens since a few days on a Gentoo hardened system using a > > grsecurity enabled kernel running Dovecot 1.0.10, only to 2 of 10 > > users though: > > > > --8<-- > > > > kernel: grsec: From 192.168.0.1: denied resource overstep by \ > > requesting 537325568 for RLIMIT_AS against limit 536870912 \ > > If it's trying to allocate 500MB of memory, there's a bug somewhere. > Could you get gdb backtrace of this? The attached patch changes Dovecot > to call abort() so it should write core files to user's home dir. See > http://dovecot.org/bugreport.htmlHmm. I tried your patch and compiled dovecot with --enable-debug, enabled coredumps for the service (with ulimit -c unlimited) and I got some corefiles now. /usr/libexec/dovecot/imap: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, not stripped --8<-- uluru tmp # gdb /usr/libexec/dovecot/imap core.x\{imap\}.u\{30010\}.g\{30006\}.p\{20880\}.t\{1201094907\} GNU gdb 6.7.1 Copyright (C) 2007 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) (no debugging symbols found) Core was generated by `imap [info ::ffff:172.16.223.18]'. Program terminated with signal 11, Segmentation fault. #0 0x169917d5 in ?? () from /lib/ld-linux.so.2 (gdb) bt full #0 0x169917d5 in ?? () from /lib/ld-linux.so.2 No symbol table info available. #1 0x169bfba9 in ?? () No symbol table info available. #2 0xb146d6ff in ?? () No symbol table info available. #3 0x00000001 in ?? () No symbol table info available. #4 0x00000000 in ?? () No symbol table info available. (gdb) quit uluru tmp # --8<-- Looks like this happens in glibc, right?! I haven't compiled glibc with debugging symbols/unstripped so far of course... -- Regards, Wolfram Schlich <wschlich at gentoo.org> Gentoo Linux * http://dev.gentoo.org/~wschlich/