On Wed, May 14, 2008 at 10:39:52AM +0200, Manlio Perillo wrote:
... and possibly setuid/gid/etc. so the one to fork should probably be
the master process, not a worker.
This is not possible.
Well, you _could_ set up a bunch of pipes/sockets but it wouldn't be
pretty :)
Otherwise (running all CGI as the
nginx user) it would be pretty limited.
The solution, here, is having Nginx to call seteuid/setegid instead of
setuid/setgid in ngx_worker_process_init.
In this way the child process can call seteuid(0) to become root again,
and then, finally, setuid(xxx) to become the effective user for the CGI.
The problem, of course, is that an external module can call seteuid(0)
to become root, and this is not acceptable.
An external module can already do whatever it wishes in the master
process so this shouldn't be a big issue. However, this requires the
nginx master to run as root (which isn't the case now AFAIK, if you use
ports > 1024). Of course, forking the master process changes nothing
here.
11 messages in ru.sysoev.nginxRe: [ANN] Enhanced Gentoo ebuilds for...
