Re: [PHP-DEV] LDAP controls in response

[Jani Taskinen]

On Wed, 9 Nov 2005, Pierangelo Masarati wrote:



On Wed, 2005-11-09 at 07:05 +0200, Jani Taskinen wrote:

 The "control-patch" looks okay. But the "warning-fix-patch" really doesn't.
 You're actually changing some functions behaviour with some of those
 changes. Maybe you didn't notice but there's ldap_get_values() and
 ldap_get_values_len() separately. And there's ldap_bind() and 
ldap_sasl_bind(),


What I'm doing is driven by the fact that the ldap_*value*() family, and
the ldap_bind*() are being deprecated (that is: they're in the library,
but they're not declared in ldap.h any more, and they are implemented as
wrappers to the replacements I'm using, at the cost of extra execution
time and resources, plus decent compiler warnings).


Perhaps with OpenLDAP, but what about the other implementations with
which this extension works just fine? You didn't wrap all those changes
inside the #ifdef's.


ldap_*value*_len() is the safe implementation of ldap_*value*(), because
it can also handle non-null terminated values; this doesn't inhibit the
handling null-terminated ones.  Moreover, PHP needs the length of the
string anyway, so...  Note that this would allow PHP to use only
ldap_get_values() for both, making the API more simple and robust (I
vaguely recall the issue that brought to implementing
ldap_get_values_len() in PHP, I think it was somewhere in PHP 3 and the
patch took a while to get there).


I agree it's better this way, but (even as unlikely it is) changing this
MIGHT break someone's script.

Anyway, it might be the time to cleanup the API of this extension
and make it simpler. It's pretty confusing as it is.
The returned arrays are also weird with their "count" fields and such.


Anyway, none of these is an issue to me, so I'm fine with the controls
patch.  A final comment: apart from some fuzziness complaints, both
patches apply also to PHP 4 without changes.  This means we can get into
production immediately (well, after some testing... :)


This is a new feature and new features are no longer added in PHP 4.
We only add new stuff in PHP >= 5.1.

--Jani

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

Re: [PHP-DEV] LDAP controls in response

[Pierangelo Masarati]

> On Wed, 9 Nov 2005, Pierangelo Masarati wrote:
>
>>
>> On Wed, 2005-11-09 at 07:05 +0200, Jani Taskinen wrote:
>>>  The "control-patch" looks okay. But the "warning-fix-patch" really
>>> doesn't.
>>>  You're actually changing some functions behaviour with some of
>>> those
>>>  changes. Maybe you didn't notice but there's ldap_get_values() and
>>>  ldap_get_values_len() separately. And there's ldap_bind() and
>>> ldap_sasl_bind(),
>>
>> What I'm doing is driven by the fact that the ldap_*value*() family, and
>> the ldap_bind*() are being deprecated (that is: they're in the library,
>> but they're not declared in ldap.h any more, and they are implemented as
>> wrappers to the replacements I'm using, at the cost of extra execution
>> time and resources, plus decent compiler warnings).
>
>  Perhaps with OpenLDAP, but what about the other implementations with
>  which this extension works just fine? You didn't wrap all those
> changes
>  inside the #ifdef's.

Right, sorry.  And note that this is true only for OpenLDAP 2.3 (which is
considered stable by the OpenLDAP project but maybe not by distributors
yet...).  I'm pretty confident the reworking I put in place is conformant
with most APIs, but, as I said, I likely have no chance to test it
shortly, so I wouldn't stress too much on it.

>
>> ldap_*value*_len() is the safe implementation of ldap_*value*(), because
>> it can also handle non-null terminated values; this doesn't inhibit the
>> handling null-terminated ones.  Moreover, PHP needs the length of the
>> string anyway, so...  Note that this would allow PHP to use only
>> ldap_get_values() for both, making the API more simple and robust (I
>> vaguely recall the issue that brought to implementing
>> ldap_get_values_len() in PHP, I think it was somewhere in PHP 3 and the
>> patch took a while to get there).
>
>  I agree it's better this way, but (even as unlikely it is) changing
> this
>  MIGHT break someone's script.

