On 23/08/07, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Ruediger Pluem wrote: > > > > On 08/22/2007 07:21 PM, JoshuaKramer wrote: > >> Howdy All, > >> > >> Is there an easy way to get the apr_proc_fork mechanism to set the > >> SELinux context or domain of child scripts? I am using an experimental > >> module (mod_wsgi) to run Python scripts; the Python script is run in a > >> Python interpreter which in turn is embedded in child HTTPD processes. > >> These child HTTPD processes run as individual Linux users. I'd also > >> like to be able to set their security contexts/domains. > > > > As apr_proc_fork is part of APR it would be better to post this question > > to [EMAIL PROTECTED] (although many APR folks are also on this list). > > You might also have a look at > > http://svn.apache.org/repos/asf/httpd/httpd/trunk/os/unix/unixd.c > > about how httpd extended the create process logic.
The mod_wsgi package already does all that stuff that unixd.c does. It couldn't use the unixd.c code however, because the unixd.c code is hardwired to to use User/Group directive values. In mod_wsgi it needs to potentially create a number of different distinct daemon processes running as different users. As such, it would be nice if the unixd.c code was refactored to allow the user/group to be passed in as parameters, that way it could be reused and it wouldn't be necessary to duplicate what it does. In terms of the persons original problem, it is that under SELinux the main Apache parent process runs as Apache user and not as root, but with SELinux allowing it to still create listener on port 80. That the main Apache process isn't root though, then means that it isn't possible to create forked daemon processes that run as a different user. It is some way of having these forked daemon processes run under SELinux as a different user that they want. So, nothing to do with the lack of code for forking daemon processes and dropping privileges, but the restrictions put in place by running SELinux. I am not sure that there is a way around the problem. Graham
