- openldap-bugs - openldap.org

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by guenther+ldapdev＠sendmail.com 15 Aug '08

15 Aug '08

On Thu, 14 Aug 2008, Michael Ströder wrote: > Philip Guenther wrote: ... > > They also have the "SSLProtocol" directive, further down on that page. > > Then I'd vote for doing it exactly like this with one option (space- or > comma-separated list of protocols). As I mentioned in the ITS, I think treating the various protocol versions as independently choosable is a Bad Thing, as it permits broken settings with no corresponding gain. That said, it's more important to me that *some* option gets in so that I (and Sendmail) don't have to maintain forever a patch to add it. If someone 'official' will make a decision and simply state what the option should look like in its three forms (C API, ldap.conf, slapd config), I'll munge the patch to match. Philip Guenther

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ghenry＠OpenLDAP.org 15 Aug '08

15 Aug '08

----- "ali pouya" <ali.pouya(a)free.fr> wrote: > Gavin Henry <ghenry(a)suretecsystems.com> wrote : > > > ali.pouya(a)free.fr wrote: > > > Why do you change serverID? > In a configuration with two mirrors I have to set two different IDs. > The problem > is that the replica defaults to serverID=0, whilst I understood that > the replica > does not need a serverID. > > So you're saying serverID=0, serverID=1, serverID=2 makes a > difference > > from serverID=1, serverID=2, serverID=3? > > > > They only have to be unique. > > > > Yes. Let me put the problem another way : > > In 2.4.11 each time you start slapd (master as well as replica) it > scans (reads) > all of the objects being more recent than its contextCSN value having > ITS OWN > serverID. Wouldn't it be bettre that it scans only the objects more > recent thant > the moste recent value of the contextCSN ? > If y have millions of such entries the scanning taks too long. > Is this a bug or a normal feature ? This is intended: servers/slapd/overlays/syncprov.c in HEAD 615 | case FIND_MAXCSN: 616 | | cf.f_choice = LDAP_FILTER_GE; 617 | | /* If there are multiple CSNs, use the one with our serverID */ 618 | | for ( i=0; i<si->si_numcsns; i++) { 619 | | | if ( slap_serverID == si->si_sids[i] ) { 620 | | | | maxid = i; 621 | | | | break; 622 | | | } 623 | | } 624 | | if ( i == si->si_numcsns ) { 625 | | | /* No match: this is multimaster, and none of the content in the DB 626 | | | * originated locally. Treat like no CSN. 627 | | | */ 628 | | | return LDAP_NO_SUCH_OBJECT; 629 | | } > > > There are no writes above, you've only shown searches. > > Yes there are no writes because this is an extract of the startup > log. > > > How many times do you restart slapd and why? > > In production I restart slapd once a day for backup. But the problem > is that if > I restart it for any reason I have to wait to much for the service to > be > available. A cold backup of the bdb dir I take it. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#5656) Bind operations with translucent overlay
by mateusz.kijowski＠gmail.com 14 Aug '08

14 Aug '08

Full_Name: Mateusz Kijowski Version: 2.3.43 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.126.222.22) In some use scenarios, it is useful if the translucent overlay does not forward bind operation requests to the remote server when there are values for userPassword attribute in the local database. It would be nice if this could be enabled or disabled by a configuration option. For consistency, enabling this behavior should also affect the PASSMOD extended operation to modify the local value of userPassword.

1 0

