[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [users@httpd] httpd user and user directory permissions dilemna



On Sun, 2 Nov 2003, David Christensen wrote:

> users@httpd.apache.org & users@httpd.apache.org:
>
> I am running Apache 1.3.26 on Debian 3.0r1 (Woody).  I would like to
> enable user ~/public_html directories, but have two security goals which
> I cannot solve simultaneously:
>
> 1.  Apache should run as the user when reading user pages and running
>     user CGI scripts.
>
> 2.  User home directories should not allow group or world access.
>

Neither of these is possible because of the basic limitations of unix
security.

As you already figured out, you can accomplish part of 1, because suexec
can launch cgi scripts as the user.  The "reading user pages" part is
impossible, however, and any directory serving web pages must be in some
way accessible by the web server, so 2 isn't possible either.

Why?  Well, under unix, each program must run as a user.  To make apache
more secure, all request processing and serving is done under a
non-root userid (see the User and Group directives).  Obviously, a
non-root userid can't simply switch to some other userid.

Even if you were to run apache as root (not a good move!), this still
wouldn't work.  Each apache process serves many different requests.  If
the process were to switch to a non-root userid to serve a specific
directory, then it couldn't serve requests for any other directory,
because there is no way to get the root permissions back to switch to the
new user.  You could imagine a server that forked a new process to serve
each request, which then exited.  But you can also imagine that such a
server would be dog-slow.

Solutions?  Well, there have been a couple different projects that use the
new threading ability of apache 2 to allow different pools of threads to
be kept around to serve requests under different userids.  This wouldn't
work for dozens or hundreds of different userids, of course.  And none of
these projects has anything production ready.  See the "perchild" mpm,
which doesn't work.

You could do the same thing by running a number of different instances of
apache on different ports with different privileges and using a reverse
proxy to choose which one gets the requests.  Again, this would be rather
resource intensive and complicated.

The punch-line: you can't do that.  CGI scripts can be launched under
different userids, but ordinary pages (including php scripts launched as
part of the apache process) must use the apache userid.  Hence you need to
provide world or apache-group read and search access to all the files you
want to serve.

(That was probably way more than you wanted to know.  I should put that
into the FAQ so I don't have to repeat it!)

Joshua.



Reply to: