PDM Meeting Notes

Jessie Hernandez

20 years ago

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 provide
a patch (my problem is not with Marcus, in fact, he was very supportive
and helpful when I was writing the patch and the __autoload mechanism
I'm using is thanks to his input. My problem is that my patch was
completely ignored and someone else was assigned to write a patch, when
the one I already wrote can be used).

My patch meets all the requirements, except for the following items:

1) "The suggested separator is "\" as this is the only free choice." - I
currently use the ':' separator, but this can be easily changed.

2) "Functions in name spaces are allowed." - I added this once and
posted the patch to the list, but many (including Andi himself) agreed
that we should just stick to classes inside namespaces. The only thing I
accomplished was having the function be used as
namespace_name:my_function. If a namespace import for functions were to
work, then an __autoload for functions would need to be supported in the
engine. This has been suggested before, as having a global __call
function. With a global __call function, namespace imports can also
import functions.

3) "Constants in name spaces are allowed unless we find problems with
the implementation." - I have not tried this, but if all agree, I can
check to see how easy it would be to add this to my patch.


The attached patch is identical to what I had since August 9th, but was
updated to apply cleanly to the latest PHP 5.1 CVS version (it must be
applied before running buildconf).

I do not mean to offend anyone or point fingers, and I am sorry if my
tone is a bit harsh, but please understand that I have reason to have
felt ignored in this whole manner. If you need more information about
the "inner workings of my patch", then please email me or post your
questions to the list, and I'll be more than happy to explain.


Regards,

Jessie Hernandez


Derick Rethans wrote:

Derick Rethans

20 years ago

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 mentioned that Marcus was going to provide a patch (my problem
> is not with Marcus, in fact, he was very supportive and helpful when I was
> writing the patch and the __autoload mechanism I'm using is thanks to his
> input. My problem is that my patch was completely ignored and someone else was
> assigned to write a patch, when the one I already wrote can be used).

Hang on a bit, if it's assigned to Marcus, doesn't mean he can not work
with you on that.

regards,
Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Marcus Börger

20 years ago

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 _THE EXACT SAME ONE_ that my patch uses. To add insult
>> to injury, it's mentioned that Marcus was going to provide a patch (my problem
>> is not with Marcus, in fact, he was very supportive and helpful when I was
>> writing the patch and the __autoload mechanism I'm using is thanks to his
>> input. My problem is that my patch was completely ignored and someone else was
>> assigned to write a patch, when the one I already wrote can be used).

> Hang on a bit, if it's assigned to Marcus, doesn't mean he can not work
> with you on that.

Despite the written sentence i had namespaces on my radar for a long time
now. That i didn't do anything just reflects the current state of PHP. We
are not going to have namespaces for a list of good reasons. Your patch
and the amount of people asking for that feature started discussions all
over again. So while beeing in paris we were able to look at the following
things the stuff we knew your patch was supposed to do and the stuff we
wanted your patch to do as well as the module patch and the stuff we thought
that patch should do. After a long discussion we came to the intermediate
conclusion that it is worth to restart working on namespaces again since a
few issues we had with the first approach have been solved as of now.
However the notes show that PHP will undergo a big amount of changes
especially engine api wise. Thus i guess we won't start working on that
beforehand. If you feel to do more work on your stuff then go ahead we
might go with exactly your patch or ignore it completley when the changes
are done. That's how PHP is done and has nothing to do whetehr i plan to do
some work on my own. Indeed i could come up with a patch that would be
outrules by yours or somebody elses as well. That's open source. Things
might be ignored or removed or rewritten at any time by others. The
advantage is that we can all work together if we feel like and that by doing
so we cannot only learn from each other but reach a very good final result
(if there is such a thing as final result in software).

To cut this short. As soon as i feel like i will start to do some work. And
as soon as there is something to show i will post it. Since i always showed
my stuff were early here. Should you do something earlier i think i will try
to catch up with you and either say nothing to do for me left or send you my
thoughts by mail or try to come up with my brand own ideas.

We'll see, nothing has been made a law by those notes.