Re: (ITS#5578) sortvals error
by andrew.findlay＠skills-1st.co.uk 14 Aug '08

14 Aug '08

On Sat, Jul 05, 2008 at 09:31:28PM +0000, hyc(a)symas.com wrote: > Thanks for the report. Seems the search routine wasn't copied correctly from > back-bdb/idl.c. Fixed now in HEAD. Not quite I'm afraid. It now crashes if a value is added that sorts to the head of the list. I applied this LDIF to the original test case data: dn: cn=tenK,ou=groups,o=test,dc=example,dc=org changetype: modify add: member member: uniqueIdentifier=a_0,dc=example,dc=org Running the server with '-d 65535' the trace ends thus: <= entry_decode(cn=tenK,ou=groups,o=test,dc=example,dc=org) bdb_modify: cn=tenK,ou=groups,o=test,dc=example,dc=org slap_queue_csn: queing 0xa74b3c42 20080814122245.470522Z#000000#000#000000 bdb_dn2entry("cn=tenk,ou=groups,o=test,dc=example,dc=org") bdb_modify_internal: 0x00000004: cn=tenK,ou=groups,o=test,dc=example,dc=org <= acl_access_allowed: granted to database root bdb_modify_internal: add member dnMatch 5 "uniqueIdentifier=a_004997,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_004995,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_000001,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_000000,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_004997,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_004995,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_000001,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" dnMatch 5 "uniqueIdentifier=a_000000,dc=example,dc=org" "uniqueIdentifier=a_0,dc=example,dc=org" Program received signal SIGSEGV, Segmentation fault. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ali.pouya＠free.fr 14 Aug '08

14 Aug '08

Gavin Henry <ghenry(a)suretecsystems.com> wrote : > ali.pouya(a)free.fr wrote: > Why do you change serverID? In a configuration with two mirrors I have to set two different IDs. The problem is that the replica defaults to serverID=0, whilst I understood that the replica does not need a serverID. > > So you're saying serverID=0, serverID=1, serverID=2 makes a difference > from serverID=1, serverID=2, serverID=3? > > They only have to be unique. > Yes. Let me put the problem another way : In 2.4.11 each time you start slapd (master as well as replica) it scans (reads) all of the objects being more recent than its contextCSN value having ITS OWN serverID. Wouldn't it be bettre that it scans only the objects more recent thant the moste recent value of the contextCSN ? If y have millions of such entries the scanning taks too long. Is this a bug or a normal feature ? > There are no writes above, you've only shown searches. Yes there are no writes because this is an extract of the startup log. > How many times do you restart slapd and why? In production I restart slapd once a day for backup. But the problem is that if I restart it for any reason I have to wait to much for the service to be available. I hope I have have understood and answered to your quetions. Thanks Best Regards Ali

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by michael＠stroeder.com 14 Aug '08

14 Aug '08

Philip Guenther wrote: > On Thu, 14 Aug 2008, Michael Ströder wrote: > ... >> From my understanding this is what LDAP_OPT_X_TLS_CIPHER_SUITE is for, >> isn't it? It's directly passed to OpenSSL and can also be used to enable >> or disable SSLv2, SSLv3 and TLSv1 besides choosing the ciphers itself. > > Nope. The cipher suite list and protocol versions supported are > orthogonal: even if you include "!SSLv2" in your cipher suite, openssl > will still send an SSLv2-compatible handshake. Ditto on the server side: > when OpenSSL announced a vulnerability in the server SSLv2 handshake code, > I looked at whether specifying "!SSLv2" in the cipher spec would protect > the server as a workaround. Nope: only setting the SSL_OP_NO_SSLv2 option > or using a SSLv3-only or TLSv1-only method would do it. Ok. >> Apache HTTP server does it also that way. See: >> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite > > They also have the "SSLProtocol" directive, further down on that page. Then I'd vote for doing it exactly like this with one option (space- or comma-separated list of protocols). Ciao, Michael.

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by guenther+ldapdev＠sendmail.com 14 Aug '08

14 Aug '08

On Wed, 13 Aug 2008, Howard Chu wrote: > Philip Guenther wrote: ... > > OpenSSL's API for this is a bitfield with symbolic names, so there > > would still need to be a maintained mapping from whatever schema > > OpenLDAP provided to that bit set. > > Yes, but there's no forward compatibility impact from this. I.e., if we > have to map numbers to bitfields, we can just have a default case: if > the number is higher than any we recognize, just disable all the bits we > know about and assume the TLS library is smart enough to do something > useful with whatever is left. Hmm, with a warning in the docs "if you set this option to a value beyond the range understood by your version of OpenLDAP or the underlying SSL library, it may enforce a lower minimum or fail completely". So instead of writing TLS_PROTOCOL_MIN TLSv1.0 they would write TLS_PROTOCOL_MIN 3,1 etc? I guess that's acceptable to me, albeit a little user unfriendly. > > I guess an alternative would be to directly expose the > > SSL_CTX_set_options() API: TLS_OPTIONS would take a number and pass it > > directly to that call. Of course, the admin would have to read the .h > > file and do some math to figure out what to set, and there's no guarantee > > that OpenSSL won't change those values across a version change... > > I think at this point we need to get away from using implementation-specific > values. Back when OpenSSL was the only game in town I wouldn't have worried > too much about it, but now it's becoming more of an issue. I guess I shouldn't have left out the "<joke>" brackets around that. Philip

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by hyc＠symas.com 14 Aug '08

14 Aug '08

Philip Guenther wrote: > On Wed, 13 Aug 2008, Howard Chu wrote: >> This should use a single option flag and a numeric or bitfield argument >> for selecting protocols instead. Since we're talking about minimum >> settings, it should likely just be an increasing range of numbers. >> >> I note that the on-the-wire protocol version is just a 16 bit integer; >> we could define protocol names that correspond directly to these values. > > OpenSSL's API for this is a bitfield with symbolic names, so there would > still need to be a maintained mapping from whatever schema OpenLDAP > provided to that bit set. Yes, but there's no forward compatibility impact from this. I.e., if we have to map numbers to bitfields, we can just have a default case: if the number is higher than any we recognize, just disable all the bits we know about and assume the TLS library is smart enough to do something useful with whatever is left. > I guess an alternative would be to directly expose the > SSL_CTX_set_options() API: TLS_OPTIONS would take a number and pass it > directly to that call. Of course, the admin would have to read the .h > file and do some math to figure out what to set, and there's no guarantee > that OpenSSL won't change those values across a version change... I think at this point we need to get away from using implementation-specific values. Back when OpenSSL was the only game in town I wouldn't have worried too much about it, but now it's becoming more of an issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by guenther+ldapdev＠sendmail.com 14 Aug '08

14 Aug '08

On Wed, 13 Aug 2008, Howard Chu wrote: > This should use a single option flag and a numeric or bitfield argument > for selecting protocols instead. Since we're talking about minimum > settings, it should likely just be an increasing range of numbers. > > I note that the on-the-wire protocol version is just a 16 bit integer; > we could define protocol names that correspond directly to these values. OpenSSL's API for this is a bitfield with symbolic names, so there would still need to be a maintained mapping from whatever schema OpenLDAP provided to that bit set. I guess an alternative would be to directly expose the SSL_CTX_set_options() API: TLS_OPTIONS would take a number and pass it directly to that call. Of course, the admin would have to read the .h file and do some math to figure out what to set, and there's no guarantee that OpenSSL won't change those values across a version change... Philip Guenther

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by guenther+ldapdev＠sendmail.com 14 Aug '08

14 Aug '08

On Thu, 14 Aug 2008, Michael Ströder wrote: ... > From my understanding this is what LDAP_OPT_X_TLS_CIPHER_SUITE is for, > isn't it? It's directly passed to OpenSSL and can also be used to enable > or disable SSLv2, SSLv3 and TLSv1 besides choosing the ciphers itself. Nope. The cipher suite list and protocol versions supported are orthogonal: even if you include "!SSLv2" in your cipher suite, openssl will still send an SSLv2-compatible handshake. Ditto on the server side: when OpenSSL announced a vulnerability in the server SSLv2 handshake code, I looked at whether specifying "!SSLv2" in the cipher spec would protect the server as a workaround. Nope: only setting the SSL_OP_NO_SSLv2 option or using a SSLv3-only or TLSv1-only method would do it. > Apache HTTP server does it also that way. See: > http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite They also have the "SSLProtocol" directive, further down on that page. Philip Guenther

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by michael＠stroeder.com 14 Aug '08

14 Aug '08

guenther+ldapdev(a)sendmail.com wrote: > It's time for SSL version 2.0 to die: Yupp! > As a first step, here's a patch against the CVS trunk that adds the ability to > set the minimum TLS/SSL protocol from the C API (LDAP_OPT_X_TLS_PROTOCOL_MIN), > the ldap.conf (TLS_PROTOCOL_MIN), and the slapd config > (TLSProtocolMin/olcTLSProtocolMin). Possible settings are: > C API ldap_[sg]et_option() ldap.conf/slapd config > ----------------------------------------------------------- > LDAP_OPT_X_TLS_PROTOCOL_SSLv2 SSLv2 > LDAP_OPT_X_TLS_PROTOCOL_SSLv3 SSLv3 > LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 TLSv1 OR TLSv1.0 From my understanding this is what LDAP_OPT_X_TLS_CIPHER_SUITE is for, isn't it? It's directly passed to OpenSSL and can also be used to enable or disable SSLv2, SSLv3 and TLSv1 besides choosing the ciphers itself. Apache HTTP server does it also that way. See: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslciphersuite This patch could be necessary if different SSL implementations can be used which have different parameters for this. Still you would have to set other implementation-specific parameters... Ciao, Michael.

1 0

Re: (ITS#5655) add option for setting minimum TLS/SSL protocol
by hyc＠symas.com 14 Aug '08

14 Aug '08

guenther+ldapdev(a)sendmail.com wrote: > Full_Name: Philip Guenther > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/guenther-080813.patch > Submission from: (NULL) (64.58.1.252) > > > It's time for SSL version 2.0 to die: it has numerous weaknesses and has been > superseded by SSL version 3.0 and TLS version 1.0 for *years*. Indeed, the LDAP > Start_Tls extended operation is defined by reference to the TLS standard. > > (It could be argued that a client that sends an SSLv2-compatible handshake after > doing Start_Tls is non-compliant, or at least non-interoperable, as servers are > only required to support true TLS handshakes.) > > As a first step, here's a patch against the CVS trunk that adds the ability to > set the minimum TLS/SSL protocol from the C API (LDAP_OPT_X_TLS_PROTOCOL_MIN), > the ldap.conf (TLS_PROTOCOL_MIN), and the slapd config > (TLSProtocolMin/olcTLSProtocolMin). Possible settings are: > C API ldap_[sg]et_option() ldap.conf/slapd config > ----------------------------------------------------------- > LDAP_OPT_X_TLS_PROTOCOL_SSLv2 SSLv2 > LDAP_OPT_X_TLS_PROTOCOL_SSLv3 SSLv3 > LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 TLSv1 OR TLSv1.0 Using an option flag for each protocol version seems excessive; it will be a recurring maintenance burden because each new option flag reflects an API change. (GnuTLS claims to already support TLSv1.2.) This should use a single option flag and a numeric or bitfield argument for selecting protocols instead. Since we're talking about minimum settings, it should likely just be an increasing range of numbers. I note that the on-the-wire protocol version is just a 16 bit integer; we could define protocol names that correspond directly to these values. > (1.0, because TLSv1.1 is already published, even though OpenSSL doesn't support > it yet) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5655) add option for setting minimum TLS/SSL protocol
by guenther+ldapdev＠sendmail.com 14 Aug '08

14 Aug '08