Well, GIGO :)  If one uses ldap_get_values_len() with strings (i.e.
null-terminated arrays) the result is fine and consistent; the BER
contains the info about the value length so there's not even the
performance penalty of a strlen().  If one was relying on using
ldap_get_values() for non-null terminated strings ...

>
>  Anyway, it might be the time to cleanup the API of this extension
>  and make it simpler. It's pretty confusing as it is.

>  The returned arrays are also weird with their "count" fields and
> such.

I added them for consistency with the rest of the data returned by PHP's
ldap_get_{entries,attributes,values}(); I'm fine if they get removed, we
also save the counter...

Should I do the cleanup?  Should I simply remove the "warning" stuff and
the "count" stuff in the arrays?

>
>> Anyway, none of these is an issue to me, so I'm fine with the controls
>> patch.  A final comment: apart from some fuzziness complaints, both
>> patches apply also to PHP 4 without changes.  This means we can get into
>> production immediately (well, after some testing... :)
>
>  This is a new feature and new features are no longer added in PHP 4.
>  We only add new stuff in PHP >= 5.1.

I was speaking for our own packages; usually I don't expect anything to be
backported so far, it's fair enough to see contributed features in the
mainstream at some point.

Thanks for your time.  p.

-- 
Pierangelo Masarati
mailto:[EMAIL PROTECTED]





Ing. Pierangelo Masarati

Responsabile Open Solution



SysNet s.n.c.

Via Dossi, 8 - 27100 Pavia - ITALIA

http://www.sys-net.it

--

Office:   +39.02.23998309  

Mobile:   +39.333.4963172

Email:[EMAIL PROTECTED]

--


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

Re: [PHP-DEV] when will support for php 4 last?

[Mikael Fern]

hello jani,
thanks for the info. yeah, the feature requests shouldn't be considered bugs
but it's just what is in the mail.. :)

also, outside of lxr.php.net , is there any place that
stores more readable documentation about the code?

regards,

On 11/9/05, Jani Taskinen <[EMAIL PROTECTED]> wrote:
>
> On Wed, 9 Nov 2005, Mikael Fern wrote:
>
> > i notice there are 637 open bugs for php 4 (from the last mail i got)
> > including feature requests. there are also hundreds of open bugs for php
> 5.
>
> Actually there are 28 open bugs marked only for PHP 4.
> There are 106 open bugs marked for PHP 5, of which about 80% are also
> found in PHP 4. So really, count of open bugs for PHP 4 is about 100.
>
> Feature/change requests are not bugs.
>
> > since the php 6 is on the way to go, i want to ask about the support for
> php
> > 4, the time it will be officially be in history.
>
> If you would ask only me, the support has already ended.
> If bug is only found in PHP 4, I don't care. But that's just me.
>
> Derick will propably support PHP 4 until PHP 6 is out. :)
>
> > is there any plan after 4.4 branch releases? or maybe this is the last
> > branch for php 4?
>
> AFAICT, 4.4 will be the last of PHP 4 branches. There will be no new
> features in PHP 4. Most of the active developers concentrate on PHP 5
> and/or 6.
>
> --Jani
>
>


--


--

[PHP-DEV] Correct use of zend_list_delete

[Marco Bambini]

Maybe this is a question too simple for this list, but I am writing  
my first php extension (using php 4.4 SDK) so please, be patient...
My extension (rsql) returns a custom struct to php so my code in my  
rsql_connect looks like:


ZEND_FUNCTION(rsql_connect)
{

RETURN_RESOURCE(zend_list_insert(rsqldb, rsql_connection));
}

The relevant code is:

ZEND_FUNCTION(rsql_disconnect)
{
...
	ZEND_FETCH_RESOURCE2(rsqldb, void*, theConnectionParameter, -1,  
kConnIDString, rsql_connection, rsql_pconnection);

if (rsqldb) zend_list_delete(Z_LVAL_PP(theConnectionParameter));
if (rsqldb) myCustomFree(rsqldb);
}

