To lock down php scripts running in a virtual host you can use the open_basedir directive in the apache conf. This will ensure that no scripts running in the directory can read files outside of the specified directory. e.g
php_value open_basedir /home/vhost/vhostsite -- Darren On Mon, Apr 07, 2003 at 09:14:15AM -0600, Vector wrote: > ----- Original Message ----- > From: "Fraser Campbell" <[EMAIL PROTECTED]> > To: <debian-isp@lists.debian.org> > Sent: Monday, April 07, 2003 7:36 AM > Subject: Privacy in virtual hosting environment > > > > Hi, > > > > Since I'm currently setting up my first shared hosting environment in a > few > > years I'm wondering how to adequately address privacy issues. > > Good, lots of 'em don't care. > > > I plan to provide python (with and without mod_python), perl (perhaps just > > CGI) as well as PHP support. Is there any way to prevent people from > > sourcing things above their document root? My main concern is db > passwords > > stored in config files or scripts. > > I tried using PHP's ini settings within each vhost to ensure people weren't > access directories outside the directory for their vhost but that didn't > work because PHP screws it all up and gets mixed up with some vhosts > parameters bleeding into others and it generates errors in a seemingly > random way. > > suexec is nice for cgi but still doesn't limit a scripts ability to read > files outside the a certain directory. It only enforces permissions. So at > first my solution to that was to restrict vhost directories by permissions > and have a separate group for each vhost that has the apache user in it and > then under that directory, everything is world readable. That way, only the > user and apache have access to the primary directory and then standard > permissions apply after that. So if suexec is running cgi as one user > another can get outside their own vhost directory but no inside anyone > elses. > e.g. > > directory, owner, group, perms > vhost1, user1, group1-apache, 750 > vhost1/htdocs, user1, group1, 755 > vhost2, user2, group2-apache, 750 > vhost2/htdocs, user2, group2, 755 > > Well that breaks down as soon as apache is in more than the maximum allowed > number of groups per user thus limiting you to that number of vhosts per > apache instance. > > > I think with apache2 and the mpm that allows different users for different > > virtual hosts it should be possible but since apache2 isn't in woody I > don't > > like the idea too much. > > that's finally what I've resorted to. Even though mpm is experimental I > have to use it anyway because it really is the best option......USE THE > SOURCE, LUKE......heheh > > > My other thoughts are to run multiple instances of apache wth different > uids, > > an alternative might be to run user mode linux or other virtual > environment. > > Both of these options seem quite resource intensive though and multiple > > apaches would require an IP for every site (I think). > > been there done that....very ugly....most secure but very ugly. It is a > pain to administer and it is pig on the box. Yes each one requires it's own > IP address if you are going to have them all listen on port 80 anyway. > > > What are you guys using? > > > > I know some that have switched to web servers like Roxen to help solve this > issue and make things more secure. I don't know if PHP will run on stuff > like that without running it as a CGI instead of having PHP built-in. > I know of admins that have run separate instances of apache like you mention > above. > > vec > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
