PHP :: Bug #8155 :: PHP segmentation faults when using ldap

Bug #8155	PHP segmentation faults when using ldap_add
Submitted:	2000-12-07 06:24 UTC	Modified:	2000-12-08 11:09 UTC
From:	Philip dot Naylor at uwe dot ac dot uk	Assigned:
Status:	Closed	Package:	LDAP related
PHP Version:	4.0.3pl1	OS:	Solaris 7
Private report:	No	CVE-ID:	None

View Developer Edit

Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.

php.net Username: php.net Password:

Quick Fix:	(description)
	Block user comment
Status:		Assign to:
Package:
Bug Type:
Summary:
From:	Philip dot Naylor at uwe dot ac dot uk
New email:
PHP Version:		OS:

New/Additional Comment:

[2000-12-07 06:24 UTC] Philip dot Naylor at uwe dot ac dot uk

The following script causes the PHP process to segmentation fault (11), or
bus error (10) when the ldap_add function is called.

<?php
// the address of the LDAP server.
  $ldapServer="ns0.csm.uwe.ac.uk";
// the distinguished name of the directory.
  $ldapDirectory="dc=contacts, dc=csm, dc=uwe, dc=ac, dc=uk";
// required values in any entry.
  $newEntry["objectclass"][0]="top";
  $newEntry["objectclass"][1]="person";
  $newEntry["objectclass"][2]="organizationalPerson";
  $newEntry["objectclass"][3]="inetOrgPerson";
  $uid="testing";
  $newEntry["uid"]=$uid;
// connect to the LDAP server.
  $directoryService=ldap_connect($ldapServer);
// construct entry.
  $newEntry["sn"]="Naylor";
  $newEntry["givenname"]="Philip";
  $newEntry["cn"]="Philip Naylor";
  $newEntry["initials"]="PJ";
  $newEntry["title"]="Unix Systems Manager";
  $newEntry["o"]="Univ. West of England";
  $newEntry["ou"]="CSM";
  $newEntry["postaladdress"]="here";
  $newEntry["postalcode"]="BS16 1QY";
  $newEntry["l"]="Frenchay, Bristol";
  $newEntry["telephonenumber"]="0117 344 3348";
  $newEntry["facsimiletelephonenumber"]="0117 344 3155";
  $newEntry["mail"]="Philip.Naylor@uwe.ac.uk";
  $newEntry["labeleduri"]="http://www.csm.uwe.ac.uk/~pjnaylor/";
// create the distinguished name.
  $dn="uid=".$uid.", ".$ldapDirectory;
// bind to the LDAP server as the manager (allowed to do updates).
  $ldapLogin=ldap_bind($directoryService,"cn=Manager, ".$ldapDirectory,"Ch0ck5");
// add the new entry.
  $ldapAdd=ldap_add($directoryService,$dn,$newEntry);
// close the connection to the LDAP server.
  ldap_unbind($directoryService);
  ldap_close($directoryService);
// that's all folks !
?>

We are using PHP 4.0.3pl1 as a DSO in Apache 1.3.14, both the client and server
LDAP functionality is provided by OpenLDAP 2.0.6 with a db 3.1.17 back end.

The configuration options for the PHP build were :

--prefix=/opt2 --enable-force-cgi-redirect --enable-discard-path 
--with-ldap=/pub_domain --with-mysql=no --enable-debug

I have not succeeded in producing any sort of backtrace, or core dump for the fault.
However, running slapd with -d 255 gives :

daemon: new connection on 8
daemon: added 8r
daemon: activity on:
daemon: select: listen=6 active_threads=0 tvp=NULL
daemon: activity on 1 descriptors
daemon: activity on: 8r
daemon: read activity on 8
connection_get(8)
connection_get(8): got connid=0
connection_read(8): checking for input on id=0
ber_get_next 
sockbuf_read: want=1, got=1
  0000:  30                                                 0                 
sockbuf_read: want=1, got=1
  0000:  47                                                 G                 
sockbuf_read: want=71, got=71
  0000:  02 01 01 60 42 02 01 02  04 35 63 6e 3d 4d 61 6e   ...`B....5cn=Man  
  0010:  61 67 65 72 2c 20 64 63  3d 63 6f 6e 74 61 63 74   ager, dc=contact  
  0020:  73 2c 20 64 63 3d 63 73  6d 2c 20 64 63 3d 75 77   s, dc=csm, dc=uw  
  0030:  65 2c 20 64 63 3d 61 63  2c 20 64 63 3d 75 6b 80   e, dc=ac, dc=uk.  
  0040:  06 43 68 30 63 6b 35                               .Ch0ck5           
ber_get_next: tag 0x30 len 71 contents:
ber_dump: buf=0x000f1bc0 ptr=0x000f1bc0 end=0x000f1c07 len=71
  0000:  02 01 01 60 42 02 01 02  04 35 63 6e 3d 4d 61 6e   ...`B....5cn=Man  
  0010:  61 67 65 72 2c 20 64 63  3d 63 6f 6e 74 61 63 74   ager, dc=contact  
  0020:  73 2c 20 64 63 3d 63 73  6d 2c 20 64 63 3d 75 77   s, dc=csm, dc=uw  
  0030:  65 2c 20 64 63 3d 61 63  2c 20 64 63 3d 75 6b 80   e, dc=ac, dc=uk.  
  0040:  06 43 68 30 63 6b 35                               .Ch0ck5           