static void rsql_realconnectionclose(zend_rsrc_list_entry *rsrc)
{
void *rsqldb;
if (rsrc != NULL)
{
rsqldb = rsrc->ptr;
if (rsqldb != NULL)
{
rsqlserver_disconnect(rsqldb, kTRUE);
rsqldb = NULL;

if (persistent == kTRUE)
RSQL_G(num_persistent)--;
}
}
}


PHP_MINIT_FUNCTION(rsql)
{
	rsql_connection = zend_register_list_destructors_ex 
(rsql_realconnectionclose, NULL, kConnIDString, module_number);

}

What is the issue I encounter with this code?
This php code crashes:

for ($i=0; $i<10; $i++){

$dbconn = rsql_connect("127.0.0.1","admin","admin");
if (is_resource($dbconn) == 0){
print "Connection to database server failed.";
exit();
}

rsql_disconnect($dbconn);

}

and also this one:

for ($i=0; $i<10; $i++){

$dbconn = rsql_connect("127.0.0.1","admin","admin");
if (is_resource($dbconn) == 0){
print "Connection to database server failed.";
exit();
}

}

What I think is that when rsql_disconnect is called explicitly or by  
the destructor (rsql_realconnectionclose) my custom struct isn't  
really deleted from the zend_list.


I really appreciate any help for my issue...

Thanks a lot,
Marco Bambini

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

[PHP-DEV] Lack of read permission on main script leads to E_WARNING

[Ryan Dingman]

I believe that I've found a bug in the way that PHP handles  
permission problems when accessing the main script.


If I access http://localhost/foo.php and PHP does not have permission  
to read foo.php, I get an E_WARNING rather than an E_COMPILE_ERROR  
(include vs. require).  This is in PHP 5.1 RC4.  I've fixed this in a  
local build by patching zend_execute_scripts in Zend/zend.c on line  
1079. zend_execute_scripts was calling zend_compile_file and passing  
ZEND_INCLUDE in as the type argument rather than passing along its  
type argument.  The old code reads:


EG(active_op_array) = zend_compile_file(file_handle, ZEND_INCLUDE  
TSRMLS_CC);


My patched version reads:

EG(active_op_array) = zend_compile_file(file_handle, type TSRMLS_CC);

Because I'm not intimately familiar with the inner workings of the  
interpreter, I'm not sure that this is the best way to fix this  
problem, but it seems like the most appropriate place that I could find.


In case you are wondering why I care -- we have a PHP module that  
monitors PHP errors and redirects our customers to a customer service  
page any time that PHP encounters anything that the interpreter  
really shouldn't recover from (E_CORE_ERROR, E_ERROR, E_PARSE,  
E_COMPILE_ERROR and E_USER_ERROR).  The main script not being  
readable is certainly a case where we would like to redirect them to  
a customer service page.  However, having an E_WARNING as the error  
makes it difficult to identify this situation because we would now  
have to distinguish between this E_WARNING and any others that might  
arise in the site.  Having an E_COMPILE_ERROR would be much more  
definitive and more correct IMHO.  Yes, we are taking other steps to  
ensure that the permission on the PHP scripts for our site are  
correct, but mistakes do happen and we want to guarantee that our  
customers have as good an experience as possible in the case of  
unexpected errors (as any enterprise site should).


Thoughts?

Thanks,

Ryan Dingman
[EMAIL PROTECTED]
Next Online Mortgage Technologies

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

Re: [PHP-DEV] object-overloading: why not allow recursive calls? (5.1) hey, in zend_object_handlers.c function zend_std_read_property we protect against calling the __get function of an object if we

[Andi Gutmans]

This is intentional and I think it makes it much more fool-proof for 
developers. Adding recursion protection can be very expensive and 
complicated, and it doesn't seem to make sense here. The idea is that 
once you're in the __get() method, you know exactly how your 
properties are mapped and can do the right thing. It's only this one 
method where you have your mapping anyway, not an entirely different place.


