mailing list archives
Re: Unix Permissions: Using groups to isolate users from webserver
From: lists <lists () innocence-lost net>
Date: Wed, 1 Dec 2004 22:03:32 -0700 (MST)
you can compile php as a cgi or as a shared object linked into apache,
however suexec becomes pretty pointless if you dont make php a cgi. There
are some snafu's with suexec, but once you get the permissions issues down
(files/directories that are/contain cgi's must be owned by the user they
are to run as and not be writeable to world/group, etc), it works pretty
Perhaps what you should consider for your situation is something a little
more estoeric, perhaps something like extended posix acl's, rsbac
(rsbac.org), or even grsec's acl's, it has a bit of a learning curve
however once you get it deployed and working, you will be happy that you
There are only two choices in life. You either conform the truth to your desire,
or you conform your desire to the truth. Which choice are you making?
On Wed, 1 Dec 2004, drax wrote:
Date: Wed, 01 Dec 2004 03:17:14 +0100
From: drax <drax () sweon net>
To: Alexander Klimov <alserkli () inbox ru>
Cc: security-basics () securityfocus com
Subject: Re: Unix Permissions: Using groups to isolate users from webserver
Thank you for you reply Alexander.
Alexander Klimov wrote:
On Mon, 29 Nov 2004, drax wrote:
I am running a server, which has user accounts accessible through ssh
running a few services, moreover, apache for serving http. Some of
have vhosts, and therefor apache goes in various user's home dir to
webpages. I need the users to have full control of their vhost'ed
that is why they are in their respective $HOME and belong to them.
Note that it does not matter where the file resides -- to be
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. So I can't store the
user's vhost'ed files there (even with proper access modes) because the user
wouldn't be able to see them.
Some of their web pages (php scripts,etc) need to be able to write to
filesystem. Therefor apache must be able to write in those particular
their $HOME. Additionally, some of their web scripts (conf files with
passwords, etc), need to be protected from other users. But obvisouly,
be accessible by apache.
The way I solved this problem is the following:
Do you believe my setup is correct and up to the task, or could it be
circumvented in a matter of minutes?
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
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? 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.
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 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)
The proper way to solve your problem is to execute scripts with UIDs of
Note, that since usually php executed inside httpd you need to switch to
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". As for running a
apache process per user, doesn't that get cumbersom if you start having alot
The suexec seems to be what I wanted in the first place but everywhere (conf
files, docs, even you :p), it mentions CGI. That's what stopped me because I
mainly have php scripts, not CGIs. Maybe it works anyway, I'll look into it.
I'll keep you posted, thanks for the help.