On Fri, Aug 24, 2007 at 01:53:13PM -0700, Matthew W Marcus wrote:
> Let's say I have a user on my VPS called "jimmy" with a UID of 34 and his 
> website is http://www.jimmylove.com.  Let's say I have another user on my VPS 
> called "sally" with a UID of 69 and her website is http://www.prettysally.com.
> 
> If we go to a browser and type in http://www.jimmylove.com/~sally, then here 
> is what happens:
> 
> suPHP attempts to have the user "jimmy" access and open sally's website index 
> file.  This happens because we are using jimmy's website to access sally's 
> website.  Sounds strange, but I hope I'm making sense (a little hungover 
> today).
> 
> This would generate an error in the suPHP log of:
> 
> [DATE] [warn] Mismatch between target UID (34) and UID (69) of file 
> "/home/sally/public_html/index.php"
> 
> If we type in http://IP_ADDRESS/~sally, we have the situation of the user 
> "nobody" (UID = 99) attempting to access sally's index file.  This is also 
> generating a 500 error and an entry in the suPHP log of:
> 
> [DATE] [warn] Mismatch between target UID (99) and UID (69) of file 
> "/home/sally/public_html/index.php"
> 
> I hope that explains what's happening.  As far as each user, they are all a 
> part of their own group with the same name as their username.  Using our 
> example above, sally would be in the group "sally" and jimmy would be in the 
> group "jimmy"  etc etc

I had a feeling this is what was happening.  suphp is most definitely
build in force or paranoid mode (paranoid has my vote).  Your Apache
configuration more or less looks something like this:

LoadModule suphp_module libexec/apache22/mod_suphp.so

UserDir public_html

User nobody
Group nobody
ServerName www.someplace.com

AddType application/x-httpd-php .php
AddHandler x-httpd-php .php
suPHP_Engine on

<VirtualHost www.jimmylove.com>
  suPHP_UserGroup jimmy jimmy
  DocumentRoot "/home/jimmy/public_html"
</VirtualHost>

<VirtualHost www.prettysally.com>
  suPHP_UserGroup sally sally
  DocumentRoot "/home/sally/public_html"
</VirtualHost>


On the filesystem, you have the following:

drwx--x--x   22 jimmy     jimmy     1536  9 Aug 20:16 /home/jimmy/public_html/
-rw-r--r--   22 jimmy     jimmy     1536  9 Aug 20:16 
/home/jimmy/public_html/index.php

drwx--x--x   22 sally     sally     1536  9 Aug 20:16 /home/sally/public_html/
-rw-r--r--   22 sally     sally     1536  9 Aug 20:16 
/home/sally/public_html/index.php


With this configuration, the following will happen:

  http://www.jimmylove.com/           <-- OK
  http://www.prettysally.com/         <-- OK
  http://www.someplace.com/~jimmy/    <-- FAIL (runtime user nobody != jimmy)
  http://www.someplace.com/~sally/    <-- FAIL (runtime user nobody != sally)
  http://www.jimmylove.com/~jimmy/    <-- OK
  http://www.jimmylove.com/~sally/    <-- FAIL (runtime user jimmy != sally)
  http://www.prettysally.com/~sally/  <-- OK
  http://www.prettysally.com/~jimmy/  <-- FAIL (runtime user sally != jimmy)

You have UserDir enabled globally (e.g. "UserDir public_html" in the
global part of your Apache configuration).  This means _any_ of your
VirtualHosts can be used to get to any of your users' public_html
accounts, regardless of what VirtualHost.

I _strongly_ recommend against this.  I recommend you set up a single
VirtualHost (do not use the global configuration!) where users can
access http://whatever/~user/ accounts.  I also recommend avoiding
mapping VirtualHost DocumentRoots to whatever directory you choose
in your UserDir statement (e.g. public_html).

Opinions aside, if you __really__ must have the above functionality
working as documented, then there is a solution: get your provider to
rebuild suphp in "owner" mode (--with-setid-mode=owner), and remove
the suPHP_UserGroup directives from your configuration.

In that configuration, suphp will look at the user/group of every PHP
file on the filesystem, and switch the credentials of that user/group
before executing the script.

You _do not_ need the userdir patch.  I really don't understand why
that patch exists at all anyways...

-- 
| Jeremy Chadwick                                    jdc at parodius.com |
| Parodius Networking                           http://www.parodius.com/ |
| UNIX Systems Administrator                      Mountain View, CA, USA |
| Making life hard for others since 1977.                  PGP: 4BD6C0CB |

_______________________________________________
suPHP mailing list
suPHP@lists.marsching.biz
http://lists.marsching.biz/mailman/listinfo/suphp

Reply via email to