Very Computer

Hi,

who knows exactly how Apache deals with the User and Group directives
either plain in the httpd.conf and in a VirtualHost subsection? It seems,
the plain version actually changes the user even for accessing direct
documents to be served by the Apache and especially for modules like
mod_php, but when these directives are set in a VirtualHost section, they
only apply to CGI scripts executed via suExec or CGIwrap? Am I right?

Does anybody know why the User is not even set with seteuid for a
VirtualHost? The server instance still could be reused, because seteuid
is reversible. And yet mod_php and mod_perl would be limited to that
user. It should be easy to prevent seteuid back to the real user-id for
such scripting languages.

Thanks
        Michael

remarked...

[You news agent seems to be broken.]

Quote:> who knows exactly how Apache deals with the User and Group directives=20=

> either plain in the httpd.conf and in a VirtualHost subsection? It seems=
> ,=20
> the plain version actually changes the user even for accessing direct=20=

> documents to be served by the Apache and especially for modules like=20=

> mod_php, but when these directives are set in a VirtualHost section, the=
> y=20
> only apply to CGI scripts executed via suExec or CGIwrap? Am I right?

You can only use User and Group in Virtual hosts if you have SuExec
installed.  CGIwrap is different as it forces CGI scripts to run with
the user's UID.

--

pls note the one line sig, not counting this one.

As the docs say, User and Group directives in virtualhosts only apply
to suexec.

Quote:>Does anybody know why the User is not even set with seteuid for a
>VirtualHost? The server instance still could be reused, because seteuid
>is reversible. And yet mod_php and mod_perl would be limited to that
>user. It should be easy to prevent seteuid back to the real user-id for
>such scripting languages.

Erm... "it should be easy to prevent seteuid".  Lots of things in
this world should be easy.  Like solving world hunger.  Just because
they "should be" doesn't mean they are.  In a language like perl
or php, there are a whole lot of things you can do that are quite
hard to restrict completely.  In addition, if there are any security
holes that may be present to let users execute arbitrary code as
the user the server runs as, that means that they can seteuid()
back whenever they want.

This also means that any hole in Apache leads to a root compromise of
your system.  That isn't very smart.

The reason Apache doesn't offer this is because it simply isn't secure.