Re: Unix Permissions: Using groups to isolate users from webserver

[Alexander Klimov <alserkli () inbox ru>]

On Wed, 1 Dec 2004, drax wrote:
> Alexander Klimov wrote:
> > Note that it does not matter where the file resides -- to be readable/writable
> > the only thing matters is its access mode.
>
> True, but the access modes of the directory containing it, also play a
> role. In my case, although most directory and files are readable, a
> couple directories up in the tree, there's an access mode blocking (no
> execution) anyone but the apache user from going in any deeper.
> This is to stop people from viewing the webserver files.

Since every user is able to execute a programm of his choice under apache user
he effectively has the same access as apache itself.

> > Since your webserver is always executed with the same UID which allows to
> > read/write all users' data then every user who can execute something on it has
> > exactly the same abilities.
> What do you mean by " the same UID which allows to read/write all users'
> data". That's if I execute the server as root right?

No, that means that the apache UID is always the same. That is a programm of
a user A is executed with under the apache user id and a programm of another
user B is also executed under the apache user id.

> But apache changes to the user/group you feed it in the conf files, and
> therefor gets (only) that user's rights. So unless the user specifically makes
> a file readable for that apache user, the webserver won't see the file.
> Correct me if I am wrong though.
Don't sure I understand you current setup: how many times you use User
directive? If you use it only once then the situation is exactly as I described.
If you use it in every virtual host and do not use suEXEC then it is pretty
useless:
> > > http://httpd.apache.org/docs/mod/core.html#user >>>
Special note: Use of this directive in <VirtualHost> requires a properly
configured suEXEC wrapper. When used inside a <VirtualHost> in this manner, only
the user that CGIs are run as is affected. Non-CGI requests are still processed
with the user specified in the main User directive.
<<<

> On the other hand, you made me realise something else which proves my
> solutions is worthless. Since the scripts (php, cgis) apache executes inherit
> the rights of the user apache is running as. And since any user can (with my
> solution)  feed scripts to apache then any user can do whatever apache can do

You are absolutely right -- this is what I tried to explain. Note that this
also means that no acl's can help you.

> ie:  fiddle around with other user's files (who have been setup for apache to
> read/write) and worst even, fiddle around with the main server files (main
> sites being hosted)

It is usually a good idea to make configuration files owned by root and
read-only for apache user since the configuration files are executed by parent
process wich runs under root (and yes, in some cases config can contain
executable commands, e.g., if you have mod_perl).

> > The proper way to solve your problem is to execute scripts with UIDs of
> > respected users:
> >   http://httpd.apache.org/docs/suexec.html
> >
> > Note, that since usually php executed inside httpd you need to switch to CGI
> > mode or use different UIDs for httpds for different vhosts (AFAIK this is
> > greatly simplified by Apache 2).
>
> I didn't quite catch what you meant by "switch to CGI mode".

PHP can be run as apache module (that is inside apache) which makes suexec
impossible or you can install it separately and make your PHP scripts usual unix
scripts: start them with
#!/usr/local/php/bin/php
and chmod +x them.

> As for running a apache process per user, doesn't that get cumbersom if you
> start having alot of users?
It is not that cumbersome if you use Apache 2:
http://httpd.apache.org/docs-2.0/mod/perchild.html#assignuserid
-- 
Regards,
ASK