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 [email protected] http://lists.marsching.biz/mailman/listinfo/suphp
