Everything

php

new security related directive for php-4.3.4

php.internals

Unnamed Person

22 years ago

Hi internals,

I added "virtual_root_level" new security related directive
into php-4.3.4.

Full description with the patch can be found in here

http://www.boulat.net/projects/virtual_root_level/

Some feedback/comments would be appreciated.

Regards,
Boulat

Ilia A.

22 years ago

No new features are being accepted into the 4.3.X tree, only bug fixes.
The patch itself seems to duplicate the open_basedir functionality anyway.

Ilia

On March 19, 2004 12:48 pm, boulat@funio.com wrote:

Rasmus Lerdorf

22 years ago

So if your script is:

/path1/path2/path3/foo.php

And your virtual_root_level is set to 2 then foo.php will be able to open
files anywhere under /path1/path2

How is that different from simply setting open_basedir to /path1/path2 ?

Is it because you have a bunch of different paths for every user and you
don't want to add all these to your open_basedir list?  It seems a bit
fishy to me.  There is nothing wrong with have vhost-specific open_basedir
settings.

-Rasmus


On Fri, 19 Mar 2004 boulat@funio.com wrote:

Unnamed Person

22 years ago

> So if your script is:
>
>   /path1/path2/path3/foo.php
>
> And your virtual_root_level is set to 2 then foo.php will be able to open
> files anywhere under /path1/path2
>
> How is that different from simply setting open_basedir to /path1/path2 ?
>
> Is it because you have a bunch of different paths for every user and you
> don't want to add all these to your open_basedir list?

Bingo, I have too many clients to add them all, instead determining the
value on the fly is the best way to go IMHO.

> It seems a bit
> fishy to me.  There is nothing wrong with have vhost-specific >open_basedir
> settings.

Agreed, but for me it seems that using that directive would save you time
and would make your vhost-specific settings shorter, especially if all
your virtual hosts are located in the same directory-tree.

Ilia A.

22 years ago

On March 19, 2004 01:19 pm, boulat@funio.com wrote:

> Bingo, I have too many clients to add them all, instead determining the
> value on the fly is the best way to go IMHO.

If you have many clients you probably should've automated the account creation
process and modification of all the appropriate config files including
httpd.conf. As such as it would be trivial to add 1 line to every virtual
host, that would limit the PHP's ability to open files to that user's
directories.

Ilia

Unnamed Person

22 years ago

> On March 19, 2004 01:19 pm, boulat@funio.com wrote:
>> Bingo, I have too many clients to add them all, instead determining the
>> value on the fly is the best way to go IMHO.
>
> If you have many clients you probably should've automated the account
> creation
> process and modification of all the appropriate config files including
> httpd.conf. As such as it would be trivial to add 1 line to every virtual
> host, that would limit the PHP's ability to open files to that user's
> directories.

The reason why I would want to play with settings in php.ini or/and
httpd.conf often is because everytime I modify those config files I MUST
restart apache in order for changes to take place, meaning I will have
DOWNTIME. Now imagine hundreds of new accounts added per day to your
hosting machine, that means the webserver will end up getting restarted
hundreds of times... Hundreds of seconds per day add up to minutes of
downtime... and as we all know downtime is something everyone tries to
avoid at all costs.

Cheers.

Rasmus Lerdorf

22 years ago

On Fri, 19 Mar 2004 boulat@funio.com wrote:

> The reason why I would want to play with settings in php.ini or/and
> httpd.conf often is because everytime I modify those config files I MUST
> restart apache in order for changes to take place, meaning I will have
> DOWNTIME. Now imagine hundreds of new accounts added per day to your
> hosting machine, that means the webserver will end up getting restarted
> hundreds of times... Hundreds of seconds per day add up to minutes of
> downtime... and as we all know downtime is something everyone tries to
> avoid at all costs.

That's a good point.  But this implementation still doesn't seem very
slick to me.  What about something like:

open_basedir = /var/www/{user}/public_html

Where {user} would map to the owner of the script being executed.  Other
things that might be supported as well:  {group}, {regex:a.*$}, {host}
and probably other things as well.  I haven't thought through this very
much yet, but that seems like a more flexible approach to this problem.

-Rasmus

Ilia A.

22 years ago

Restarting apache takes roughly 1 second. Your argument about hundreds of
accounts being added each time implies that you intend to have A LOT of users
who may end up using PHP on a single machine. Based on this 'guestimate'
within 1 month you intend to have 3000+ users on a single machine. Now, I am
simply curios as to what hardware do you have that supports this wonder?

Additionally apache HUP does not affect users as current requests are sent 1st
and then apache is restarted, the entire process is transparent to the user,
for whom a 1 second delay is hardly noticeable. Download & generation of most
pages will take >1 second anyway.

As for Rasmus' idea of adding various options and possibly regular expression.
open_basedir works right now with a minimum amount of overhead in most
situations. Which still makes the file operations a fair bit slower, but
certainly acceptable loss given the security benefits. However, adding more
options, that would make open_basedir resolving quite a bit slower will
quickly tip the scales in favor of performance. With complex file system
operation checks, you certainly will not be able to host anywhere near 3000
users.

Ilia


On March 19, 2004 03:43 pm, Rasmus Lerdorf wrote:

Rasmus Lerdorf

22 years ago

On Fri, 19 Mar 2004, Ilia Alshanetsky wrote:

> As for Rasmus' idea of adding various options and possibly regular expression.
> open_basedir works right now with a minimum amount of overhead in most
> situations. Which still makes the file operations a fair bit slower, but
> certainly acceptable loss given the security benefits. However, adding more
> options, that would make open_basedir resolving quite a bit slower will
> quickly tip the scales in favor of performance. With complex file system
> operation checks, you certainly will not be able to host anywhere near 3000
> users.

If you are using open_basedir at all, you have already given up all hope
of any sort of performance.

-Rasmus

Ilia A.

22 years ago

On March 19, 2004 04:05 pm, you wrote:

> If you are using open_basedir at all, you have already given up all hope
> of any sort of performance.

Certainly, but this would make the existing situation much worse then it
already is. Ideally fastcgi or ap2 should be used where it is possible to
make the web server processes run under the user's account hence avoiding the
needed for open_basedir, safe_mode, etc... all together.

Ilia

Rasmus Lerdorf

22 years ago

On Fri, 19 Mar 2004, Ilia Alshanetsky wrote:

> On March 19, 2004 04:05 pm, you wrote:
> > If you are using open_basedir at all, you have already given up all hope
> > of any sort of performance.
>
> Certainly, but this would make the existing situation much worse then it
> already is. Ideally fastcgi or ap2 should be used where it is possible to
> make the web server processes run under the user's account hence avoiding the
> needed for open_basedir, safe_mode, etc... all together.

The code could easily be written such that there is virtually no
performance degradation unless the dir actually contains a {} component,
so I don't buy that argument.  We are always trading convenience for
performance here.

-Rasmus

Unnamed Person

22 years ago

> On March 19, 2004 04:05 pm, you wrote:
>> If you are using open_basedir at all, you have already given up all hope
>> of any sort of performance.
>
> Certainly, but this would make the existing situation much worse then it
> already is. Ideally fastcgi or ap2 should be used where it is possible to
> make the web server processes run under the user's account hence avoiding
> the
> needed for open_basedir, safe_mode, etc... all together.

So then following your logic why not remove open_basedir,safe_mode,etc all
together from PHP, just to increase the performance?

However, if you do decide to keep those since
"the alternatives at the web server and OS levels aren't very realistic,
many people, especially ISP's, use safe mode "
why not improve open_basedir, safe_mode, etc.. security options making PHP
even more popular and robust?

Cheers,
Boulat.