httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton" <graham.dumple...@gmail.com>
Subject Re: Getting apr_proc_fork to set SELinux Context / Domain
Date Wed, 22 Aug 2007 22:14:38 GMT
On 23/08/07, William A. Rowe, Jr. <wrowe@rowe-clan.net> 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 dev@apr.apache.org (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

Mime
View raw message