[mod_fcgid PATCH] don't try to change ownership of socket directory unless running as root

[Jeff Trawick <tr...@gmail.com>]

Currently, starting httpd as non-root with mod_fcgid loaded fails unless
User/Group are set to the active User/Group.  Normally, httpd modules don't
try to set ownership of objects to the specified User/Group unless starting
as root.  Thus, httpd.conf can contain reasonable User/Group settings for
production use but still be suitable for use by Joe User.
The affected code in fcgid_pm_unix.c is from the original revision (
http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/arch/unix/fcgid_pm_unix.c?revision=753487&view=markup
).

Logic was added a couple of years ago (
http://svn.apache.org/viewvc?view=rev&revision=753553) to bypass the
directory creation/chown if the directory already existed and had the
correct ownership, to allow use with some SELinux policy.

Comments/concerns?

Re: [mod_fcgid PATCH] don't try to change ownership of socket directory unless running as root

[Jeff Trawick <tr...@gmail.com>]

On Mon, May 11, 2009 at 4:26 PM, Joe Orton <jo...@redhat.com> wrote:

> On Mon, May 11, 2009 at 11:56:42AM -0400, Jeff Trawick wrote:
> > Currently, starting httpd as non-root with mod_fcgid loaded fails unless
> > User/Group are set to the active User/Group.  Normally, httpd modules
> don't
> > try to set ownership of objects to the specified User/Group unless
> starting
> > as root.  Thus, httpd.conf can contain reasonable User/Group settings for
> > production use but still be suitable for use by Joe User.
> > The affected code in fcgid_pm_unix.c is from the original revision (
> >
> http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/arch/unix/fcgid_pm_unix.c?revision=753487&view=markup
> > ).
> >
> > Logic was added a couple of years ago (
> > http://svn.apache.org/viewvc?view=rev&revision=753553) to bypass the
> > directory creation/chown if the directory already existed and had the
> > correct ownership, to allow use with some SELinux policy.
> >
> > Comments/concerns?
>
> I bumped into problems with this when I tried the Fedora package of
> mod_fcgid recently, but got scared off when I started reading the code.
>
>
It seems that there's a lot to understand ;)

The only requirement on the directory is that root can create
> sockets in the directory, and the less-privileged user can open those
> sockets, right?


Close.  The startup user (root) creates the directory and sets permissions
to 0700.  The child user (e.g., webservd) creates the sockets and connects
to them.  (A pipe is used for communication as well.  I think there's a unix
socket per application instance.)

Re: [mod_fcgid PATCH] don't try to change ownership of socket directory unless running as root

[Joe Orton <jo...@redhat.com>]

On Mon, May 11, 2009 at 11:56:42AM -0400, Jeff Trawick wrote:
> Currently, starting httpd as non-root with mod_fcgid loaded fails unless
> User/Group are set to the active User/Group.  Normally, httpd modules don't
> try to set ownership of objects to the specified User/Group unless starting
> as root.  Thus, httpd.conf can contain reasonable User/Group settings for
> production use but still be suitable for use by Joe User.
> The affected code in fcgid_pm_unix.c is from the original revision (
> http://svn.apache.org/viewvc/httpd/mod_fcgid/trunk/mod_fcgid/arch/unix/fcgid_pm_unix.c?revision=753487&view=markup
> ).
> 
> Logic was added a couple of years ago (
> http://svn.apache.org/viewvc?view=rev&revision=753553) to bypass the
> directory creation/chown if the directory already existed and had the
> correct ownership, to allow use with some SELinux policy.
> 
> Comments/concerns?

I bumped into problems with this when I tried the Fedora package of 
mod_fcgid recently, but got scared off when I started reading the code.

1. global symbol names like get_socketpath() etc

2. defaults:

#define DEFAULT_SOCKET_PREFIX "logs/fcgidsock"
#define DEFAULT_SHM_PATH "logs/fcgid_shm"

should be DEFAULT_REL_RUNTIMEDIR-relative, then these would appear in 
the correct place by default (e.g. /var/run in a Fedora build)

3. the whole apr_dir_make_recursive() thing seemed a bit dubious (at 
least in that it's _recursive) - I would have expected a prerequisite of 
a correctly configured directory and failure otherwise.

but I confess I haven't had time/energy to look into this module in 
detail.  The only requirement on the directory is that root can create 
sockets in the directory, and the less-privileged user can open those 
sockets, right?

Regards, Joe