Full_Name: Philip Guenther Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/guenther-080813.patch Submission from: (NULL) (64.58.1.252) It's time for SSL version 2.0 to die: it has numerous weaknesses and has been superseded by SSL version 3.0 and TLS version 1.0 for *years*. Indeed, the LDAP Start_Tls extended operation is defined by reference to the TLS standard. (It could be argued that a client that sends an SSLv2-compatible handshake after doing Start_Tls is non-compliant, or at least non-interoperable, as servers are only required to support true TLS handshakes.) As a first step, here's a patch against the CVS trunk that adds the ability to set the minimum TLS/SSL protocol from the C API (LDAP_OPT_X_TLS_PROTOCOL_MIN), the ldap.conf (TLS_PROTOCOL_MIN), and the slapd config (TLSProtocolMin/olcTLSProtocolMin). Possible settings are: C API ldap_[sg]et_option() ldap.conf/slapd config ----------------------------------------------------------- LDAP_OPT_X_TLS_PROTOCOL_SSLv2 SSLv2 LDAP_OPT_X_TLS_PROTOCOL_SSLv3 SSLv3 LDAP_OPT_X_TLS_PROTOCOL_TLSv1_0 TLSv1 OR TLSv1.0 (1.0, because TLSv1.1 is already published, even though OpenSSL doesn't support it yet) This option is set up to specify a minimum version instead of permitting arbitrary control of which versions are supported because the SSL/TLS version negotiation assumes that both ends support a contiguous range. If one end has a gap in what it supports (e.g., SSLv2 and TLSv1, but not SSLv3), then it'll fail to handshake with another one that has the missing version as its highest supported version, even though they both support a lower version. Simply setting just the lower-bound prevents the specification of such a 'silly-state'. (for example: "openssl s_client -no_ssl3" will fail to handshake with "openssl s_server -no_tls1", even though they both support SSLv2. Ditto if you flip the ends.)

1 0

Re: (ITS#5640) slapd scans too many objects at startup
by ghenry＠suretecsystems.com 14 Aug '08

14 Aug '08

ali.pouya(a)free.fr wrote: > Full_Name: Ali Pouya > Version: 2.4.11 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (145.242.11.4) > > > I have a test directory with two mirrors A and B and a replica C connected to > A. > I usaually use server A for write operations. > > I encounter the following problems : > > > 1) If the data base is initiated in stand alone (so serverID defaults to zero) > and then I set serverIDs 1 and 2 for A and B then each time I start up slapd on > C it scans all of the objects writtent on A afterwards, producing the followin > log for each object : Why do you change serverID? > > ====================================================== > entry_decode: "cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr" > <= entry_decode(cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr) > => bdb_dn2id("cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr") > <= bdb_dn2id: got id=0x9 > => test_filter > GE > => access_allowed: search access to "cn=testr1,ou=resources,ou=mefi,o=gouv,c=fr" > "entryCSN" requested > <= root access granted > => access_allowed: search access granted by manage(=mwrscxd) > <= test_filter 6 > ====================================================== > > For a directory with 10 million objects the this takes more than one hour (slapd > is running but the service is not available). > If I set serverID=3 on the replica C the problem disapears. So you're saying serverID=0, serverID=1, serverID=2 makes a difference from serverID=1, serverID=2, serverID=3? They only have to be unique. > > 2) If I do only one write operation on B, then I get two contextCSN values, > which is normal. > > But il this case slapd on B scans, at each startup, all objecs written on A > after the write operation on B. > The log and the effect are similar to those explained above. > > Should I consider this as a normal behaviour or a bug ? There are no writes above, you've only shown searches. How many times do you restart slapd and why? > > My mirror configuration is similar to the one recommended in Admin's Guide. > Of course I can provide more detailed information if required. > > Thanks for your HELP > Best Regards > Ali > > -- Kind Regards, Gavin Henry. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

(ITS#5654) memberof syntax clunky
by abartlet＠samba.org 12 Aug '08

12 Aug '08

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.176.63.104) As instructed by Howard: From: Howard Chu <hyc(a)highlandsun.com> To: samba-technical(a)lists.samba.org Subject: Re: samba4-ol-mmr Date: Mon, 11 Aug 2008 21:09:52 -0700 (Tue, 14:09 EST) > # Generated from schema in /usr/local/samba/private/ldap/schema-tmp.ldb > overlay memberof > memberof-dn cn=samba-admin,cn=samba > memberof-dangling error > memberof-refint TRUE > memberof-group-oc top > memberof-member-ad msDS-ObjectReference > memberof-memberof-ad msDS-ObjectReferenceBL > memberof-dangling-error 32 (repeats once per attribute link) ... Mmm, that's really clunky. Someone should file an OpenLDAP enhancement request on the memberof config syntax. You should only need to instantiate the overlay once, and then it should just take a list of oc/forward-ad/back-ad config options. > Look closely at how we sub in memberof configuration into the > slapd.conf. I suggest that you could add a ${REPL_CONFIG} after each > database, which the script could sub with either "" or by reading and > subing in a slapd-replica.conf -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5641) Segmentation fault - slaptest and slapd
by hfranzke＠tee.toshiba.de 11 Aug '08

11 Aug '08

Tested and it works. Thanks. Helmut Franzke On Saturday 09 August 2008 10:30:35 Pierangelo Masarati wrote: > Fixed in HEAD; please test. p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- -- Toshiba Electronics Europe GmbH Helmut Franzke E-Mail: hfranzke(a)tee.toshiba.de Tel: +49-211-5296-666 Fax: +49-211-5296-386 ----------------- () Join the ASCII ribbon campaign against html email /\ and Microsoft attachments. CONFIDENTIALITY DISCLAIMER The information in this email and in any attachments is confidential and may be privileged. If you are not the intended recipient, please destroy this message, delete any copies held on your systems and notify the sender immediately. You should not retain, copy or use this email for any purpose outside of any NDA currently existing between Toshiba Electronics Europe GmbH and yourselves. Toshiba Electronics Europe GmbH Hansaallee 181 - 40549 Duesseldorf - Germany Phone: +49 (211) 5296-0 - Fax: +49 (211) 5296-400 Handelsregister Duesseldorf HRB 22487 Geschaeftsfuehrer: Hitoshi Otsuka Amtsgericht Duesseldorf

1 0

(ITS#5653) Segmentation Fault running slapd with mysql back-end
by ollieeillo＠yahoo.co.uk 11 Aug '08

11 Aug '08

Full_Name: Ollie Version: openldap-2.3.39 OS: CentOS release 4.5 (Final) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.248.134.226) CentOS release 4.5 (Final) openldap-2.3.39 (Stable) mysql 5.0.27-max (Cluster) localhost openssl-0.9.8h libiodbc-3.52.6 (iODBC) slapd.conf ###################### include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args allow bind_v2 access to * by * read access to * by * write database sql dbname openldap dbuser ldap dbpasswd <snip> loglevel 264 suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" ################################################# Worked perfectly with db-4.5.20 but as soon as mysql is used a segmentation fault happens. Strangely, if the mysql database tables are unpopulated then slapd starts fine. It's only once the test tables are populated that segmentation fault happens mysql openldap < testdb_data.sql mysql openldap < testdb_metadata.sql iodbc ####################### ./configure --with-iodbc-inidir=/etc make make install running slapd ####################### # /usr/local/libexec/slapd -d -1 .... backsql_db_open(): setting "DELETE FROM ldap_entry_objclasses WHERE entry_id=?" by default ==>backsql_get_db_conn() ==>backsql_open_db_conn(18446744073709551615) <==backsql_open_db_conn(18446744073709551615) backsql_open_db_conn(18446744073709551615): connected, adding to tree. <==backsql_get_db_conn() ==>backsql_load_schema_map() backsql_load_schema_map(): oc_query "SELECT id,name,keytbl,keycol,create_proc,delete_proc,expect_return FROM ldap_oc_mappings" backsql_load_schema_map(): objectClass "organization": keytbl="institutes" keycol="id" expect_return: add=0, del=0; attributes: backsql_load_schema_map(): objectClass "inetOrgPerson": keytbl="persons" keycol="id" expect_return: add=0, del=0; attributes: backsql_load_schema_map(): objectClass "document": keytbl="documents" keycol="id" expect_return: add=0, del=0; attributes: backsql_load_schema_map(): objectClass "referral": keytbl="referrals" keycol="id" expect_return: add=0, del=0; attributes: backsql_load_schema_map(): at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" backsql_oc_get_attr_mapping(): executing at_query "SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=?" for objectClass "document" with param oc_id="2" attributeType: name="(null)" sel_expr="(null)" from="(null)" join_where="(null)" add_proc="(null)" delete_proc="(null)" sel_expr_u="" Segmentation fault ############################################ >>>>> Executing all LDAP tests for sql >>>>> Starting sql-test000-read ... running defines.sh Starting slapd on TCP/IP port 9011... Testing SQL backend read operations... Waiting 5 seconds for slapd to start... ./scripts/sql-test000-read: line 42: 3729 Segmentation fault $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... make: *** [sql-yes] Interrupt

1 0

(ITS#5652) configure errors
by edpena＠cisco.com 10 Aug '08

10 Aug '08

Full_Name: Ed Pena Version: openldap-2.3.39 OS: hpux 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.102.254.33) checking arpa/nameser.h usability... no checking arpa/nameser.h presence... yes configure: WARNING: arpa/nameser.h: present but cannot be compiled configure: WARNING: arpa/nameser.h: check for missing prerequisite headers? configure: WARNING: arpa/nameser.h: see the Autoconf documentation configure: WARNING: arpa/nameser.h: section "Present But Cannot Be Compiled" configure: WARNING: arpa/nameser.h: proceeding with the preprocessor's result configure: WARNING: arpa/nameser.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking shadow.h usability... no checking shadow.h presence... yes configure: WARNING: shadow.h: present but cannot be compiled configure: WARNING: shadow.h: check for missing prerequisite headers? configure: WARNING: shadow.h: see the Autoconf documentation configure: WARNING: shadow.h: section "Present But Cannot Be Compiled" configure: WARNING: shadow.h: proceeding with the preprocessor's result configure: WARNING: shadow.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking for shadow.h... yes

1 0

(ITS#5651) pthread error in configure
by edpena＠cisco.com 10 Aug '08

10 Aug '08

Full_Name: Ed Pena Version: openldap-2.3.39 OS: hpux 11.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.102.254.33) checking pthread.h usability... no checking pthread.h presence... yes configure: WARNING: pthread.h: present but cannot be compiled configure: WARNING: pthread.h: check for missing prerequisite headers? configure: WARNING: pthread.h: see the Autoconf documentation configure: WARNING: pthread.h: section "Present But Cannot Be Compiled" configure: WARNING: pthread.h: proceeding with the preprocessor's result configure: WARNING: pthread.h: in the future, the compiler will take precedence configure: WARNING: ## --------------------------------------------- ## configure: WARNING: ## Report this to <http://www.openldap.org/its/> ## configure: WARNING: ## --------------------------------------------- ## checking for pthread.h... yes

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by hyc＠symas.com 09 Aug '08

09 Aug '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >> Seems that we should add a backend_attribute handler to the translucent overlay. > > That's not going to work anyway, since the overlay's bi_acl_attribute > method is not going to be called anyway. In fact, any call to > backend_attribute will be cast into a call to bi_entry_get_rw, so only > by implementing translucent_entry_get_rw we could have a chance to look > the remote entry up. But then we'd probably have issues in the > subsequent call to translucent_entry_release, to distinguish whether the > looked-up entry was from the local or the remote database... And see > ITS#5650: right now, even if the attribute is not local, the local entry > will always be returned. I think in most cases the entry that translucent returns will have to be constructed from both local and remote anyway. In which case, translucent_release should just be a call to entry_free; the original local entry should be duplicated and released immediately. >>>> I've also tried to hack the translucent overlay so that it would support the >>>> bi_entry_get_rw callback but I haven't been able to provide something that would >>>> even satisfy me. I suppose I would have to use some sort of callback mechanism >>>> like translucent_search_cb but I haven't figured it out yet. >>> That's another problem I ran through when trying to add rewrite >>> capabilities to the slapo-rwm(5) overlay, so that authorization could be >>> rewrapped when performed through virtual data views. However, I believe >>> the API of bi_entry_get_rw be modified for overlays, since the current >>> API does not allow calls to modify their arguments. I'd leave that >>> alone by now. >> Haven't looked closely at this yet... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by ando＠sys-net.it 09 Aug '08

09 Aug '08

hyc(a)symas.com wrote: > Seems that we should add a backend_attribute handler to the translucent overlay. That's not going to work anyway, since the overlay's bi_acl_attribute method is not going to be called anyway. In fact, any call to backend_attribute will be cast into a call to bi_entry_get_rw, so only by implementing translucent_entry_get_rw we could have a chance to look the remote entry up. But then we'd probably have issues in the subsequent call to translucent_entry_release, to distinguish whether the looked-up entry was from the local or the remote database... And see ITS#5650: right now, even if the attribute is not local, the local entry will always be returned. >>> I've also tried to hack the translucent overlay so that it would support the >>> bi_entry_get_rw callback but I haven't been able to provide something that would >>> even satisfy me. I suppose I would have to use some sort of callback mechanism >>> like translucent_search_cb but I haven't figured it out yet. >> That's another problem I ran through when trying to add rewrite >> capabilities to the slapo-rwm(5) overlay, so that authorization could be >> rewrapped when performed through virtual data views. However, I believe >> the API of bi_entry_get_rw be modified for overlays, since the current >> API does not allow calls to modify their arguments. I'd leave that >> alone by now. > > Haven't looked closely at this yet... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5650) The bdb_entry_get() call ignores the attribute arg
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The call bdb_entry_get() ignores the attribute description passed as arg, returning the entry if it exists and if it belongs to the objectClass optionally passed as arg. The fix is trivial: check if the attribute is present in the entry. The only question is: should we also check for subtypes? Right now, I'm fixing it for strict attribute type. p.

1 0

Re: problem with ldap backend / rwm overlay (ITS#5647)
by brett.maxfield＠gmail.com 09 Aug '08

09 Aug '08

------=_Part_137280_15866481.1218285287040 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Works exactly as it should, extra attributes are now hidden :) Thanks very much. Brett On Sat, Aug 9, 2008 at 7:02 PM, Pierangelo Masarati < openldap-its(a)openldap.org> wrote: > Should be fixed now in HEAD, for both slapo-rwm and slapd-meta. Please > test. > > p. > ------=_Part_137280_15866481.1218285287040 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div dir="ltr">Works exactly as it should, extra attributes are now hidden :)<br><br>Thanks very much.<br><br>Brett<br><br><div class="gmail_quote">On Sat, Aug 9, 2008 at 7:02 PM, Pierangelo Masarati <span dir="ltr"><<a href="mailto:openldap-its@openldap.org">openldap-its(a)openldap.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Should be fixed now in HEAD, for both slapo-rwm and slapd-meta.  Please test.<br> <font color="#888888"><br> p.<br> </font></blockquote></div><br></div> ------=_Part_137280_15866481.1218285287040--

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by hyc＠symas.com 09 Aug '08

