mailing list archives
Re: Unix Permissions: Using groups to isolate users from webserver
From: drax <drax () sweon net>
Date: Wed, 01 Dec 2004 03:17:14 +0100
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 and is
running a few services, moreover, apache for serving http. Some of these users
have vhosts, and therefor apache goes in various user's home dir to fetch the
webpages. I need the users to have full control of their vhost'ed files, and
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 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. 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.
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.
Some of their web pages (php scripts,etc) need to be able to write to the
filesystem. Therefor apache must be able to write in those particular parts of
their $HOME. Additionally, some of their web scripts (conf files with SQL
passwords, etc), need to be protected from other users. But obvisouly, still
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 it has
exactly the same abilities.
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 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". As for
running a apache process per user, doesn't that get cumbersom if you
start having alot of users?
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.