ID:               38819
 User updated by:  madcoder at gmail dot com
 Reported By:      madcoder at gmail dot com
-Status:           Feedback
+Status:           Open
 Bug Type:         LDAP related
 Operating System: 2.6.15-gentoo linux amd64
 PHP Version:      5.1.6
 New Comment:

No, I'm sorry, it's on a private LAN.  A VPN account would be required
to gain access to the LAN, and corporate policy won't allow me to grant
you that.  If you would like to contact me off-bugzilla, I might be able
to arrange a different way of accessing the server.


Previous Comments:
------------------------------------------------------------------------

[2006-09-26 09:38:39] [EMAIL PROTECTED]

Is it possible to get an account @ this server?

------------------------------------------------------------------------

[2006-09-26 09:36:37] madcoder at gmail dot com

Sorry for the extra post...  I just tested with different values in
ldap_connect.  For all values of the hostname parameter that I tried,
any that were *NOT* prefixed with "ldap://"; caused a segmentation fault
at line 2:
  ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);

The various values I tried, all of which resulted in a segfault, were:
hostname (xyzdc01 and xyzdc02)
IP (172.16.0.50 and 172.16.0.51)
FQHN (xyzdc01.xyz.acs-inc.com and xyzdc02.xyz.acs-inc.com)

All of the above, when prefixed with ldap://, resulted in the same
segfault described initially, at ldap_get_entries().

------------------------------------------------------------------------

[2006-09-26 09:29:47] madcoder at gmail dot com

My apologies for misunderstanding...

To reproduce the problem on my system:

1) I connect to the ldap server, which happens to be a Microsoft Active
Directory domain controller, using:
  $_SERVER['ldap'] = ldap_connect("ldap://xyzdc02.xyz.acs-inc.com";) or
die("ldap connect failed");

2) Set MSAD-required options:
  ldap_set_option($_SERVER['ldap'], LDAP_OPT_PROTOCOL_VERSION, 3);
  ldap_set_option($_SERVER['ldap'], LDAP_OPT_REFERRALS, 0);

3) Bind to the LDAP directory with a search user configured with read
access to the directory:
  ldap_bind($_SERVER['ldap'], '[EMAIL PROTECTED]', 'some.Pass')
or die('ldap bind failed');

4) Perform a basic search, looking for my User object:
  $result = ldap_search($_SERVER['ldap'], 'dc=xyz,dc=acs-inc,dc=com',
'(sAMAccountName=jhansche)',
array('samaccountname','telephonenumber'));

(print a couple of debug messages):
  echo "done searching\n";
  echo "Count: " . ldap_count_entries($_SERVER['ldap'],$result) . "
entries\n";

5) Attempt to fetch the results of the search above:
  $info = ldap_get_entries($_SERVER['ldap'], $result);
*** This was the last line to execute before the segfault ***

(print more debugging messages):
  echo "Done fetching\n";
  print_r($info);

==============
I then test the script with this command line (ruling out apache as any
part of the problem), and receive these results to stdout/err:
  # php -e test.php
  done searching
  Count: 1 entries
  Segmentation fault
==============
As a result of that process, running via gdb, I get the backtrace,
which I have posted previously.
==============
Running via valgrind, filtering out the valgrind output, the script
*runs fine*, and produces the following output:

  # valgrind php -e test.php 2>/dev/null
  done searching
  Count: 1 entries
  Done fetching
  Array
  (
    [Full output of the array returned by ldap_get_entries() is
displayed here correctly, but snipped out for brevity's sake]
  )
  # (end of output)

==============
The LDAP server is running Windows Server 2003 SP1.  The segmentation
fault occurs when trying to connect to either of the two domain
controllers on the network.  The segfault also occurs if I leave off
the LDAP_OPT_REFERRALS = 0 option, and perform a single-level search
directly on the Organizational Unit containing my user account.
==============
/etc/openldap/ldap.conf:
BASE    dc=xyz,dc=acs-inc,dc=com
URI     ldap://xyz.acs-inc.com
TLS_REQCERT never
TLS_CACERT /etc/ssl/certs/xyzdc02.pem
TLS_CACERTDIR /etc/ssl/certs
(note that I am not calling ldap_start_tls() in this test, so the TLS_*
lines are not used)

==============
Performing the same query via the command-line 'ldapsearch' utility
from OpenLDAP:
 $ ldapsearch -H ldap://xyz.acs-inc.com -D [EMAIL PROTECTED] -w
some.Pass "(samaccountname=jhansche)" telephonenumber
  # LDAPv3
  # base <> with scope subtree
  # filter: (samaccountname=jhansche)
  # requesting: telephonenumber

  # Joe Hansche, Administrators, elp.acs-inc.com
  dn: CN=Joe Hansche,OU=Administrators,DC=xyz,DC=acs-inc,DC=com
  telephoneNumber: 5492
==============

Unfortunately, I don't have another non-MS ldap server to try.  It
appears that the search is completed successfully, because the
ldap_count_entries() call returns 1, which is correct.  It just
segfaults when trying to retrieve the actual entries with
ldap_get_entries().  I hope that is more informative.  If not, please
let me know what additional information I can give you that might help
track this problem down.  If you'd like I can try adding some debugging
messages into the ldap portion of the php source to see where it might
be failing, and why?

Thanks, by the way.  I appreciate your efforts.

------------------------------------------------------------------------

[2006-09-26 07:07:20] [EMAIL PROTECTED]

I intentionally said "how to reproduce it", not "what is the reproduce
code". It's clear to me that you're still using the same code, but this
code doesn't make much sense to me since I don't have your data, your
variables etc.
Hence the question - how to reproduce it?

------------------------------------------------------------------------

[2006-09-25 23:20:32] madcoder at gmail dot com

It's pretty much the same as before...

(gdb) bt
#0  0x00002aae16a8de44 in ldap_count_values (vals=0x559cadc0)
    at getvalues.c:153
#1  0x00005555555db423 in zif_ldap_get_entries (ht=1436331456,
    return_value=0x5555559ca5c0, return_value_ptr=0x0, this_ptr=0x0,
    return_value_used=1435796224)
    at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/ext/ldap/ldap.c:1068
#2  0x00005555556e4d20 in zend_do_fcall_common_helper_SPEC (
    execute_data=0x7fff942851d0) at zend_vm_execute.h:200
#3  0x00005555556ed112 in ZEND_DO_FCALL_SPEC_CONST_HANDLER (
    execute_data=0x7fff942851d0) at zend_vm_execute.h:1640
#4  0x00005555556e43f9 in execute (op_array=0x5555559c7ae0)
    at zend_vm_execute.h:92
#5  0x00005555556bf1d8 in zend_execute_scripts (type=8, retval=0x0,
    file_count=3)
    at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/Zend/zend.c:1109
#6  0x0000555555670784 in php_execute_script
(primary_file=0x7fff94287790)
    at /var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/main/main.c:1737
#7  0x00005555557756f4 in main (argc=3, argv=0x7fff942879c8)
    at
/var/tmp/portage/php-5.1.6-r4/work/php-5.1.6/sapi/cli/php_cli.c:1093

The ldap code to reproduce the problem is the same as at the beginning
of this report...  The difference between the code I posted originally
and the code that gave me the above output (showing "Count: 1"), is
this:

echo "done searching\n";
echo "Count: " . ldap_count_entries($_SERVER['ldap'],$r) . "
entries\n";
$info = ldap_get_entries($_SERVER['ldap'], $r);

(that is, I added the Count line *after* the original post;  everything
else is the same)

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/38819

-- 
Edit this bug report at http://bugs.php.net/?id=38819&edit=1

Reply via email to