09 Aug '08

ando(a)sys-net.it wrote: > kouk(a)noc.uoa.gr wrote: >> Full_Name: Kostantinos Koukopoulos >> Version: 2.4.11 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723-2.patch >> Submission from: (NULL) (195.134.100.30) >> >> >> When using the translucent overlay, if one tries to use set syntax in an ACL or >> ACI rule, in order to dereference the bound user, like in the example below, >> then the user's entry is fetched from the local database only. >> >> Example<who> clause: >> by set="user/eduPersonOrgUnitDN& [ou=someunit,dc=someorg,dc=somecountry]" >> >> If the 'eduPersonOrgUnitDN' attribute has not been modified it will not be found >> in the local database. I believe it would be better if the remote database was >> also checked, like when a search operation is performed against the overlay. >> >> I found the problem was due to that acl_set_gather2 tries to fetch the attribute >> directly from the backend, but the translucent overlay does not support this, so >> the backend is used instead. I've attached a patch which makes acl_set_gather >> always use an internal search operation to fetch the attribute, instead of >> calling acl_set_gather2. > > Although I understand the spirit of the patch you propose, I'm not sure > it is the right solution. In fact, running an internal search like that > implies that the whole overlay chain be run through. Probably, that's > correct in the case of the translucent overlay, though. I need to think > about it. Any comments by others? Seems that we should add a backend_attribute handler to the translucent overlay. >> I've also tried to hack the translucent overlay so that it would support the >> bi_entry_get_rw callback but I haven't been able to provide something that would >> even satisfy me. I suppose I would have to use some sort of callback mechanism >> like translucent_search_cb but I haven't figured it out yet. > > That's another problem I ran through when trying to add rewrite > capabilities to the slapo-rwm(5) overlay, so that authorization could be > rewrapped when performed through virtual data views. However, I believe > the API of bi_entry_get_rw be modified for overlays, since the current > API does not allow calls to modify their arguments. I'd leave that > alone by now. Haven't looked closely at this yet... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5618) better error messages for syncrepl failure
by hyc＠symas.com 09 Aug '08

