Hi,
On Sat, 26 Nov 2005 11:57:45 -0500, in php.internals
[EMAIL PROTECTED] (Daniel Convissor) wrote:
>If you have some suggestions for documentation improvements, make a patch
>against http://cvs.php.net/phpdoc/en/features/safe-mode.xml, post the
>patch on a website somewhere then open a docume
Hi Peter:
On Fri, Nov 25, 2005 at 11:22:32AM +0100, Peter Brodersen wrote:
> I don't think anybody disagrees about this. I'm just curious about
> documenting some recommendations.
If you have some suggestions for documentation improvements, make a patch
against http://cvs.php.net/phpdoc/en/featu
On Fri, 25 Nov 2005 09:39:34 -0800, in php.internals
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
>I think that is a pretty good idea actually. It's the uid matching that
>is the problem. Having a way to restrict which commands the exec
>functions can execute is sort of a separate thing that is s
Hello Matthias,
could you please change to an email client that doesn't scramble
the message id's?
marcus
p.s.: this issue nerves a lot since we loose context. And from time to time
it has to be mentioned it seems :-)
Friday, November 25, 2005, 1:33:12 PM, you wrote:
>> >> I have always main
Christopher Kunz wrote:
Peter Brodersen wrote:
Well, safe_mode could prevent someone of doing a
shell_exec("cat /home/otheruser/web/config.php");
open_basedir can't do the same thing.
Even if open_basedir could restrict the location of the called
executable people could still upload a binary t
Matthias Pigulla wrote:
Well, safe_mode could prevent someone of doing a shell_exec("cat
/home/otheruser/web/config.php"); open_basedir can't do the same
thing.
We were in a continual losing race against that sort of thing though.
In pretty much every single release there have been ways to
d
> >> I have always maintained that shared hosts should be running
> >> per-security context Apache instances as different users.
> >
> > The problem with that is that it makes name-based virtual
> hosts pretty
> > pointless because each apache instance will at least need an ip
> > address on i
That's why you can't assure security...
Please read: ... this special type of security...
Regards,
A.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 25.11.2005 um 10:51 schrieb Matthias Pigulla:
Because of bugs in the safe_mode implementation (forgetting some
checks?) or conceptual problems?
Safe mode doesn't work 'cos there are lots of third party libraries
which PHP relies on and don't take care of the safe mode. That's why
you c
Hi,
On Thu, 24 Nov 2005 15:55:10 -0800
"Sara Golemon" <[EMAIL PROTECTED]> wrote:
> > Well, safe_mode could prevent someone of doing a
> > shell_exec("cat /home/otheruser/web/config.php");
> > open_basedir can't do the same thing.
> >
> disabled_functions=shell_exec, etc
This is pretty much
Peter Brodersen wrote:
> Well, safe_mode could prevent someone of doing a
> shell_exec("cat /home/otheruser/web/config.php");
> open_basedir can't do the same thing.
>
> Even if open_basedir could restrict the location of the called
> executable people could still upload a binary to their own dir
Hi,
On Thu, 24 Nov 2005 16:23:05 -0800
Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Yep, completely right. We came to the conclusion a long time ago that
> safe_mode isn't safe, and keeping it around is just going to continue
> giving people a false sense of security (and PHP a bad name).
I don't
Hi,
On Thu, 24 Nov 2005 14:12:32 -0800
Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> > Well, safe_mode could prevent someone of doing a
> > shell_exec("cat /home/otheruser/web/config.php");
> > open_basedir can't do the same thing.
> We were in a continual losing race against that sort of thing tho
> > Well, safe_mode could prevent someone of doing a shell_exec("cat
> > /home/otheruser/web/config.php"); open_basedir can't do the same
> > thing.
> >
> disabled_functions=shell_exec, etc
But safe_mode is more safe because it disables these functions
altogether? It's difficult to maintain
> > Well, safe_mode could prevent someone of doing a shell_exec("cat
> > /home/otheruser/web/config.php"); open_basedir can't do the same
> > thing.
>
> We were in a continual losing race against that sort of thing though.
> In pretty much every single release there have been ways to
> do th
Well, safe_mode could prevent someone of doing a
shell_exec("cat /home/otheruser/web/config.php");
open_basedir can't do the same thing.
disabled_functions=shell_exec, etc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yep, completely right. We came to the conclusion a long time ago that
safe_mode isn't safe, and keeping it around is just going to continue
giving people a false sense of security (and PHP a bad name).
Andi
At 02:12 PM 11/24/2005, Rasmus Lerdorf wrote:
Peter Brodersen wrote:
Well, safe_mode
Peter Brodersen wrote:
Well, safe_mode could prevent someone of doing a
shell_exec("cat /home/otheruser/web/config.php");
open_basedir can't do the same thing.
We were in a continual losing race against that sort of thing though.
In pretty much every single release there have been ways to do t
Hi,
On Thu, 24 Nov 2005 09:11:53 -0800
Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> > I'm not looking for any near-safe_mode-substitution. I'm more
> > concerned about the deployment of PHP6 at shared hosts.
> These shared hosts really should be using open_basedir. We have
> confused them by hav
Actually, three: code blocks, interpolation of complex variables, and
string indexing.
- Andrei
On Nov 24, 2005, at 3:22 AM, Jani Taskinen wrote:
True. But having two purposes for {} is not good either.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
Peter Brodersen wrote:
On Tue, 22 Nov 2005 18:57:19 +0100 (CET), in php.internals
[EMAIL PROTECTED] (Derick Rethans) wrote:
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also d
On Tue, 22 Nov 2005 18:57:19 +0100 (CET), in php.internals
[EMAIL PROTECTED] (Derick Rethans) wrote:
>On 11 and 12 November a bunch of us had a developers meeting in Paris,
>discussing the things we want to do for PHP 6. Partly because of the
>Unicode support, but we also discussed the items on
On Thu, 24 Nov 2005, Matthias Pigulla wrote:
Admittedly this is ugly to read but the same thing on the other side is
$var[$x][$y] vs. $var[$x]{$y}.
True. But having two purposes for {} is not good either.
And most of the time it's up to the coders how they use the existing
features
> -Ursprüngliche Nachricht-
> Von: Jani Taskinen [mailto:[EMAIL PROTECTED]
> We could start with making it an E_ERR..erm..E_STRICT notice
> if you use {} with arrays or [] with strings. And really separate
> them in PHP 6. But does it make any sense?
At least some people
On Thu, 24 Nov 2005, Jakub Vrana wrote:
4.5 Cleanup for {} vs. []
It was already discussed. Many people would be confused from
documentation statement "[] was marked as deprecated in 4.0.6 - 5.1
but then suddenly {} was deprecated instead and removed in 6.0" and
many scripts would refuse to wo
Derick Rethans wrote:
> On 11 and 12 November a bunch of us had a developers meeting in Paris,
> discussing the things we want to do for PHP 6. Partly because of the
> Unicode support, but we also discussed the items on "Rasmus' wishlist"
> and a lot of other items. I made a report of the discussio
On Wednesday 23 November 2005 16:40, Christian Schneider wrote:
> As far as named parameters go: I can live with the decision as we use
> our own patch for that anyway
Christian,
Where are the details on this patch?
Kind Regards,
--
Ian P. Christian ~ http://pookey.co.uk
--
PHP Internals - P
Derick Rethans wrote:
discussing the things we want to do for PHP 6. Partly because of the
The whole list of decisions is very reasonable, congratulations!
My only gripe is about the removal of curly braces for string offsets: I
very much like the way you undeprecated var ('As there is no rea
Marcus,
I agree that we should work together on this, so that we can achieve the
best result possible and to avoid duplicate work. To a certain degree,
we have already worked together on this, when you suggested using the
__autoload mechanism to resolve namespace imports and this is what I
en
Hello Derick,
Tuesday, November 22, 2005, 7:26:56 PM, you wrote:
> On Tue, 22 Nov 2005, Jessie Hernandez wrote:
>> I saw the notes regarding namespaces, and it really suprised me that the
>> namespace patch was not looked at in detail, discarded, and then the approach
>> that was agreed on was _
Hello Jessie,
Tuesday, November 22, 2005, 7:57:47 PM, you wrote:
> Rasmus Lerdorf wrote:
>>
>> The entire meeting was exclusively about PHP 6. We are too far along in
>> the 5.1 process to make any large changes at this point.
>>
> Actually, I did not mean to include it in the current 5.1 ve
Rasmus Lerdorf wrote:
The entire meeting was exclusively about PHP 6. We are too far along in
the 5.1 process to make any large changes at this point.
Actually, I did not mean to include it in the current 5.1 version (as
that's about to be released), but I was hoping for it to make it in
Jessie Hernandez wrote:
The way the sentence was worded at
http://www.php.net/~derick/meeting-notes.html#name-spaces led me to
believe this:
"First we briefly discussed the current name space patch, but as we were
not all familiar with its workings we did not go into deep detail for
this. Th
Hi Rasmus,
The way the sentence was worded at
http://www.php.net/~derick/meeting-notes.html#name-spaces led me to
believe this:
"First we briefly discussed the current name space patch, but as we were
not all familiar with its workings we did not go into deep detail for
this. Then we saw an
Jessie Hernandez wrote:
I saw the notes regarding namespaces, and it really suprised me that the
namespace patch was not looked at in detail, discarded, and then the
approach that was agreed on was _THE EXACT SAME ONE_ that my patch uses.
To add insult to injury, it's mentioned that Marcus was
On Tue, 22 Nov 2005, Jessie Hernandez wrote:
> I saw the notes regarding namespaces, and it really suprised me that the
> namespace patch was not looked at in detail, discarded, and then the approach
> that was agreed on was _THE EXACT SAME ONE_ that my patch uses. To add insult
> to injury, it's
Hello all,
I saw the notes regarding namespaces, and it really suprised me that the
namespace patch was not looked at in detail, discarded, and then the
approach that was agreed on was _THE EXACT SAME ONE_ that my patch uses.
To add insult to injury, it's mentioned that Marcus was going to pro
37 matches
Mail list logo
