0

I asked this question before here but user CheekySoft pointed out that I was "asking how to implement my proposed solution" where instead I should just "state my problem and ask for solution ideas". So here goes.

On the linux server I have the files set up like so

/home
├──  user1
│   ├── [-rwx------]  index.html
│   └── [-rwx------]  index.php
└──  user2
    ├── [-rwx------]  index.html
    └── [-rwx------]  index.php

If I have Apache virtual hosts set up at

<Directory /home/user1>`
<Directory /home/user2>

Then [any] user can go to www.example.com/user1/index.html or www.example.com/user2/index.html. However, the permissions on those files are 0700, therefore, they are inaccessible over the web. It is for this reason that I am using suPHP.

For the sake of argument, lets say index.php has only the following in it

index.php:

<?php
echo file_get_contents('index.html');
exit();
?> 

Now, with suPHP set up, user1 can go to www.example.com/user1/index.php to view index.html. Likewise, user2 can go to www.example.com/user2/index.php to view index.html. However, user1 can also go to www.example.com/user2/index.php to view user2's index.html page, and vice versa for user2.

The natural way to deal with this is through PHP sessions. All requests to a page are redirected to a main page (ie. www.facebook.com), the user is validated against the database, and then redirected to the correct page (see image below).

User Interaction diagram

The users would go to a page (ie. www.example.com/page1.html), and then there would be a portion of page 1 hard coded to ensure a valid session exists. If it exists, the page is loaded. If it does not exist, the user is redirected to, in this case, index.html. After they login and a valid session is established, they are redirected back to the original page. We can modify index.php to carry this out:

indexValidate.php:

<?php
//this is purely pseudo code, I can't guarantee it will work
session_start();
require_once 'Session_Validator.php';
$sv = new Session_Validator();
$sv->validate($un, $pwd);

echo file_get_contents('index.html');
exit();
?>

However, In my design, these pages (page1.html, page2.html...) are in the users own directory (index.html, index.php), therefore, the server can't demand that they have this hard coded section checking for a valid section. The user can simply edit the file to remove out this section. Of course this would be stupid on the user's part, but I don't want the user to have to modify every single one of their files to have a session check section at the top. I want this to be seamless.

A few notes:

  1. I can use Apache to redirect all requests to a single validateUser.php script which, validates the user then, if valid, calls the original script requested. However, this has the side effect that suPHP has now already switched to a user, most likely var-www
  2. I do not want to use Apache web login authentication

Can anyone provide a solution to my problem?

Community
  • 1
  • 1
puk
  • 16,318
  • 29
  • 119
  • 199
  • I am fairly confident my question has no solution http://stackoverflow.com/a/9561335/654789 – puk Mar 06 '12 at 04:39

1 Answers1

1

How about creating an apache rewrite rule for all the users and create one single PHP wrapper for all the HTML pages

The RewriteRule could be something like:

RewriteCond %{REQUEST_URI} !^/auth
RewriteRule ^(.*) /auth/wrapper.php?uri=$1

And in wrapper.php:

  1. Check if user is validated. If not, redirect to /auth/validate.php?redirect=<where-I-came-from>
  2. If validated, load the file mentioned in uri=<...>

    echo file_get_contents('<...>');

EDIT: You can create symbolic links to the wrapper.php and then set the permissions on the symbolic link to the user. you could do this in the auth folder:

ln -s wrapper.php username1.php
chown -h username1:username1 username1.php

Then you wil get a folder like this:

-r--r--r--. 1 var-www   var-www   15 march   3 12:45 wrapper.php
lrwxrwxrwx. 1 username1 username1 17 march   3 12:47 username1.php -> wrapper.php
lrwxrwxrwx. 1 username2 username2 17 march   3 12:52 username2.php -> wrapper.php
lrwxrwxrwx. 1 username3 username3 17 march   3 12:52 username3.php -> wrapper.php

Please note: The user must be able to read the auth directory To make it even more secure you can put the wrapper.php in a separate directory.

Bjørne Malmanger
  • 1,457
  • 10
  • 11
  • I tried that before. The problem is who owns `wrapper.php`? If the owner is apache then `wrapper.php` is run as user apache (I think it's `www-data`), and *I think* when that script tries to access, for example, `/home/user1/index.php`, that file has permissions `0700` and a different owner, so it can't execute it (can't read `/home/user1/index.html` for the same reason). – puk Mar 03 '12 at 02:05
  • Now I could make a wrapper class for each user, owned by the user, so when called by the user, suPHP runs the script **as** that user. But then how do I restrict the user from modifying that file (it is extremely sensitive after all)? Can I somehow put all these 'user' files in a separate directory where the user can't access but Apache can? You might be onto something. Can a file be owned by a user other than the parent directory's owner (sticky directories excluded)? – puk Mar 03 '12 at 02:11
  • But would suPHP use the owner of the symbolic link, or the actual file? I used something like so: `/etc/validator (var-www 0700)`, `/etc/validator/user1 (var-www 0700)` and `/etc/validator/user1/validate.php (user1 0700)`. This way the file belongs to user1, but because user1 does not have access to `validator/`, or `user/`, then they can not edit the file =) – puk Mar 04 '12 at 11:20
  • Of course your solution has the added benefit that there is only a single copy of the file. – puk Mar 04 '12 at 11:21
  • I'm pretty sure your solution won't work. I get the following error "UID or GID of symlink `/auth/username1.php` is not matching its target" – puk Mar 05 '12 at 00:21
  • Neither of our solutions will work as suPHP will not execute scripts if the user does not own both the file and all parent directories up to the document root http://www.hurricanehost.com/billing/knowledgebase.php?action=displayarticle&id=34 – puk Mar 05 '12 at 03:39