marcus

Jessie Hernandez

20 years ago

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
ended up doing.

I will try to add functions and constants soon to the patch, and will
look at the PHP 6 source to see what I need to do to make it work with
that version.


Regards,

Jessie



Marcus Boerger wrote:

Rasmus Lerdorf

20 years ago

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 going to provide
> a patch (my problem is not with Marcus, in fact, he was very supportive
> and helpful when I was writing the patch and the __autoload mechanism
> I'm using is thanks to his input. My problem is that my patch was
> completely ignored and someone else was assigned to write a patch, when
> the one I already wrote can be used).

How in the world do you know your patch was ignored?  It wasn't.  But it
also isn't going to work as-is, especially in the new Unicode world, so
it is going to take more than one person to play with it and see what
can be done.  Marcus simply volunteered to do that.

-Rasmus

Jessie Hernandez

20 years ago

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 alternative implementation of name spaces with
"Modules"".

Anyways, from what you said, is namespace support only going to be added
in PHP 6? I have been basing my patch on 5.1, hoping that it would make
it before 6, as the patch is small and has absolutely no BC problems.

Obviously, I don't agree on having to wait that long, but if that is the
case, I'll check what changes I need to do in order to apply it to PHP
6. Thanks for the clarification.


Regards,

Jessie Hernandez


Rasmus Lerdorf wrote:

Rasmus Lerdorf

20 years ago

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. Then we saw an alternative implementation of name spaces with
> "Modules"".

Yes, Dmitry has a module-based namespace patch as well.  Yours isn't
actually the only working patch on the table right now and as the notes
say, we looked at it.

> Anyways, from what you said, is namespace support only going to be added
> in PHP 6? I have been basing my patch on 5.1, hoping that it would make
> it before 6, as the patch is small and has absolutely no BC problems.

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.

-Rasmus

Jessie Hernandez

20 years ago

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 a
5.2 release, for example. Or will there be no more minor releases until 6?


Regards,

Jessie Hernandez

Marcus Börger