09 Aug '08

henson(a)acm.org wrote: > Full_Name: Paul B. Henson > Version: 2.3.40 > OS: Gentoo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (134.71.248.24) > > > I recently installed some updates and configuration changes on one of my > LDAP slaves. Replication broke mysteriously after that. The only thing logged > was "slapd[30723]: do_syncrepl: rid 001 retrying (9 retries left)" > > I finally figured out that the search was failing with a protocol error because > derefAliases was set to always, a setting I had just added. It would be useful > if replication failure provided better error messages, something in the logs > indicating that a protocol error had occurred because of an invalid > dereferencing setting would have saved me a lot of time. An additional log message for this situation has been added. > In addition, if it is a protocol error to dereference aliases in the context of > syncrepl, shouldn't the server just ignore that global configuration setting and > just do the right thing? A patch has been applied to always set Deref to Never. These changes are in CVS HEAD, please test. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5628) dereferencing user with translucent overlay
by ando＠sys-net.it 09 Aug '08

09 Aug '08

kouk(a)noc.uoa.gr wrote: > Full_Name: Kostantinos Koukopoulos > Version: 2.4.11 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723-2.patch > Submission from: (NULL) (195.134.100.30) > > > When using the translucent overlay, if one tries to use set syntax in an ACL or > ACI rule, in order to dereference the bound user, like in the example below, > then the user's entry is fetched from the local database only. > > Example <who> clause: > by set="user/eduPersonOrgUnitDN & [ou=someunit,dc=someorg,dc=somecountry]" > > If the 'eduPersonOrgUnitDN' attribute has not been modified it will not be found > in the local database. I believe it would be better if the remote database was > also checked, like when a search operation is performed against the overlay. > > I found the problem was due to that acl_set_gather2 tries to fetch the attribute > directly from the backend, but the translucent overlay does not support this, so > the backend is used instead. I've attached a patch which makes acl_set_gather > always use an internal search operation to fetch the attribute, instead of > calling acl_set_gather2. Although I understand the spirit of the patch you propose, I'm not sure it is the right solution. In fact, running an internal search like that implies that the whole overlay chain be run through. Probably, that's correct in the case of the translucent overlay, though. I need to think about it. Any comments by others? > I've also tried to hack the translucent overlay so that it would support the > bi_entry_get_rw callback but I haven't been able to provide something that would > even satisfy me. I suppose I would have to use some sort of callback mechanism > like translucent_search_cb but I haven't figured it out yet. That's another problem I ran through when trying to add rewrite capabilities to the slapo-rwm(5) overlay, so that authorization could be rewrapped when performed through virtual data views. However, I believe the API of bi_entry_get_rw be modified for overlays, since the current API does not allow calls to modify their arguments. I'd leave that alone by now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5627) set syntax in ACI's
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Can't find the patch; however, the problem should now be fixed, thanks. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5637) dynacl broken when an access mask has been already applied by previous ACL rule
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Fixed in HEAD, thanks. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5636) performance improvement in ACI evaluation
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Applied to HEAD, thanks. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5641) Segmentation fault - slaptest and slapd
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Fixed in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

ITS#5581 reopened
by ando＠sys-net.it 09 Aug '08

09 Aug '08

Should be re-fixed now in HEAD; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5649) overlay_register_control doesn't work
by hyc＠OpenLDAP.org 09 Aug '08

09 Aug '08

Full_Name: Howard Chu Version: 2.3/2.4/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc For non-global overlays, overlay_register_control sets the control flags in the temporary BackendDB structure, which is discarded shortly thereafter. It needs to set the flags in the real BackendDB structure.

1 0

Re: (ITS#5648) ppolicy controls entries without objectclass pwdPolicy
by hyc＠symas.com 08 Aug '08

08 Aug '08

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: 2.4.11 > OS: openSUSE-11.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.237.56) > > > Hello, > man slapo-ppolicy(5) says that the overlay depends on objectclass pwdPolicy and > Every account that should be subject to password policy control should have > pwdPolicySubentry... As usual, it's important that you read every word in the manpage and not skip over anything. The manpage says: >> Every account that should be subject to password policy control should have a pwdPolicySubentry attribute containing the DN of a valid pwdPolicy entry, or they can simply use the configured default. << This means the pwdPolicy entry is some other entry, not that user entries must have the pwdPolicy class. Yes, the overlay depends on the pwdPolicy class because entries of pwdPolicy class must be used to store the policy definitions. It doesn't say that user entries must have pwdPolicy class and it would be stupid to store the policy definitions in the user entries. And it would be pointless to require a pwdPolicySubentry attribute to point to the relevant policy if the policy was simply stored in the user entry. Use your brain. This ITS will be closed. > But ppolicy is controlling every enty, even those without attribute pwdPolicy > and attribute pwdPolicySubentry. > I have created a test entry, which is not subject to password policy but got > locked out after 3 binds with wrong password. > > dn: cn=pw tester,o=avci,c=de > cn: pw tester > createTimestamp: 20080808132851Z > creatorsName: cn=admin,o=avci,c=de > description: Password Tester > entryCSN: 20080808132851.203028Z#000000#000#000000 > entryDN: cn=pw tester,o=avci,c=de > entryUUID: af06a7e2-f999-102c-8d8e-df96a2a401d4 > hasSubordinates: FALSE > modifiersName: cn=admin,o=avci,c=de > modifyTimestamp: 20080808132851Z > objectClass: person > pwdAccountLockedTime: 20080808133126Z > pwdChangedTime: 20080808132851Z > pwdFailureTime: 20080808133058Z > pwdFailureTime: 20080808133109Z > pwdFailureTime: 20080808133126Z > sn: tester > structuralObjectClass: person > subschemaSubentry: cn=Subschema > userPassword: tested > > -Dieter > > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5648) ppolicy controls entries without objectclass pwdPolicy
by dieter＠dkluenter.de 08 Aug '08

08 Aug '08

Michael Ströder <michael(a)stroeder.com> writes: > dieter(a)dkluenter.de wrote: >> man slapo-ppolicy(5) says that the overlay depends on objectclass pwdPolicy and >> Every account that should be subject to password policy control should have >> pwdPolicySubentry... >> But ppolicy is controlling every enty, even those without attribute pwdPolicy >> and attribute pwdPolicySubentry. >> I have created a test entry, which is not subject to password policy but got >> locked out after 3 binds with wrong password. > > Do you have 'ppolicy_default' set in slapd.conf? > What happens if you remove that? Yes, I do have ppolicy_default "cn=user,cn=policies,o=avci,c=de" but this should only be applicable if the entry belongs to objectclass pwdPolicy but not without objectclass pwdPolicy declaration. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

1 0

