RLIMIT_STACK RLIMIT_CORE

[JLO]

I'm using 2.4.31-grsec kernel. I've noticed when I'm running clamscan and I accidentally leave large volumes mounted in the filesystem so that I scan several hundred gigs where it takes a long time, and my system load and CPU stay maxed out for a duration (and memory starts going into swap). I get these errors all over the place.

Mar 19 11:35:08 Sievette kernel: grsec: denied resource overstep by requesting 44548096 for RLIMIT_STACK against limit 8388608 for /bin/ps[ps:10940] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:8629] uid/euid:0/0 gid/egid:0/0
Mar 19 11:35:08 Sievette kernel: grsec: denied resource overstep by requesting 44548096 for RLIMIT_STACK against limit 8388608 for /bin/ps[ps:10940] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:8629] uid/euid:0/0 gid/egid:0/0
Mar 19 11:45:09 Sievette kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/rrdtool[rrdtool:8977] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/rrdtool_perf.pl[rrdtool_perf.pl:21714] uid/euid:0/0 gid/egid:0/0
Mar 19 11:45:09 Sievette kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/rrdtool[rrdtool:6032] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/rrdtool_perf.pl[rrdtool_perf.pl:21714] uid/euid:0/0 gid/egid:0/0
Mar 19 11:45:09 Sievette kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/rrdtool[rrdtool:17384] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/rrdtool_perf.pl[rrdtool_perf.pl:21714] uid/euid:0/0 gid/egid:0/0

Now I'm fairly sure this is in a perl script that does performance graphing.
Manually kill clamscan,Mar 19 13:55:46 Sievette clamscan: ALERT exited abnormally with [0], and everything is back to normal. I did a forum search, there seems to be some mystery in this reguard.

[PaX Team]

Mar 19 11:35:08 Sievette kernel: grsec: denied resource overstep by requesting 44548096 for RLIMIT_STACK against limit 8388608 for /bin/ps[ps:10940] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:8629] uid/euid:0/0 gid/egid:0/0

this just means that ps ran out of stack space (which may itself be a bug in ps or a real need), you have to increase the stack limit (which is 8MB by default).

Mar 19 11:45:09 Sievette kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/rrdtool[rrdtool:8977] uid/euid:0/0 gid/egid:0/0, parent /usr/local/bin/rrdtool_perf.pl[rrdtool_perf.pl:21714] uid/euid:0/0 gid/egid:0/0

this one is about rrdtool crashing but not leaving the coredump behind because of the core size resource limit, adjust it and then you can take a look at it (i posted here and/or the mailing list some generic instructions for what to look at in a core in gdb).

[JLO]

My observation of this raises some questions. First, obviously I do various system graphing (throughput, memory usage, system load, cpu load, connections, squid cache size, etc) through a cron job every 5 minutes or so. Second clamscan is also ran through cron (but I have cut it back to once a week). I can go days and days without ANY errors (at all-from anything) but there is something about clamscan & grsecurity together that causes errors (or error reporting) in my (unrelated?) cron graphing programs. So I go from no errors for days to errors continuously just by running clamscan. I seriously doubt the problem lies in ps or rrdtool as this only appeared (for me) with later grsecurity kernels PLUS running clamscan (resource intensively). If I hadn't deleted my earlier grsecurity kernels (such as 2.4.20, 27), I would do more testing to see if this is grsecurity version specific or unrelated (as in BAD clamscan, good grsecurity for faithfully reporting)- as there is at least a known trigger to produce this phenomenon. I noticed another recent post of someone receiving errors from running clamscan also.

http://forums.grsecurity.net/viewtopic. ... 353d88900c

Edit: I have also noticed unwanted network activity when running clamd long term...so there may be something more sinister here...