20 years ago

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 version (as
> that's about to be released), but I was hoping for it to make it in a
> 5.2 release, for example. Or will there be no more minor releases until 6?

There was no decison on that yet. Actually there was no real discussion on
that issue anyway. PHP is developed in a way that those decisions are done
when they are at hand. That said we are all working on getting 5.1 out of
the doors. Ass soon as we have done that there will be a bunch of MFHing
from head to 5.1.1-dev. Then there will be 5.1.1 and then..well i cannot
look deeper in my glass ball. It doesn't show anything more.

marcus

Marian Kostadinov

20 years ago

I think that automatic __toString calling for (string)$obj,
$obj.'somestring' and so on is urgent compared to other features and
should be available in 5.1.1 or at latest - 5.2.0. I suppose that
"object #XX" is not useful for anyone programming in PHP.

On 22/11/05, Derick Rethans <derick@php.net> wrote:

Stefan Walk

20 years ago

On 22/11/05, Derick Rethans <derick@php.net> wrote:

> Hello folks!
>
> 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 discussions we had and
> placed the notes here:
>
> http://php.net/~derick/meeting-notes.html
>
> regards,
> Derick

Hello,

what was the reason for the decision to drop asp tags? We are using
them in our templates because of the <%= shortcut and no conflicts
with X(HT)ML.

Regards,
Stefan

Marcus Börger

20 years ago

Hello Stefan,

"<%=" is of course also conflicting the XML specs since "<"
must be followed by a "!" is we are in a DTD context. Or a "?"
to start a processing instruction or a valid element name. And
"%" cannot start an element name.

marcus

Wednesday, November 23, 2005, 5:07:22 PM, you wrote:

> On 22/11/05, Derick Rethans <derick@php.net> wrote:
>> Hello folks!
>>
>> 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 discussions we had and
>> placed the notes here:
>>
>> http://php.net/~derick/meeting-notes.html
>>
>> regards,
>> Derick

> Hello,

> what was the reason for the decision to drop asp tags? We are using
> them in our templates because of the <%= shortcut and no conflicts
> with X(HT)ML.

> Regards,
> Stefan

> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

Best regards,
Marcus

Edin Kadribasic

20 years ago

Marcus Boerger wrote:

> Hello Stefan,
>
>    "<%=" is of course also conflicting the XML specs since "<"
> must be followed by a "!" is we are in a DTD context. Or a "?"
> to start a processing instruction or a valid element name. And
> "%" cannot start an element name.

When we are talking about asp tags we are talking about the ability of
*PHP* to parse xml documents, say in order to produce valid xhtml. PHP
will produce parse error if you have short tags enabled when trying to
parse xml, while with short tags disabled and asp tags enabled it parses
them just fine which makes it sweet for making templating of xml documents.

I really see no reason to remove a feature that at least some people
find useful, and which has no effects on those that do not have it enabled.

Edin

Stefan Walk

20 years ago

On 23/11/05, Edin Kadribasic <edink@emini.dk> wrote:

> Marcus Boerger wrote:
> > Hello Stefan,
> >
> >    "<%=" is of course also conflicting the XML specs since "<"
> > must be followed by a "!" is we are in a DTD context. Or a "?"
> > to start a processing instruction or a valid element name. And
> > "%" cannot start an element name.
>
> When we are talking about asp tags we are talking about the ability of
> *PHP* to parse xml documents, say in order to produce valid xhtml. PHP
> will produce parse error if you have short tags enabled when trying to
> parse xml, while with short tags disabled and asp tags enabled it parses
> them just fine which makes it sweet for making templating of xml documents.
>
> I really see no reason to remove a feature that at least some people
> find useful, and which has no effects on those that do not have it enabled.
>
> Edin

Exactly. PHP chokes on <?xml if short tags are enabled.

Regards,
Stefan

Jani Taskinen

20 years ago

On Thu, 24 Nov 2005, Stefan Walk wrote:

> Exactly. PHP chokes on <?xml if short tags are enabled.

And just because of that we're removing those too. >:)

--Jani

Daniel Convissor

20 years ago

Hi Edin, et al:

On Wed, Nov 23, 2005 at 11:59:16PM +0100, Edin Kadribasic wrote:

>
> PHP
> will produce parse error if you have short tags enabled when trying to
> parse xml, while with short tags disabled and asp tags enabled it parses
> them just fine which makes it sweet for making templating of xml documents.

How PHP chokes on <?xml tags when short tags is enabled is compleltely
silly.  There's a patch here to fix it,
http://news.php.net/php.internals/18493, some proof of why it's a problem,
http://news.php.net/php.internals/18496, and the "bogus" (yeah, right) bug
report, http://bugs.php.net/bug.php?id=25987.

--Dan

--
T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

Sara Golemon

20 years ago

> How PHP chokes on <?xml tags when short tags is enabled is compleltely
> silly.  There's a patch here to fix it,
> http://news.php.net/php.internals/18493, some proof of why it's a problem,
> http://news.php.net/php.internals/18496, and the "bogus" (yeah, right) bug
> report, http://bugs.php.net/bug.php?id=25987.
>

As the author of the patch you mentioned, I should reitterate that I don't
think that it's a *good* fix.  Treating <?xml as special is a hack, not a
broadband solution.

-Sara

Marcus Börger

20 years ago

Hello Sara,

Sunday, November 27, 2005, 3:39:40 AM, you wrote:

>> How PHP chokes on <?xml tags when short tags is enabled is compleltely
>> silly.  There's a patch here to fix it,
>> http://news.php.net/php.internals/18493, some proof of why it's a problem,
>> http://news.php.net/php.internals/18496, and the "bogus" (yeah, right) bug
>> report, http://bugs.php.net/bug.php?id=25987.
>>
> As the author of the patch you mentioned, I should reitterate that I don't
> think that it's a *good* fix.  Treating <?xml as special is a hack, not a
> broadband solution.

To second this, the xml standard allows any name after '<?' as processing
instruction. Widely in use is for example '<?jsp' and do you want to start
special treatment for java stuff in PHP?  ;-)