Re: (ITS#5648) ppolicy controls entries without objectclass pwdPolicy
by michael＠stroeder.com 08 Aug '08

08 Aug '08

dieter(a)dkluenter.de wrote: > man slapo-ppolicy(5) says that the overlay depends on objectclass pwdPolicy and > Every account that should be subject to password policy control should have > pwdPolicySubentry... > But ppolicy is controlling every enty, even those without attribute pwdPolicy > and attribute pwdPolicySubentry. > I have created a test entry, which is not subject to password policy but got > locked out after 3 binds with wrong password. Do you have 'ppolicy_default' set in slapd.conf? What happens if you remove that? Ciao, Michael.

1 0

(ITS#5648) ppolicy controls entries without objectclass pwdPolicy
by dieter＠dkluenter.de 08 Aug '08

08 Aug '08

Full_Name: Dieter Kluenter Version: 2.4.11 OS: openSUSE-11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.237.56) Hello, man slapo-ppolicy(5) says that the overlay depends on objectclass pwdPolicy and Every account that should be subject to password policy control should have pwdPolicySubentry... But ppolicy is controlling every enty, even those without attribute pwdPolicy and attribute pwdPolicySubentry. I have created a test entry, which is not subject to password policy but got locked out after 3 binds with wrong password. dn: cn=pw tester,o=avci,c=de cn: pw tester createTimestamp: 20080808132851Z creatorsName: cn=admin,o=avci,c=de description: Password Tester entryCSN: 20080808132851.203028Z#000000#000#000000 entryDN: cn=pw tester,o=avci,c=de entryUUID: af06a7e2-f999-102c-8d8e-df96a2a401d4 hasSubordinates: FALSE modifiersName: cn=admin,o=avci,c=de modifyTimestamp: 20080808132851Z objectClass: person pwdAccountLockedTime: 20080808133126Z pwdChangedTime: 20080808132851Z pwdFailureTime: 20080808133058Z pwdFailureTime: 20080808133109Z pwdFailureTime: 20080808133126Z sn: tester structuralObjectClass: person subschemaSubentry: cn=Subschema userPassword: tested -Dieter

1 0

(ITS#5647) problem with ldap backend / rwm overlay
by brett.maxfield＠gmail.com 08 Aug '08

08 Aug '08

Full_Name: Brett Maxfield Version: slapd 2.4.11 (Jul 29 2008 19:56:20) OS: SunOS qgdmzmlr01 5.10 Generic_127111-11 sun4v sparc SUNW,Sun-Fire-T200 URL: Submission from: (NULL) (203.18.108.168) I am trying to setup a ldap backend which is a filtered view of another larger parent directory, with respect to exposing fewer object classes and attributes. The intent is to present a simpler view of the larger directory, and the config below works, except for when i uncomment the line containing "rwm-map attribute *", to hide the attributes i do not want visible, but after that it stops returning any entries at all for any query. So may be there is some important openldap attribute i am nuking ? The below config works, until the "rwm-map attribute *" line is uncommented, the ldap backend stops returning any entries. Pierangelo Masarati on the list stated : <quote> Yes, I fear that's hiding the objectClass attribute, which is required for internal operations. On the other hand, you can't simply tell back-ldap to preserve that attribute, because mapping objectClass is not allowed. I suggest you file an ITS so that this problem can be fixed. </quote> I have tried mapping the "rwm-map attribute objectClass *", and as Perangelo states, the error is "objectclass attribute cannot be mapped". If this is true, then the usability of rwm-map attribute is extremely compromised, and probably unusable? The structure of the parent directory is : c=AU o=My Org 1 ou=My Unit 1 o=My Org 2 ou=My Unit 2 Config is : database ldap suffix "c=AU" uri "ldap://<parent ip>:<parent port>/" overlay rwm lastmod off # attribute maps (ok except for final "rwm-map attribute *" map) rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute mail * rwm-map attribute c * rwm-map attribute o * rwm-map attribute ou * # does not like this, it stops any entries being returned #rwm-map attribute * # objectclass maps (ok) rwm-map objectclass top * rwm-map objectclass country * rwm-map objectclass organization * rwm-map objectclass organizationalRole * rwm-map objectclass organizationalPerson * rwm-map objectclass organizationalUnit * rwm-map objectclass *

1 0

Re: (ITS#5646) Unable to make the openldap-2.4.11 in fedora9
by hyc＠symas.com 07 Aug '08

07 Aug '08

snkg24(a)gmail.com wrote: > Full_Name: Nar > Version: openldap-2.4.11 > OS: Fedora 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (59.93.52.62) > > > Hi all, > > I am unable to install the openldap using configure. The following error > appearing after inputting the command "make". > > Please provide the solution. This is a dup of ITS#5464, a bug in glibc. https://www.openldap.org/its/index.cgi/Build?id=5464 This ITS will be closed, you can send further followups to ITS#5464. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5646) Unable to make the openldap-2.4.11 in fedora9
by snkg24＠gmail.com 07 Aug '08

07 Aug '08

Full_Name: Nar Version: openldap-2.4.11 OS: Fedora 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (59.93.52.62) Hi all, I am unable to install the openldap using configure. The following error appearing after inputting the command "make". Please provide the solution. ----------- [root@eltserv openldap-2.4.11]# make Making all in /root/Download/openldap-2.4.11 Entering subdirectory include make[1]: Entering directory `/root/Download/openldap-2.4.11/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/root/Download/openldap-2.4.11/include' Entering subdirectory libraries make[1]: Entering directory `/root/Download/openldap-2.4.11/libraries' Making all in /root/Download/openldap-2.4.11/libraries Entering subdirectory liblutil make[2]: Entering directory `/root/Download/openldap-2.4.11/libraries/liblutil' rm -f version.c ../../build/mkversion -v "2.4.11" liblutil.a > version.c cc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB/include -c -o utils.o utils.c cc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB/include -c -o fetch.o fetch.c cc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB/include -c -o getpeereid.o getpeereid.c getpeereid.c: In function lutil_getpeereid: getpeereid.c:65: error: storage size of peercred isnt known make[2]: *** [getpeereid.o] Error 1 make[2]: Leaving directory `/root/Download/openldap-2.4.11/libraries/liblutil' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/root/Download/openldap-2.4.11/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#5642) Double free on exit, when specific attributetype is defined
by hyc＠symas.com 06 Aug '08

06 Aug '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) >> This is now fixed in HEAD. > > Slapd should to refuse to start with a bogus OID like that. > OIDs start with components<0-1>.<0-39> or 2.<any>. > > The LDAP standard doesn't seem to mention this, but RFC 4517 does defer > to X.680 (the ASN.1 spec), which since 1998 has deferred to X.660 - > which I don't have:-( Anyway, my reference is John Larmouth's _ASN.1 > Complete_. And it can be inferred from the BER encoding of the OBJECT > IDENTIFIER type. > Feel free to patch it. The fix I committed was simply to the double-free for any attributeType that inherits from objectClass... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5644) make test000 core dumps
by michael＠stroeder.com 06 Aug '08

06 Aug '08

Ralf Haferkamp wrote: > On Dienstag, 5. August 2008, michael(a)stroeder.com wrote: >> [..] >> slapd starting >> daemon: listen(ldap://localhost:9011/, 5) failed errno=3D98 (Address >> alre= ady in use) >> lt-slapd shutdown: initiated >> =3D=3D=3D=3D> bdb_cache_release_all >> lt-slapd destroy: freeing system resources. >> slapd stopped. >> >> --------------000504090501070603080100-- > This might just be another incarnation of ITS#5251 (duplicate results > from getaddrinfo()). Indeed removing 'localhost' from /etc/hosts in the line starting with '::1' solved this. On my former openSUSE 10.3 system I had disabled IPv6 completely. Hmm... So you can mark ITS#5644 as duplicate of ITS#5251. Ciao, Michael.

1 0

Re: (ITS#5642) Double free on exit, when specific attributetype is defined
by h.b.furuseth＠usit.uio.no 06 Aug '08

06 Aug '08

hyc(a)symas.com writes: >> attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) > > This is now fixed in HEAD. Slapd should to refuse to start with a bogus OID like that. OIDs start with components <0-1>.<0-39> or 2.<any>. The LDAP standard doesn't seem to mention this, but RFC 4517 does defer to X.680 (the ASN.1 spec), which since 1998 has deferred to X.660 - which I don't have:-( Anyway, my reference is John Larmouth's _ASN.1 Complete_. And it can be inferred from the BER encoding of the OBJECT IDENTIFIER type. -- Hallvard

1 0

Re: (ITS#5644) make test000 core dumps
by rhafer＠suse.de 06 Aug '08

06 Aug '08

On Dienstag, 5. August 2008, michael(a)stroeder.com wrote: > This is a multi-part message in MIME format. > --------------000504090501070603080100 > Content-Type: text/plain; charset=UTF-8; format=flowed > Content-Transfer-Encoding: 8bit > > Pierangelo Masarati wrote: > > ----- "Michael Ströder" <michael(a)stroeder.com> wrote: > >> Pierangelo Masarati wrote: > >>> Are you sure you're loading the sasl mechs you've compiled for? > >> > >> That's a typical issue with SASL (see SASL_PATH, in case). > >> > >>>> #2 0x405df014 in ?? () from /usr/lib/libldap-2.4.so.2 > >> > >> Hmm, it seems the problem is rather that the LDAP client libs from > >> the > >> > >> RPM package installed by openSUSE are loaded instead the ones from > >> the > >> > >> build directory. That's bad. Any way around this when running > >> 'make test'? > > > > LD_LIBRARY_PATH to your just built libs? > > Hmm, I don't have a clue what's going on. I tried with my RE24 source > tree from which I've successfully built a couple of days ago. I've > removed openSUSE packages for OpenLDAP client libs and > cyrus-sasl-ldap-auxprop. Still no success. It does not core dump > anymore but slapd does not start (see below). > > Ciao, Michael. > > -------------------------------- snip > --------------------------------- > > >>>>> Starting test000-rootdse ... > > running defines.sh > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve the root DSE... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > Waiting 5 seconds for slapd to start... > ./scripts/test000-rootdse: line 66: kill: (21057) - No such process > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > > >>>>> Test failed > >>>>> ./scripts/test000-rootdse failed (exit 255) > [..] > make: *** [test] Error 2 > -------------------------------- snip > --------------------------------- [..] > slapd starting > daemon: listen(ldap://localhost:9011/, 5) failed errno=3D98 (Address > alre= ady in use) > lt-slapd shutdown: initiated > =3D=3D=3D=3D> bdb_cache_release_all > lt-slapd destroy: freeing system resources. > slapd stopped. > > --------------000504090501070603080100-- This might just be another incarnation of ITS#5251 (duplicate results from getaddrinfo()). -- Ralf

1 0

ITS#5581 reopened
by ando＠sys-net.it 06 Aug '08

06 Aug '08

I have re-opened this bug. I have a fix, will commit ASAP. I confirm the bug only seems to affect malformed filters in the URI. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5581) slapd: search.c:970: oc_filter: Assertion `f != ((void *)0)' failed.
by ando＠sys-net.it 06 Aug '08

06 Aug '08

----- stef(a)memberwebs.com wrote: > I get this problem with 2.4.11 (but not with 2.4.10). My slapo-unique > configuration is as follows: > > unique_uri ldap:///?cn?sub > unique_uri ldap:///?uid,login?sub?(!(disabled=TRUE)) > > The filter seems valid to me, but please correct me if I'm wrong. Does "disabled" exist? I mean: is it defined __before__ this line in your slapd.conf? Does TRUE comply with its syntax? I've checked the fix to this bug, and it seems to mischeck the validity of the filter, so if what you specify in the "filter" field of the URI is not a valid filter, the string "(?=error)" shows up instead of the normalization of your filter, causing subsequent harm to filter evaluation. This does not occur if the filter is valid, so there must be also an error on your side (I'm fixing the test, in the meanwhile, so that the error is notified while parsing the configuration). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5586) SLAPD crashing with SIGABRT in connection.c on Solaris - reference through nil pointer
by dbb＠st-andrews.ac.uk 06 Aug '08

06 Aug '08

Thanks. Howard Chu wrote: > dbb(a)st-andrews.ac.uk wrote: >> Just an update, still present in 2.4.11, backtrace below. Still can't >> work out why it's happening, >> it's something in the way that sendmail uses ldap and not the actual >> queries that cause the crash. >> >> I can replay the connections and searches to the server, and I've used >> Suns ldap load testing software >> to load up the server way over what we ever see and I can't replicate >> the SIGABRT or crash it in any >> other way. >> >> Any help appreciated. > > In frame 5 > print *index > print connections[*index] /usr/local/SUNWspro/bin/dbx /source/openldap-2.4.11/servers/slapd/.libs/slapd ./slapd-2.4.11-core-6-8-08 For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libldap_r-2.4.so.2.1.0 Reading liblber-2.4.so.2.1.0 Reading libltdl.so.3.1.5 Reading libdb-4.2.so Reading libicuuc.so.3 Reading libicudata.so.3 Reading libsasl2.so.2.0.22 Reading libdl.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libgen.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libgcc_s.so.1 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libm.so.2 Reading libCrun.so.1 Reading libc_psr.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@7 a l@7 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@8 a l@8 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@9 a l@9 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@10 a l@10 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@11 a l@11 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@12 a l@12 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() (dbx) thread t@2 t@2 (l@2) stopped in __lwp_kill at 0xfe2c0f90 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1808, 0x1a183c, 0x367, 0x0, 0xa810c, 0x1d7b80), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1217978957), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) print *index *index = 33 (dbx) print connections[*index] connections[*index] = { c_struct_state = 2 c_conn_state = 1 c_conn_idx = 33 c_sd = 33 c_close_reason = 0x1a11bc "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x45fbd0 c_starttime = 1217978957 c_activitytime = 1217978957 c_connid = 436161U c_peer_domain = { bv_len = 7U bv_val = 0x48fda0 "unknown" } c_peer_name = { bv_len = 22U bv_val = 0x4b34b8 "IP=138.251.30.31:34746" } c_listener = 0x23ea28 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x2c2664 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x2c266c } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x4252d8 c_sasl_sockctx = (nil) c_sasl_extra = 0x43a298 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 0 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 0 c_n_get = 0 c_n_read = 0 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x67ac8 = &slap_send_ldap_result() c_send_search_entry = 0x68c40 = &slap_send_search_entry() c_send_search_reference = 0x6b320 = &slap_send_search_reference() c_send_ldap_extended = 0x685e8 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x68968 = &slap_send_ldap_intermediate() } (dbx) A second example in case useful /usr/local/SUNWspro/bin/dbx /source/openldap-2.4.11/servers/slapd/.libs/slapd ./slapd-2.4.11-core-1300-4-8-08 For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libldap_r-2.4.so.2.1.0 Reading liblber-2.4.so.2.1.0 Reading libltdl.so.3.1.5 Reading libdb-4.2.so Reading libicuuc.so.3 Reading libicudata.so.3 Reading libsasl2.so.2.0.22 Reading libdl.so.1 Reading libssl.so.0.9.8 Reading libcrypto.so.0.9.8 Reading libresolv.so.2 Reading libgen.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libc.so.1 Reading libgcc_s.so.1 Reading libgcc_s.so.1 Reading libpthread.so.1 Reading libm.so.2 Reading libCrun.so.1 Reading libc_psr.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0xfe2c0f90: __lwp_kill+0x0008: bcc,a,pt %icc,__lwp_kill+0x18 ! 0xfe2c0fa0 Current function is connection_next 871 assert( connections[*index].c_conn_state == SLAP_C_INVALID ); (dbx) where current thread: t@2 [1] __lwp_kill(0x0, 0x6, 0x0, 0x6, 0xfc00, 0x0), at 0xfe2c0f90 [2] raise(0x6, 0x0, 0xfe2a4a98, 0xffffffff, 0xfe2e8284, 0x6), at 0xfe25fd78 [3] abort(0xfdfff3f0, 0x1, 0xfe2e9288, 0xa83f0, 0xfe2eb298, 0x0), at 0xfe23ff98 [4] __assert(0x1a1808, 0x1a183c, 0x367, 0x0, 0xa810c, 0x1d7b80), at 0xfe2401d4 =>[5] connection_next(c = (nil), index = 0xfdfff6d4), line 871 in "connection.c" [6] connections_timeout_idle(now = 1217851229), line 225 in "connection.c" [7] slapd_daemon_task(ptr = (nil)), line 2152 in "daemon.c" (dbx) threads t@1 a l@1 ?() LWP suspended in __lwp_wait() o> t@2 a l@2 slapd_daemon_task() signal SIGABRT in __lwp_kill() t@3 a l@3 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@4 a l@4 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@5 a l@5 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() t@6 a l@6 ldap_int_thread_pool_wrapper() sleep on 0x258570 in __lwp_park() (dbx) print *index *index = 21 (dbx) print connections[*index] connections[*index] = { c_struct_state = 2 c_conn_state = 1 c_conn_idx = 21 c_sd = 21 c_close_reason = 0x1a11bc "?" c_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_sb = 0x435300 c_starttime = 1217851229 c_activitytime = 1217851229 c_connid = 6825U c_peer_domain = { bv_len = 7U bv_val = 0x419470 "unknown" } c_peer_name = { bv_len = 22U bv_val = 0x413908 "IP=138.251.30.32:40070" } c_listener = 0x23ea28 c_sasl_bind_mech = { bv_len = 0 bv_val = (nil) } c_sasl_dn = { bv_len = 0 bv_val = (nil) } c_sasl_authz_dn = { bv_len = 0 bv_val = (nil) } c_authz_backend = (nil) c_authz_cookie = (nil) c_authz = { sai_method = 128U sai_mech = { bv_len = 0 bv_val = (nil) } sai_dn = { bv_len = 0 bv_val = (nil) } sai_ndn = { bv_len = 0 bv_val = (nil) } sai_ssf = 0 sai_transport_ssf = 0 sai_tls_ssf = 0 sai_sasl_ssf = 0 } c_protocol = 0 c_ops = { stqh_first = (nil) stqh_last = 0x2c16a4 } c_pending_ops = { stqh_first = (nil) stqh_last = 0x2c16ac } c_write_mutex = { __pthread_mutex_flags = { __pthread_mutex_flag1 = 4U __pthread_mutex_flag2 = '\0' __pthread_mutex_ceiling = '\0' __pthread_mutex_type = 0 __pthread_mutex_magic = 19800U } __pthread_mutex_lock = { __pthread_mutex_lock64 = { __pthread_mutex_pad = "" } __pthread_mutex_lock32 = { __pthread_ownerpid = 0 __pthread_lockword = 0 } __pthread_mutex_owner64 = 0 } __pthread_mutex_data = 0 } c_write_cv = { __pthread_cond_flags = { __pthread_cond_flag = "" __pthread_cond_type = 0 __pthread_cond_magic = 17238U } __pthread_cond_data = 0 } c_currentber = (nil) c_sasl_bind_in_progress = '\0' c_writewaiter = '\0' c_is_tls = '\0' c_needs_tls_accept = '\0' c_sasl_layers = '\0' c_sasl_done = '\0' c_sasl_authctx = 0x426680 c_sasl_sockctx = (nil) c_sasl_extra = 0x4346a8 c_sasl_bindop = (nil) c_pagedresults_state = { ps_be = (nil) ps_size = 0 ps_count = 0 ps_cookie = 0 ps_cookieval = { bv_len = 0 bv_val = (nil) } } c_n_ops_received = 0 c_n_ops_executing = 0 c_n_ops_pending = 0 c_n_ops_completed = 0 c_n_get = 0 c_n_read = 0 c_n_write = 0 c_extensions = (nil) c_clientfunc = (nil) c_clientarg = (nil) c_send_ldap_result = 0x67ac8 = &slap_send_ldap_result() c_send_search_entry = 0x68c40 = &slap_send_search_entry() c_send_search_reference = 0x6b320 = &slap_send_search_reference() c_send_ldap_extended = 0x685e8 = &slap_send_ldap_extended() c_send_ldap_intermediate = 0x68968 = &slap_send_ldap_intermediate() } -- The University of St Andrews is a charity registered in Scotland : No SC013532

1 0

Re: (ITS#5641) Segmentation fault - slaptest and slapd
by ando＠sys-net.it 06 Aug '08

06 Aug '08

----- hyc(a)symas.com wrote: > hfranzke(a)tee.toshiba.de wrote: > > Full_Name: Helmut Franzke > > Version: 2.4.11 / 2.4.9 > > OS: Ubuntu server 8.04.1 / Centos 4.6 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (192.109.150.105) > > > > > > I could get slaptest/slapd to produce a segmentation fault by using > the unique > > overlay and a unique_uri with a base dn. This behaviour depends on > the position > > of the overlay/unique_uri in slapd.conf and doesn't appear if you > don't use a > > base dn regardless of the position. (I know an overlay should be > defined after > > the other configuration settings have been set. I encountered this > bug when I > > put it in the first part by mistake, see below) > > We should of course fix the SEGV, but it is already documented that > overlays > must be configured after their corresponding databases. As such, this > is not a > high priority. slapo-unique uses be_nsuffix without testing it, and it's obviously NULL until "suffix" is defined. The fix is trivial, but I can't commit right now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5586) SLAPD crashing with SIGABRT in connection.c on Solaris - reference through nil pointer
by hyc＠symas.com 06 Aug '08

06 Aug '08

dbb(a)st-andrews.ac.uk wrote: > Just an update, still present in 2.4.11, backtrace below. Still can't > work out why it's happening, > it's something in the way that sendmail uses ldap and not the actual > queries that cause the crash. > > I can replay the connections and searches to the server, and I've used > Suns ldap load testing software > to load up the server way over what we ever see and I can't replicate > the SIGABRT or crash it in any > other way. > > Any help appreciated. In frame 5 print *index print connections[*index] -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5641) Segmentation fault - slaptest and slapd
by hyc＠symas.com 06 Aug '08

06 Aug '08

hfranzke(a)tee.toshiba.de wrote: > Full_Name: Helmut Franzke > Version: 2.4.11 / 2.4.9 > OS: Ubuntu server 8.04.1 / Centos 4.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.109.150.105) > > > I could get slaptest/slapd to produce a segmentation fault by using the unique > overlay and a unique_uri with a base dn. This behaviour depends on the position > of the overlay/unique_uri in slapd.conf and doesn't appear if you don't use a > base dn regardless of the position. (I know an overlay should be defined after > the other configuration settings have been set. I encountered this bug when I > put it in the first part by mistake, see below) We should of course fix the SEGV, but it is already documented that overlays must be configured after their corresponding databases. As such, this is not a high priority. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5642) Double free on exit, when specific attributetype is defined
by hyc＠symas.com 06 Aug '08

06 Aug '08

stef(a)memberwebs.com wrote: > Full_Name: Stef Walter > Version: 2.4.11 > OS: FreeBSD 6.3-RELEASE-p2 > URL: > Submission from: (NULL) (38.99.5.20) > > > When the following line is present in the schema (or slapd.conf), then upon exit > any slap* process aborts due to a double free of memory: > > attributetype ( 278.1.3.6.1 NAME 'requireClass' SUP objectClass ) > > > The OID is obviously fictional. This can be triggered reliably by running: > > # slaptest > This is now fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs