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
Hi:
On Fri, Mar 19, 2004 at 01:24:39PM -0500, David Brown wrote:
| + /* Get rid of extra nulls */
| + while (res_length > 0 && res_buf[res_length] == '\0')
| + res_length--;
| +
| Z_STRVAL_P(result) = res_buf;
| + Z_STRLEN_P(result) = res_length+1;
| Z_TYPE_P(re
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
Hi:
Attached are three patches for ext/sybase. The first two fix bugs. The
third adds a function, while at the same time removing a lot of
redundant code. In order:
php5_sybase-fetch_object.diff:
The sybase extension does not currently compile, since
sybase_fetch_object was never conve
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
Hello, interals...
Kind of stumbled onto this by accident. Some kind of FD leak in streams. In
the current HEAD (and 5.0.0 RC1, I suppose, although I didn't specifically
test that, just my CVS checkout)...
class.one.php:
class.two.php:
foo.php:
[EMAIL PROTECTED] $ php5 foo.php
Warning
Translating PHP DOC to Bangali. Any help will be higly appriciated.
Thanx
Raja shahed
Spread php everywhere
>-Ursprüngliche Nachricht-
>Von: Bernhard Mayer [mailto:[EMAIL PROTECTED]
>Gesendet: Mittwoch, 17. März 2004 16:32
>An: [EMAIL PROTECTED]
>Betreff: [PHP-DEV] CVS Account Requ
Hi,
Moriyoshi Koizumi's <[EMAIL PROTECTED]> wrote:
>No need to yell. He's already got his karma to access to
>the pear-doc module.
wow
It seems that he did not realize yet that karma is obtained.
I contact him.:)
Regards,
--
Tadashi Jokagi
--
PHP Internals - PHP Runtime Development Mailing
Hi,
> [EMAIL PROTECTED]:/install/php-5.0.0RC1# ./configure
> --with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql4
> --with-mysqli=/usr/local/mysql4_1/bin/mysql_config
> --with-pgsql=/usr/local/pgsql --disable-libxml
using two different mysql libraries will not work of course. Yo
Hello,
the following configure & make with PHP5 RC1:
[EMAIL PROTECTED]:/install/php-5.0.0RC1# ./configure
--with-apxs2=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql4
--with-mysqli=/usr/local/mysql4_1/bin/mysql_config --with-pgsql=/usr/local/pgsql
--disable-libxml
result in:
[EMAIL PRO
Hi PHP Dev guys,
(My apologies if this has been seen before, I couldn't find a reference
to this issue in the mailing list archives)
I'd like to report some trouble I had getting I had getting PHP to
configure under Fedora Core 1 for AMD64 - I couldn't get the PHP package
that came with Fedora
Clemens Gutweiler wrote:
> Change the name of 'test' to 'test2', so that this isn't anymore an
> construcor - then the E_STRICT message appears. Bug?
Damn those stupid BC-constructor-names :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das B
At 11:00 AM 3/19/2004 +0100, Clemens Gutweiler wrote:
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> On Fri, 19 Mar 2004, Sebastian Bergmann wrote:
>
> > Andi Gutmans wrote:
> > > Only if you use E_STRICT.
> >
> > Am I missing something (bear with me, I am still on
> medication :-) but
> >
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> On Fri, 19 Mar 2004, Sebastian Bergmann wrote:
>
> > Andi Gutmans wrote:
> > > Only if you use E_STRICT.
> >
> > Am I missing something (bear with me, I am still on
> medication :-) but
> > the following code does not print a warning here:
On Fri, 19 Mar 2004, Sebastian Bergmann wrote:
> Andi Gutmans wrote:
> > Only if you use E_STRICT.
>
> Am I missing something (bear with me, I am still on medication :-) but
> the following code does not print a warning here:
Because E_Strict is set at run time, and the warnings are thrown at
Andi Gutmans wrote:
> Only if you use E_STRICT.
Am I missing something (bear with me, I am still on medication :-) but
the following code does not print a warning here:
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: ht
On Fri, Mar 19, 2004 at 10:00:16AM +0100, Andrey Hristov wrote:
> Hmmm,
> looks I was kinda fooled by some script a month ago. I was suprised that
> with debug_print_backtrace() I was able to see the arguments of the stack
> since I haven't seen the same done by debug_backtrace(). But few minutes
Andi Gutmans wrote:
What else does debug_print_backtrace() include? If the info is more
maybe we should change debug_backtrace()?
In any case, in general I don't have a problem to do this. Might be
nicer if we could do it without output buffering though but I haven't
looked at the code to see ho
On Fri, 19 Mar 2004, Andi Gutmans wrote:
> What else does debug_print_backtrace() include? If the info is more maybe
> we should change debug_backtrace()?
> In any case, in general I don't have a problem to do this. Might be nicer
> if we could do it without output buffering though but I haven't l
41 matches
Mail list logo