Best regards,
Marcus

Daniel Convissor

20 years ago

Hi Marcus:

On Sun, Nov 27, 2005 at 11:58:16AM +0100, Marcus Boerger wrote:

>
> To second this, the xml standard allows any name after '<?' as processing
> instruction. Widely in use is for example '<?jsp' and do you want to start
> special treatment for java stuff in PHP?  ;-)

First, PHP scripts are not XML files, so why are we concerned with what
the XML standard says?

Second, PHP is frequently used to output XML files, necessitating such PHP
scripts contain the string "<?xml" in them.  But in order to ensure
scripts work when short tags is on, one must write something contorted
like:

echo '<' . '?xml ...';

Third, if someone wrote a script using "<?xml" with short tags off instead
of the above, PHP needlessly fails if short tags is on, eliminating
portability.

--Dan

--
T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

Johannes Schlueter

20 years ago

Hi,

On Sunday 27 November 2005 22:20, Daniel Convissor wrote:

> First, PHP scripts are not XML files, so why are we concerned with what
> the XML standard says?

It isn't about the XML standard but about exceptions for the PHP parser and
why should <?xml be treated different from <?jsp or <?xsl or <?foo or ...
which all are used (hm, not sure about <?foo) and sometimes even in
combination with PHP.

> Second, PHP is frequently used to output XML files, necessitating such PHP
> scripts contain the string "<?xml" in them.  But in order to ensure
> scripts work when short tags is on, one must write something contorted
> like:
>
>   echo '<' . '?xml ...';

echo '<?xml ...';

just works fine.

> Third, if someone wrote a script using "<?xml" with short tags off instead
> of the above, PHP needlessly fails if short tags is on, eliminating
> portability.

so just remove short_tags :-)

johannes

Matthew Charles Kavanagh

20 years ago

On Sun, 2005-11-27 at 22:32 +0100, Johannes Schlueter wrote:

> It isn't about the XML standard but about exceptions for the PHP parser and
> why should <?xml be treated different from <?jsp or <?xsl or <?foo or ...
> which all are used (hm, not sure about <?foo) and sometimes even in
> combination with PHP.

I recall this being discussed before, but not what came of it: is there
a problem with just ignoring <?foo where foo is anything other than php
or =? <?foo or <?bar or <?whatever is a parse error anyway so I very
much doubt there's any BC break. Unless someone's program relies on
parse errors.

Christian Schneider

20 years ago

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 real reason
why we should remove it, we agreed on simply making "var" an alias to
"public" and removing the warning"') and I think curly braces for string
offsets should be treated the same way.

As far as named parameters go: I can live with the decision as we use
our own patch for that anyway ;-)

- Chris

Ian P. Christian

20 years ago

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

Jakub Vrana

20 years ago

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 discussions we had and
> placed the notes here:
> http://php.net/~derick/meeting-notes.html

I really appreciate your effort in this and offer my feedback:

> 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 work due to this.

> 4.9 Make parameter order consistent over all functions

Others talked probably about:

str_replace(needle, replace, haystack) - compare with e.g. SQL
REPLACE(haystack, needle, replace)

ereg(pattern, haystack)

etc. But I am also against changing the parameters order.

> 4.10 Minor function changes: microtime()

You showed that the most common usage of this function without
parameters remain working (with E_NOTICE) but what's with other
usages? Gain from this change is really minimal but cause that some
code working in PHP 4 will not work in PHP 6 without ugly hacks.

Jakub Vrana

Jani Taskinen

20 years ago

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 work due to this.

That's why we wanted to add the E_STRICT warning about it..
But I'd rather have this whole issue changed back to what
it really was about: separating [] and {} altogether.

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?

Removing {} is ultimately the right thing to do, whatever the
anti-purists may think. "{$str{1}}" vs. "{$str[1]}", you decide..

--Jani

Peter Brodersen

20 years ago