ber_get_next 
sockbuf_read: want=1 error=Resource temporarily unavailable
ber_get_next on fd 8 failed errno=11 (Resource temporarily unavailable)
do_bind      
ber_scanf fmt ({iat) ber:
ber_dump: buf=0x000f1bc0 ptr=0x000f1bc3 end=0x000f1c07 len=68
  0000:  60 42 02 01 02 04 35 63  6e 3d 4d 61 6e 61 67 65   `B....5cn=Manage  
  0010:  72 2c 20 64 63 3d 63 6f  6e 74 61 63 74 73 2c 20   r, dc=contacts,   
  0020:  64 63 3d 63 73 6d 2c 20  64 63 3d 75 77 65 2c 20   dc=csm, dc=uwe,   
  0030:  64 63 3d 61 63 2c 20 64  63 3d 75 6b 80 06 43 68   dc=ac, dc=uk..Ch  
  0040:  30 63 6b 35                                        0ck5              
ber_scanf fmt (o}) ber:
ber_dump: buf=0x000f1bc0 ptr=0x000f1bff end=0x000f1c07 len=8
  0000:  80 06 43 68 30 63 6b 35                            ..Ch0ck5          
do_bind: version=2 dn="cn=Manager, dc=contacts, dc=csm, dc=uwe, dc=ac, dc=uk" method=128     
==> ldbm_back_bind: dn: cn=Manager, dc=contacts, dc=csm, dc=uwe, dc=ac, dc=uk
dn2entry_r: dn: "CN=MANAGER,DC=CONTACTS,DC=CSM,DC=UWE,DC=AC,DC=UK"
=> dn2id( "CN=MANAGER,DC=CONTACTS,DC=CSM,DC=UWE,DC=AC,DC=UK" )
=> ldbm_cache_open( "/var/yp/ldap/var/openldap-ldbm/contacts/dn2id.dbb", 7, 600 )            
ldbm_cache_open (blksize 8192) (maxids 2046) (maxindirect 5)
<= ldbm_cache_open (opened 0)
<= dn2id 2   
=> id2entry_r( 2 )
=> ldbm_cache_open( "/var/yp/ldap/var/openldap-ldbm/contacts/id2entry.dbb", 7, 600 )         
ldbm_cache_open (blksize 8192) (maxids 2046) (maxindirect 5)
<= ldbm_cache_open (opened 1)
=> str2entry 
<= str2entry(cn=Manager, dc=contacts, dc=csm, dc=uwe, dc=ac, dc=uk) -> -1 (0x106ea0)         
entry_rdwr_rlock: ID: 2
<= id2entry_r( 2 ) 0x106ea0 (disk)
entry_rdwr_runlock: ID: 2
====> cache_return_entry_r( 2 ): created (0)
do_bind: v2 bind: "cn=Manager, dc=contacts, dc=csm, dc=uwe, dc=ac, dc=uk" to "cn=Manager, dc=contacts, dc=csm, dc=uwe, dc=ac, dc=uk"
send_ldap_result: conn=0 op=0 p=2
send_ldap_result: 0::
send_ldap_response: msgid=1 tag=97 err=0
ber_flush: 14 bytes to sd 8
  0000:  30 0c 02 01 01 61 07 0a  01 00 04 00 04 00         0....a........    
sockbuf_write: want=14, written=14
  0000:  30 0c 02 01 01 61 07 0a  01 00 04 00 04 00         0....a........    
daemon: select: listen=6 active_threads=1 tvp=NULL
daemon: activity on 1 descriptors
daemon: activity on: 8r
daemon: read activity on 8
connection_get(8)
connection_get(8): got connid=0
connection_read(8): checking for input on id=0
ber_get_next 
sockbuf_read: want=1, got=0
             
ber_get_next on fd 8 failed errno=0 (Error 0)
connection_read(8): input error=-2 id=0, closing.
connection_closing: readying conn=0 sd=8 for close
connection_close: conn=0 sd=8
daemon: removing 8

It would appear that the LDAP server is dropping the connection because
it has not received the data that it is expecting, and the client end is failing 
to deal with this in a graceful manner.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports

[2000-12-07 09:51 UTC] Philip dot Naylor at uwe dot ac dot uk

I've just tried rewriting the script so that it creates an LDIF file, and then exec's
the OpenLDAP   ldapadd  command, instead of using the  ldap_add  built-in 
function.

This also fails, with the same sort of debug trace from slapd, even though it
works fine from the command line, with the same LDIF file, uid, and environment,
as the user that the web server runs as.

??

[2000-12-07 18:55 UTC] sniper@php.net

Could you please try the latest snapshot from http://snaps.php.net/  ??
I haven't got anything like this before.  (I do use openldap 2.0.7, though)

Have you tried it with some older version of slapd? Like 1.2.11 ?

--Jani

[2000-12-08 10:32 UTC] Philip dot Naylor at uwe dot ac dot uk

Upgrading to   php4-200012080045  has fixed the problem with  ldap_add
(something's still failing using an LDIF file and exec'ing an external command, but
that doesn't matter now).

Am I going to be reasonably safe using this verion in a production system, with
the Oracle 8, GD, and IMAP modules, as well as LDAP ?

Cheers,

Philip.

[2000-12-08 11:09 UTC] sniper@php.net

Fixed -> closed.

You can wait for PHP 4.0.4 to be released
but using that snapshot should be reasonably safe. 
I don't think there will be any more fixes in LDAP before
the release. 

--Jani

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2025 The PHP Group All rights reserved.	Last updated: Tue Nov 04 08:00:01 2025 UTC