grsecurity forums

when trying to run ht://dig, htnotify dies in the middle of index building with:

grsec: From 63.84.43.65: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (htnotify:27281) UID(0) EUID(0), parent (rundig:27276) UID(0) EUID(0)

what do I need to do to give more resources to this program so it can complete?

-Thom

tschak909 wrote:what do I need to do to give more resources to this program so it can complete?

first check your logs for more messages related to this, especially those from PaX. my bet is that your app is getting killed by PaX, posting the relevant logs will help determine (and fix) it for sure.

PaX Team wrote:

tschak909 wrote:what do I need to do to give more resources to this program so it can complete?

first check your logs for more messages related to this, especially those from PaX. my bet is that your app is getting killed by PaX, posting the relevant logs will help determine (and fix) it for sure.

there are no PaX related messages, because I disabled PaX completely.

I deliberately turned off PaX in the kernel configs, and turning off all the options with chpax doesn't make a dent.

is there a way to increase RLIMIT_CORE for this app???

I am getting this resource overstep as well, but its very odd. At first it was just when i attempted to start squid for the first time. I thought ok, squid is being a bit too big for grsec's tastes, understandable. Then it started happenning with various other programs as well. nscd is now routinly shot by grsec and whenever I ping the local network, ping somehow manages to overstep resources, however pinging the internet is fine... Here are some log messages:

Jun 24 23:15:00 [kernel] grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ping:23629) UID(0) EUID(0), parent (bash:7227) UID(0) EUID(0)
Jun 24 23:15:21 [kernel] grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ping:14932) UID(0) EUID(0), parent (bash:7227) UID(0) EUID(0)
Jun 24 23:27:35 [kernel] grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ping:25579) UID(0) EUID(0), parent (bash:12895) UID(0) EUID(0)
Jun 24 23:31:33 [kernel] grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (slapd:18210) UID(0) EUID(0), parent (runscript.sh:24483) UID(0) EUID(0)
Jun 24 23:31:42 [kernel] grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (slapd:12865) UID(0) EUID(0), parent (runscript.sh:14174) UID(0) EUID(0)
Jun 24 23:37:36 [kernel] grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ping:14924) UID(0) EUID(0), parent (strace:32453) UID(0) EUID(0)
Jun 24 23:38:32 [kernel] grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ping:27446) UID(0) EUID(0), parent (bash:12895) UID(0) EUID(0)
Jun 24 23:39:22 [kernel] grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (nscd:5637) UID(0) EUID(0), parent (nscd:21813) UID(0) EUID(0)
Jun 24 23:39:22 [kernel] grsec: attempted resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 by (ping:10593) UID(0) EUID(0), parent (bash:12895) UID(0) EUID(0)

I do not get any other grsec logs, interestingly enough I turned on timechange and (un)mount logging, and none of those events actually get logged. I believe this is a bug in grsec.

I am using kernel 2.4.21 with the ck2 patch which includes some ck patches along with grsecurity and xfs. I would have thought it to be the other patches I applied though I'm seeing other people with the same problem. It would be nice if we could get this working.

Nox wrote:I am using kernel 2.4.21 with the ck2 patch which includes some ck patches along with grsecurity and xfs. I would have thought it to be the other patches I applied though I'm seeing other people with the same problem. It would be nice if we could get this working.

you should try the plain grsec patch first to see if the problem persists, then we'll need more info about the coredumps. generally you can try 'ulimit -c' to increase the core file size limit for apps started from a shell then you'll have to analyze the coredumps (so it's quite some debugging work). what may also help is an strace output where one of the last syscalls before the crash could give us a clue (e.g., a syscall returns some error due to a grsec restriction but the app doesn't check it).

I disabled resource overstep auditing and the programs no longer die, I was able to start squid without a hitch and havn't had a single program, its wierd that resource auditing would kill programs as well, unfortunetly I don't know how much time I have to play around with this but I will make a new kernel on my testing box and see if I can get it to do this.