apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bjoern A. Zeeb" <bzeeb-li...@lists.zabbadoz.net>
Subject Re: [Patch] redux; discussion of FD_CLOEXEC and APR_INHERIT
Date Tue, 18 Mar 2003 21:56:04 GMT
On Tue, 18 Mar 2003, Joe Orton wrote:


> "security risk" is that PHP will let you fork/exec any executable

we are not talking about mod_php here - at least I do not.

> 2. otherwise: even when you set CLOEXEC, the arbitrary binary which
> can be fork/exec from an untrusted PHP script can then just use
> ptrace() to arrange for any httpd child to run arbitrary code anyway,
> thereby gaining access to all the fds you went to so much effort to
> avoid leaking.

But if I call an ordinary CGI script (be it shell,perl,C, php as CGI...)
I may run it through suexec and it will be run under a completly different
unprivileged uid and gid. It will not be able to access httpd
resources if my file, etc. permissions are set up correctly, ...
Same will for sure almost be true for cgid/mod_cgi.

A CLOEXEC and correct handling from within APR for those exec()ing
cases will prevent those CGIs from inheriting a lot of file
descriptors that
a) _are_ a security risk (else the cgi perhaps wouldn't be able to
   access these resources - see above) and
b) those fds eat a lot of per process resources so a CGI may run into
   set process limits (set/getrlimit(2)) and
c) closing these descriptors in a wrapper like suexec would be doable
   but is _very_ expensive as one may have to call a close(2) on all
   possible open file descriptors apart from 012 what means looping
   from 3 to the rlim_cur/rlim_max value of getrlimit(RLIMIT_NOFILE, &)

So APR can help me a lot as the internals already have a "list" of
open file descriptors and need to only close them thus elimination a),
b) and c).

Just one point on this.

Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

View raw message