Andi

At 12:35 AM 11/4/2005, Thies C. Arntzen wrote:

hey,

in zend_object_handlers.c function zend_std_read_property we protect
against calling the __get function of an object if we're already in a
__get() function. (look for zobj->in_get) in that function.

i don't think we should be doing this.

simplyfied example:
name);
}
}
}

$a = new test;
var_dump($a->length);
?>

outputs:
__get(length)
int(0)

but should say:
__get(length)
__get(name)
int(4)

i think recursive gets are highly useful and should be allowed. if we
really want to protect against recursion (here) we have two real
options: -a- protect against __get(ing) the same property more than
once in the same call-chain (mucho work), or -b- (preferred) have
some global infinite recursion protection in the engine (needs to be
done somewhen anyhow, but not now).

so, in one sentence: as we don't protect against recustion elsewhere,
can we please remove this unneded roadblock?

opinions?
-thies

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


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

Re: [PHP-DEV] object-overloading: why not allow recursive calls? (5.1) hey, in zend_object_handlers.c function zend_std_read_property we protect against calling the __get function of an object if we

[Andi Gutmans]

Thies,

I think I might be wrong in my analysis. Seems like the problem is 
worse than what I thought as it seems to cross boundaries between classes.

We'll look into it more.

Andi

At 02:15 PM 11/9/2005, Andi Gutmans wrote:
This is intentional and I think it makes it much more fool-proof for 
developers. Adding recursion protection can be very expensive and 
complicated, and it doesn't seem to make sense here. The idea is 
that once you're in the __get() method, you know exactly how your 
properties are mapped and can do the right thing. It's only this one 
method where you have your mapping anyway, not an entirely different place.


Andi

At 12:35 AM 11/4/2005, Thies C. Arntzen wrote:

hey,

in zend_object_handlers.c function zend_std_read_property we protect
against calling the __get function of an object if we're already in a
__get() function. (look for zobj->in_get) in that function.

i don't think we should be doing this.

simplyfied example:
name);
}
}
}

$a = new test;
var_dump($a->length);
?>

outputs:
__get(length)
int(0)

but should say:
__get(length)
__get(name)
int(4)

i think recursive gets are highly useful and should be allowed. if we
really want to protect against recursion (here) we have two real
options: -a- protect against __get(ing) the same property more than
once in the same call-chain (mucho work), or -b- (preferred) have
some global infinite recursion protection in the engine (needs to be
done somewhen anyhow, but not now).

so, in one sentence: as we don't protect against recustion elsewhere,
can we please remove this unneded roadblock?

opinions?
-thies

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


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


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

Re: [PHP-DEV] object-overloading: why not allow recursive calls? (5.1) hey, in zend_object_handlers.c function zend_std_read_property we protect against calling the __get function of an object if

[Mike Naberezny]

The problem does not cross class boundaries.  However, here are some 
test cases to better illustrate the question:


hello1;
case 'hello3':
return $this->__get('hello1');
case 'hello4':
return $this->testFunction();
}
}

function testFunction() {
return $this->hello1;
}
}


$t = new Test();

// CASE 1: Code from outside class scope gets an undefined property
// which is proxied by __get().  This is the everyday usage.
// string(5) "there"
var_dump($t->hello1);

// CASE 2: Code inside __get() gets an undefined property,
// which generates a notice instead of being proxied by __get().
// NULL
var_dump($t->hello2);

// CASE 3: Code inside __get() calls __get()
// string(5) "there"
var_dump($t->hello3);

// CASE 4: Code inside __get gets an undefined property through a
// function, which generates a notice just like Case 2.
// NULL
var_dump($t->hello4);

// CASE 5: Code from inside a class function gets an undefined
// property which is proxied by __get()
// string(5) "there"
var_dump($t->testFunction());
?>

I agree with Thies that this should be changed, on the basis that the 
behavior is inconsistent and we don't protect against recursion 
otherwise.  Every test case should return the string.


The above examples were tested against 5.0.5 and the latest 5.1 with the 
same results.


