grsecurity forums

Hi,

We've run into a "classic" problem trying to run certain commands via PHP's exec function returning this error:

socket.c:2117: REQUIRE(maxfd <= (int)1024) failed.

we've tried every fix under the sun and we're left with wondering if grsec has something to do with this? Is there a hard limit on file descriptors imposed somewhere via grsec and is it tweakable? Is there any other part of grsec that might be causing this? We're running a testing patchset, with the low security config on kernel 2.6.24.2.

Thanks.

There is nothing in grsecurity that imposes such a limit. If you can test with a vanilla kernel of the same config and not be able to reproduce the problem, then I'll look into it further.

-Brad

Hi,

Thanks for your quick answer. I've rebooted into a stock centos kernel and the error now only occurs say one in ten tries. Whereas it fails every single time on a grsec kernel.

Thanks.

closet geek wrote:socket.c:2117: REQUIRE(maxfd <= (int)1024) failed.

where does this come from? a quick google codesearch points at some bind code only. in any case, this doesn't look like an rlimit related check but something internal to the application logic and you're likely hitting it due to file descriptor leakage - better check your application logic and also look at /proc/pid/fd/ to get an idea about what's leaking.

PaX Team wrote:

closet geek wrote:socket.c:2117: REQUIRE(maxfd <= (int)1024) failed.

where does this come from? a quick google codesearch points at some bind code only. in any case, this doesn't look like an rlimit related check but something internal to the application logic and you're likely hitting it due to file descriptor leakage - better check your application logic and also look at /proc/pid/fd/ to get an idea about what's leaking.

Hi,

It is an Apache/PHP issue however it's not clear what is causing it. We've raised the FD_SETSIZE variable in:

/usr/include/linux/posix_types.h
/usr/include/bits/typesizes.h

recompiled Apache + PHP.

cat /proc/sys/fs/file-nr
7965 0 131072

ulimit -a:

core file size (blocks, -c) 1000000
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
pending signals (-i) 1024
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 131072
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 14335
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

yes -n is crazy high but we've tried every thing here. The httpd init scripts set the ulimit -n to be this value when Apache is started. I can see no where where this value of 1024 is coming from for maxfd. The only strange thing left is that the PHP script works most times when using a stock CentOS kernel but never works at all when using a grsec patched kernel. There must be a connection somewhere.

Thanks.

Just a quick update:

The problem here did not lie with grsec, it is an Apache/PHP bug. Apache 1.3 clears up file descriptors so that exec() doesn't inherit all of the open file descriptors from Apache when executing a command. However Apache 2.2 does not have this fix, and the Apache team believe it's not their job to fix it but PHP's. PHP think it's Apache's job etc

A wrapper script has been written for exec that closes the file descriptors before executing the command(s).

Thanks.