On Tue, 22 Nov 2005 18:57:19 +0100 (CET), in php.internals
derick@php.net (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 discussions we had and
>placed the notes here:
>
>http://php.net/~derick/meeting-notes.html

Very interesting - thanks for the details. It all sounds very
promising.

Regarding safe_mode I agree that I'll never be any kind of magic
wundertool. But as the docs also specify, many shared hosts currently
"rely" on it (meaning they have setups where the users don't have
shell opportunities or other ways of accessing each other's files).

I'm not looking for any near-safe_mode-substitution. I'm more
concerned about the deployment of PHP6 at shared hosts.

Since PHP6 have a bunch of different changes and requires a lot of
information I think there should be put an effort of creating a "best
practices" document for these kind of setups. Something like enabling
open_basedir and disabling exec-functions (popen, exec, shell_exec,
passthru...). Maybe a new setting to disable all of these typies of
functions together - I don't think it is a pretty solution to e.g.
blacklist about six specific functions and hoping that this list is
static.

Furthermore, and just a though: would it be possible to have an option
when compiling an apache module of setting the open_basedir value to
the same as the virtual host's DOCUMENT_ROOT? I think deployment could
be much easier this way.


(oh yeah, and I really hope glob() results would be passed through
open_basedir checks... furthermore I want a pony!)

--
- Peter Brodersen

Rasmus Lerdorf

20 years ago

Peter Brodersen wrote:

> On Tue, 22 Nov 2005 18:57:19 +0100 (CET), in php.internals
> derick@php.net (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 discussions we had and
>> placed the notes here:
>>
>> http://php.net/~derick/meeting-notes.html
>
> Very interesting - thanks for the details. It all sounds very
> promising.
>
> Regarding safe_mode I agree that I'll never be any kind of magic
> wundertool. But as the docs also specify, many shared hosts currently
> "rely" on it (meaning they have setups where the users don't have
> shell opportunities or other ways of accessing each other's files).
>
> 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 having both directives, and I see some even enable both
safe_mode and open_basedir on top of each other which doesn't make much
sense.  Shared hosts really should be setting an open_basedir on a
per-vhost basis.  This will fix file uploads and a number of other
issues and is every bit as safe (or unsafe depending on how you look at
it) as safe_mode.

-Rasmus

Peter Brodersen

20 years ago

Hi,

On Thu, 24 Nov 2005 09:11:53 -0800
Rasmus Lerdorf <rasmus@lerdorf.com> 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 having both directives, and I see some even enable both
> safe_mode and open_basedir on top of each other which doesn't make much
> sense.

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 directory.

That's the part I liked about safe_mode. Not the words "safe", but the
grouping of exec-like functions into one setting. A new php user might
not know all the different kinds of exec-functions thus it would be
easier to forget one or two functions when blacklisting a bunch of
functions that were able to run executables.

I still think it would be nice with a "best practice for shared hosts"
page, maybe under the security section of the manual. Currently the part
about Filesystem Security mainly looks into script based security and
not configuration based security. The part about "Installed as an Apache
Module" just suggests that open_basedir itself will restrict access to
specific directories, but users could still run executables,
circumventing this restriction.

So, what would the "best practice" recommendation be?

- open_basedir restriction plus disable
exec+passthru+proc_open+shell_exec+system+popen+pcntl_exec(+dl)?
- jail users into hell?
- or something third?

> Shared hosts really should be setting an open_basedir on a
> per-vhost basis.  This will fix file uploads and a number of other
> issues and is every bit as safe (or unsafe depending on how you look at
> it) as safe_mode.

Yeah, my though was just to help automate this process. Of course the
larger web service providers would have automated their virtual host
generation and Apache2 users might just use mod_macro. Personally I feel
it kind of redundant to specify the users document_root as their open_basedir
value (although other might want to allow one level up giving users a
possibility of putting variables out of web scope - this is besides the
point though).

--
- Peter Brodersen

Rasmus Lerdorf

20 years ago

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 this that
got around safe-mode.

> - open_basedir restriction plus disable
>   exec+passthru+proc_open+shell_exec+system+popen+pcntl_exec(+dl)?
> - jail users into hell?
> - or something third?

I have always maintained that shared hosts should be running
per-security context Apache instances as different users.  That's the
only way to truly keep things secure.  If you have everyone executing
things as the same user id you will never truly separate the security
contexts.  Failing that, shared hosts should be looking at per-user fastcgi.

-Rasmus

Andi Gutmans

20 years ago

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

20 years ago

Hi,

On Thu, 24 Nov 2005 16:23:05 -0800
Andi Gutmans <andi@zend.com> 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 think anybody disagrees about this. I'm just curious about
documenting some recommendations.

I believe the problem about safe_mode is the name and the "magic" it
applies. "enable_dl" enables or disables dl(). "upload_tmp_dir"
specifies the tmp dir. "open_basedir" sets basedir restriction. All
these settings are clear about their purposes and impact. But "safe_mode"
does... something not obviously clear.

If (and only if) the approach of disabling exec functions is recommended
one could have a setting for this. "disable_exec_functions" might be a
setting that is clear about its purpose and impact.

--
- Peter Brodersen

Daniel Convissor

20 years ago

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/features/safe-mode.xml, post the
patch on a website somewhere then open a documentation bug about it and
provide the link to the patch.

--Dan

--
T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

Peter Brodersen

20 years ago

Hi,

On Sat, 26 Nov 2005 11:57:45 -0500, in php.internals
danielc@analysisandsolutions.com (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 documentation bug about it and
>provide the link to the patch.

First of all, this is about PHP 6. There would be no reason for
changing the safe-mode page as safe-mode does not exist in PHP 6.

Second, there is a difference between features and recommendations.
Several features is documented even though they would not fit in a
"best practice" recommendation.

Third, there seem no consensus about such "best practice for shared
hosts". Some recommend open_basedir and disable_functions (or
safe_mode). Some recommend running php as different users. While there
might not be a need for just one recommendation I believe  "safe_mode
isn't safe so don't rely on it" only tells users what not to do
without providing any alternatives.

If there is a clarification I would like to write some documentation
aiming at PHP6. But before any consensus and possible new directives
it would be too early to put up some text.

--
- Peter Brodersen

Peter Brodersen

20 years ago

Hi,

On Thu, 24 Nov 2005 14:12:32 -0800
Rasmus Lerdorf <rasmus@lerdorf.com> 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 this that
> got around safe-mode.

This is not about safe_mode, but open_basedir - what is the purpose of
open_basedir restriction if it is easily circumvented using shell
commands?

> I have always maintained that shared hosts should be running
> per-security context Apache instances as different users.  That's the
> only way to truly keep things secure.  If you have everyone executing
> things as the same user id you will never truly separate the security
> contexts.  Failing that, shared hosts should be looking at per-user fastcgi.

Just to summarize: this approach would require that each user's scripts
would be non-world-readable and only readable by the owner. That way
users can't peak in other users' source code.

But again, what is the purpose of open_basedir() here?

Furthermore, I might want to keep some of the security by running the
php by some other user than the owner. Otherwise e.g. a poor
"file_put_contents()" script might overwrite existing scripts. Of course
it is a bad thing if scripts aren't secure, but at least one wouldn't
risk getting all existing files wiped or modified if the php user isn't
the same as the owner.

This "other user" should not be the same for all users. A method could
be creating individual wwwuser users for every user.

E.g. for the user "penguin" another user "penguin_www" could be created
and added to the "penguin" group. PHP files could be chmod'ed 640.
"penguin_www" would be able to read and run the script (as the files
have group read), but not being able to write/modify files or create new
files. Other users wouldn't be able to read the files belonging to
"penguin".

This might be out of scope for php, but as a recommended setup I think
it would be fair to provide hints for general setup.


(and once again, I agree that safe_mode is not safe, it is a poor
functionality as it suggests magic instead of easy understandable
features, it gives users headaches with UID matching)

--
- Peter Brodersen

Sara Golemon

20 years ago

> 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....

Peter Brodersen

20 years ago

Hi,

On Thu, 24 Nov 2005 15:55:10 -0800
"Sara Golemon" <pollita@php.net> 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 the problem. Would you regard this as "best practice"?

In that case we would actually just remove safe_mode and ask every
individual user to "remake" safe_mode behaviour by disabling the very
same functions, safe_mode would disable.

Furthermore, this behaviour would be vulnerable to new exec-functions
requiring a lot of maintenance for end users.

If this really is best practice, why don't we just rename safe_mode to
"disable_exec_functions" (and maybe remove UID checks)? It would be
easier to maintain and easier to deploy - provided that this really is
the recommended setup.

--
- Peter Brodersen

Christopher Kunz

20 years ago

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 directory.

Sorry for jumping in without reading the whole mammooth thread: Why not unbundle
safe_mode_exec_dir from safe_mode and keep it? That way, the obvious stuff gets
fixed (although you can still shoot yourself in the foot with stuff like convert
or whatever $CMS_OF_THE_DAY  might require to run smoothly).

Is that feasible?

Regards,

--ck

--
http://www.de-punkt.de   [ chris@de-punkt.de ]    http://www.stormix.de
PHP-Anwendungen sind gefährdet! SQL-Injection, XSS, Session-Angriffe,
CSRF, Commandshells, Response Splitting,... böhmische Dörfer? Dann gleich
"PHP-Sicherheit" direkt beim Verlag vorbestellen! http://www.php-sicherheit.de/

Rasmus Lerdorf

20 years ago

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 to their own directory.
>
> Sorry for jumping in without reading the whole mammooth thread: Why not unbundle
> safe_mode_exec_dir from safe_mode and keep it? That way, the obvious stuff gets
> fixed (although you can still shoot yourself in the foot with stuff like convert
> or whatever $CMS_OF_THE_DAY  might require to run smoothly).
>
> Is that feasible?

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 snapped onto
the end of safe_mode.

We're a little distracted by 5.1, but if you or someone else can keep
this in mind and remind us later, I would appreciate it.  Or come up
with a patch for HEAD we can look at.

-Rasmus

Lukas Smith

20 years ago

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 snapped onto
> the end of safe_mode.
>
> We're a little distracted by 5.1, but if you or someone else can keep
> this in mind and remind us later, I would appreciate it.  Or come up
> with a patch for HEAD we can look at.

I have noted it on the php 6.0 todo list on my wiki (still need to
update the stuff there ..)

regards,
Lukas

Peter Brodersen

20 years ago

On Fri, 25 Nov 2005 09:39:34 -0800, in php.internals
rasmus@lerdorf.com (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 snapped onto
>the end of safe_mode.

Nice - I like this solution much more than users should maintain their
own disabled_functions list.

Oh, and a rename of the directive would be much appreciated - at least
it'll kill the apparently unavoidable semantics discussion every time
"safe" is mentioned.

>We're a little distracted by 5.1, but if you or someone else can keep
>this in mind and remind us later, I would appreciate it.  Or come up
>with a patch for HEAD we can look at.

FWIW, I'll make some noise later :-)

I'm still not clear about the open_basedir issue though:
open_basedir seems useless if users have access to e.g. cat and ls
(or glob() :-)
The solution with users running scrips only readably by themselves and
php running as the user seems as a whole alternative to open_basedir.
Furthermore there is the security issue of the user running the script
also able to modify or create new files.

In summary:

== open_basedir+some_exec_dir_restriction ==
Source of vulnerability: shortcomings regarding third part modules or
new functions not added to list of exec functions.
Impact: possible read access for files and directories outside of
open_basedir.
Fix: centralized (the php core source, third party modules)

== PHP running as user, scripts non-readable by "other" ==
Source of vulnerability: bugs in php script
Impact: possible read and write access to all files owned by current
user
Fix: decentralized (the current php script)


I guess my main concern is that open_basedir is kept in PHP6 (based on
the talks), but it is pretty much useless if not backed up by other
tools (disable_exec_functions, some_exec_dir_restriction, ...)

--
- Peter Brodersen