On March 19, 2004 06:19 pm, Rasmus Lerdorf wrote:
> This is also not the argument here. How many times have you heard me say
> that this should not be PHP's problem? It is architecturally incorrect to
> fix this problem in PHP and it can never be done correctly. However, PHP
> is also the pragma
On Fri, 19 Mar 2004, Ilia Alshanetsky wrote:
> I am not suggesting we remove open_basedir or safe_mode although I still
> maintain they are horrible kludges implemented in the wrong place as it is
> not the job of scripting language to implement file system security. Adding
> further hacks, prev
On March 19, 2004 05:42 pm, [EMAIL PROTECTED] wrote:
> So just because there might be means to bypass security options in PHP we
> shouldnt even bother improving security? Lets give up.
The issue is not the fact that these setting can be bypassed by PHP, those are
bugs to be fixed. But the fact s
On March 19, 2004 05:23 pm, Rasmus Lerdorf wrote:
> I suppose it could, but it doesn't. Have you tried it?
I've tried on a small scale.
> But people still like the efficiency and convenience of a runtime
> open_basedir check. It gets you 90% of the way there and it doesn't cost
> you that much.
> On March 19, 2004 04:28 pm, [EMAIL PROTECTED] wrote:
>> So then following your logic why not remove open_basedir,safe_mode,etc
>> all
>> together from PHP, just to increase the performance?
>
> Because it would break BC. When these options were developed Apache 2 was
> not around and fastcgi supp
On Fri, 19 Mar 2004, Ilia Alshanetsky wrote:
> Thousands of users on a single machines at least half (probably more) use
> dynamic scripts, would require some superb hardware and even then I very much
> doubt it could be done effectively. It would be far more practical and
> economical to have s
On March 19, 2004 04:46 pm, Rasmus Lerdorf wrote:
> Ilia, come back to reality man!
But it's so boring ;-).
> Are you really suggesting that people use
> Apache2 with the perchild MPM to solve this problem? If so, that's pretty
> funny. I also fail to see how fastcgi solves the thousands of u
On Fri, 19 Mar 2004, Rasmus Lerdorf wrote:
> On Fri, 19 Mar 2004, Ilia Alshanetsky wrote:
> >
> > Because it would break BC. When these options were developed Apache 2 was not
> > around and fastcgi support was flimsy at best. Using plain CGI (which MANY
> > ISPs use) to run PHP is quite resource
On Fri, 19 Mar 2004, Ilia Alshanetsky wrote:
> On March 19, 2004 04:28 pm, [EMAIL PROTECTED] wrote:
> > So then following your logic why not remove open_basedir,safe_mode,etc all
> > together from PHP, just to increase the performance?
>
> Because it would break BC. When these options were develop
On March 19, 2004 04:28 pm, [EMAIL PROTECTED] wrote:
> So then following your logic why not remove open_basedir,safe_mode,etc all
> together from PHP, just to increase the performance?
Because it would break BC. When these options were developed Apache 2 was not
around and fastcgi support was fli
> 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 t
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 fa
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
> On Fri, 19 Mar 2004 [EMAIL PROTECTED] 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 hundre
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
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,
On Fri, 19 Mar 2004 [EMAIL PROTECTED] 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
> On March 19, 2004 01:19 pm, [EMAIL PROTECTED] 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 th
On Mar 19, 2004, at 7:23 PM, [EMAIL PROTECTED] wrote:
Its not really duplicating anyting in open_basedir. As a metter of
fact it
is meant to be used together with open_basedir for best results.
ISP and people doin mass hosting would mainly benefit from that patch.
By using open_basedir in combina
On March 19, 2004 01:19 pm, [EMAIL PROTECTED] 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 appropri
> 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
Its not really duplicating anyting in open_basedir. As a metter of fact it
is meant to be used together with open_basedir for best results
> 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 pat
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 us
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, [EMAIL PROTECTED] wrote:
> Hi internals,
>
> I added "virtual_root_level" new security related directive
> into php-4
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
--
PHP Internals - PHP Runtime Develo
25 matches
Mail list logo