Mike


Andi Gutmans wrote:

Thies,

I think I might be wrong in my analysis. Seems like the problem is worse 
than what I thought as it seems to cross boundaries between classes.

We'll look into it more.

Andi

At 02:15 PM 11/9/2005, Andi Gutmans wrote:

This is intentional and I think it makes it much more fool-proof for 
developers. Adding recursion protection can be very expensive and 
complicated, and it doesn't seem to make sense here. The idea is that 
once you're in the __get() method, you know exactly how your 
properties are mapped and can do the right thing. It's only this one 
method where you have your mapping anyway, not an entirely different 
place.


Andi

At 12:35 AM 11/4/2005, Thies C. Arntzen wrote:


hey,

in zend_object_handlers.c function zend_std_read_property we protect
against calling the __get function of an object if we're already in a
__get() function. (look for zobj->in_get) in that function.

i don't think we should be doing this.

simplyfied example:
name);
}
}
}

$a = new test;
var_dump($a->length);
?>

outputs:
__get(length)
int(0)

but should say:
__get(length)
__get(name)
int(4)

i think recursive gets are highly useful and should be allowed. if we
really want to protect against recursion (here) we have two real
options: -a- protect against __get(ing) the same property more than
once in the same call-chain (mucho work), or -b- (preferred) have
some global infinite recursion protection in the engine (needs to be
done somewhen anyhow, but not now).

so, in one sentence: as we don't protect against recustion elsewhere,
can we please remove this unneded roadblock?

opinions?
-thies

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



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





--
Mike Naberezny
Senior PHP Developer

Zend Technologies, The PHP Company
19200 Stevens Creek Blvd, Suite 100
Cupertino, CA 95014
Tel: 408-342-8891
Fax: 408-253-8801
[EMAIL PROTECTED]

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

[PHP-DEV] Good memory management

[Bob Silva]

Hi,

 

Got a question on proper memory management within the engine.

 

I have an object that stores an Array (IS_ARRAY) as a property. Inside this
property array are other objects.

 

So heres my memory layout for an initialized object:

 

Object

Property => Array (refcount = 1)

Array[0] = Object (refcount=1 if created inside Object constructor)

Array[1] = Object (refcount= >1 if passed into Object from userland)

 

I have a set handler so that I can set the internal array value with an
assignment.

 

$Object = array(1, 'string');

 

Results in:

Object

Property => Array (refcount = 1)

Array[0] = Object (represents an the integer 0 in this case)

Array[1] = Object (represents the string "string")

 

My question is, inside my set handler, I simply call zend_update_property,
during which refcount on the old Array property gets decremented to 0 and
has zval_dtor called on it.

Now the objects that were inside that array are dangling.

 

So here is the question. 

 

Do I just rely on the engine itself to destroy the dangling objects in the
first array at the end of the script (which works),

or do I destruct the objects myself before replacing the property (Array)
with the new one?

 

Depending on the answer, what is the process to destruct an object? Just
ZVAL_DEL_REF it and let the engine GC do the rest?

 

Thanks

 

Bob Silva

[PHP-DEV] Known Security Risks in PHP

[R, Rajesh (STSD)]

Hello there,

Is there a specific web resource for known 
SSRT's(Security risks) in PHP ??

Any pointers would be helpful.


Thanks,
Rajesh R

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

Re: [PHP-DEV] Known Security Risks in PHP

[Kamesh Jayachandran]

Hi,

Stefan's http://www.hardened-php.net/advisories.15.html might be what
you look at.

With regards
Kamesh Jayachandran
On Thu, 10 Nov 2005 10:02:55 +0530, "R, Rajesh (STSD)"
<[EMAIL PROTECTED]> said:
> 
> Hello there,
> 
> Is there a specific web resource for known 
> SSRT's(Security risks) in PHP ??
> 
> Any pointers would be helpful.
> 
> 
> Thanks,
> Rajesh R
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
http://www.fastmail.fm - mmm... Fastmail...

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