by Here's an interesting (IMO) conceptual problem I'd like to pose and
solicit suggestions on. It involves Apache, PHP, unix file
permissions, and related issues. I've cross posted this to both the
PHP mailing list and comp.infosystems.www.servers.unix, since it seemed
relevant in both places.
I have a shared Linux webserver with about 30 users. For reasons that
aren't worth getting into right now, the 30 users have neither telnet
nor FTP access, and never will. Their only ability to edit their html
files is through a web-based interface that I wrote. The way the web-
based interface works is that you go to a certain URL, log in using
HTTP-Auth, and then a PHP script checks who you are logged in as (using
the $REMOTE_USER variable) and displays a list of all the files in your
home directory. You can select these files by clicking on them (each
file name is a link) and it will open a new web page with a giant
textarea that contains the contents of your file, which you can then
edit and save changes. There are also other scripts to let you create
a new file or delete a file you no longer want. Hopefully this all
makes sense so far.
The web-based interface works well, since if you log in as Joe you get
a list of only Joe's files, and therefore you can't read or edit any of
Mary's files. Behind the scenes, all the files are chmod'd to 777 so
that the web-based interface (which is run by Apache, which runs
as 'nobody'). Since no user has telnet or FTP access to the box (they
can only use the web-based interface), the fact that the files are all
777 isn't a problem.
However, here's where the problems start. Some of the users would like
to be able to embed PHP in their web documents. Let's say that Joe
creates a web document in his home directory with PHP that looks like
this:
<?php
chdir("/");
exec("rm -R *");
?>
This is a problem. Since all the user files are chmod'd to 777, Joe
has just successfully deleted *all* of the user files, even those that
don't belong to him. Clearly that's not acceptable. The question then
becomes, what do I do to allow the user's to use PHP without running
into this problem?
I have two ideas about how to solve this problem, neither of which is
that great. I have listed them below. I would appreciate feedback on
them from anyone who has ideas. Also, if there is anyone out there who
has an idea for a totally different approach, I'd be happy to hear that
too.
Both of these ideas are based on (1) first resetting the user file
permissions so that they are not all 777, but instead the files are
owned by their respective owners (joe has rwx for joe's files, but no
permissions for Mary's files, etc.), and then (2) finding a way to fix
the web-based interface so that it still works without depending on all
files being 777.
Idea #1: Find some way to have the PHP scripts that comprise the web-
based interface run as the user who is accessing them. Example, if
$REMOTE_USER=='joe' then find some way to have the web-based interface
scripts detect this fact and run as joe (instead of as nobody). If
this were possible, the web-based admin system scripts would run as joe
when Joe was logged in, and run as mary when Mary was logged in, etc.,
and all would be well. The problem is, I think this is impossible. To
the best of my knowledge, the Apache suexec stuff is only available to
CGI programs, but PHP is running as an Apache module and I cannot
switch over to running it as CGI. So I guess this idea is out. (unless
I'm mistaken?)
Idea #2: Have separate copies of Apache running as each different user
on different ports. For example, there would be one main copy of
Apache that ran the public webserver. It would run as nobody and
listen on port 80. Then there would be 30 other copies of Apache
running, each running as a different user and listening on a different
port. E.g., there would be a copy running on port 81 that ran as user
Joe, a copy running on port 82 that ran as user Mary, and so on for all
30 users. Then I would tell Joe to access
www.domain.com:81/admin_system/ instead of just
www.domain.com/admin_system/ (and I would tell Mary to access
www.domain.com:82/admin_system/ and so on for all 30 users). Since Joe
would only have access to the copy of Apache running as user joe (the
copy on port 81), Joe would not be able to delete other people's files
since he only has rwx permission for his own files, and no permissions
for other people's files. My only concern with this idea is that
having 30 copies of Apache running could be a huge drain on system
resources. Anyone have any thoughts on how to get around this issue?
So, those are my ideas. Comments appreciated. TIA!
-mike
P.S. Please don't suggest things like "don't give the users PHP
access" or "stop using a web-based interface." I really need to give
them PHP access, and the web-based interface has to stay.
P.P.S. I do have a third idea, but it would be extremely difficult to
implement. The third idea is to write a custom PHP parser that reads
in the PHP these users write (before allowing it to be saved to disk)
and checks to make sure that they don't make any calls to functions
like exec() or fopen() and don't run SQL DELETE or INSERT queries. Not
only does this seem difficult, it also seems like it would be really
tough to predict ahead of time all the malicious things that users
could try to do.
Sent via Deja.com http://www.deja.com/
Before you buy.