Re: Privacy in virtual hosting environment
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" <fraser@wehave.net>
> 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 debian-isp-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: