On Tue, 18 Mar 2003, Joe Orton wrote: Hi,
> "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/
