- openldap-bugs - openldap.org

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 08 Apr '10

08 Apr '10

> Just one weird case left. Considering the same setup as described above > (back null with 2 back ldap glued underneath): a search with pagedResults > and a page size of 3 (the exact number of results returned by each back > ldap), we get: > - a first page with the 3 results from back ldap 1 > - a second page with 3 results from back ldap 2 (so far, so good) > - but then this last result also has a pagedResults cookie, and the search > can go on and on, returning the same 2nd page. > > Presumably this is related to the patch allowing pagedResults to cross two > databases. If the first returns an empty cookie (no more results), a new > cookie is added. However, this should not be done if the last database > returns no more results. It's related to the fact that I need to parse the cookie when it's not parsed yet, to see whether it's empty. So I'm now parsing it also when working with the last database, which needs to be treated specially (i.e. it must let the empty cookie pss thru). Fixed, will commit in a moment. Thanks, p.

1 0

(ITS#6510) GSSAPI rebind proc will cause mutex deadlock
by inlovewithGod＠gmail.com 08 Apr '10

08 Apr '10

Full_Name: Jeremiah Martell Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.146.101.71) I have three windows active directory servers setup: childA.parent.example.com parent.example.com childB.parent.example.com I do a LDAP+GSSAPI bind to childA.parent.example.com. The bind succeeds. I do a search that returns referrals, (I know I need to be referred to parent, and then childB in order to find my result), and I have openldap follow referrals for me. My rebind proc is a function that only calls: ldap_sasl_interactive_bind_s( ld, NULL, NULL, NULL, NULL, LDAP_SASL_AUTOMATIC, sasl_driver, params ); where sasl_driver and params is the same parameters that I used for the initial bind call to childA. After the seach call, the debug looks like this: > ldap_chase_v3referrals, where ref[0] = parent.example.com > myGSSAPIrebindProc > ldap_sasl_interactive_bind_s < ldap_sasl_interactive_bind_s < myGSSAPIrebindProc < ldap_chase_v3referrals > ldap_chase_v3referrals, where ref[0] = childB.parent.example.com > myGSSAPIrebindProc > ldap_sasl_interactive_bind_s > ldap_chase_v3referrals, where ref[0] = childA.parent.example.com < ldap_chase_v3referrals > ldap_chase_v3referrals, where ref[0] = ForestDnsZones.parent.example.com > myGSSAPIrebindProc > ldap_sasl_interactive_bind_s ... HANG ON MUTEX I changed openldap to make all mutex's recursive, and this fixed my problem. I was then able to search, chase referrals, bind to referrals with ldap_sasl_interactive_bind_s, and eventually find my result. Thanks, - Jeremiah

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 08 Apr '10

08 Apr '10

On Wed, 7 Apr 2010 00:54:46 +0200 (CEST), masarati(a)aero.polimi.it wrote: >> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a écrit : >>> When requesting paged results control on glued databases, if a database >>> (either >>> superior or subordinate) returns one page that ends with the last >>> corresponding >>> entry in that database, the resulting cookie is empty. Thus, the result >>> returned to the client corresponds to the final result of a paged >>> response. >>> However, other databases may have returned data. A fix is being >>> designed. p. >> >> Your fix for this problem works well in my tests. >> >> Under the same subject, another problem arises: >> >> Consider this : >> - back null >> ---- back ldap 1 returning 3 results to a search >> ---- back ldap 2 returning 3 results to a search >> >> And you search "back null" with a page size of 2: >> - The first response contains 2 results from "back ldap 1" and a correct >> cookie. >> - The second response contains 1 result from "back ldap 1" and 1 result >> from "back ldap 2", and another correct cookie. >> - The third request, however, goes back to "back ldap 1", and returns >> the same results as the first response. >> - And so on... forever. >> >> As I mentioned, it seems that to solve this problem we would have to tie >> a paged results cookie to a particular backend under glue... > > Should work now. The issue was related to the fact that unless the > subordinate backends are local, the response to pgaed results has not been > parsed into the connection structure... Yes, much better now. Just one weird case left. Considering the same setup as described above (back null with 2 back ldap glued underneath): a search with pagedResults and a page size of 3 (the exact number of results returned by each back ldap), we get: - a first page with the 3 results from back ldap 1 - a second page with 3 results from back ldap 2 (so far, so good) - but then this last result also has a pagedResults cookie, and the search can go on and on, returning the same 2nd page. Presumably this is related to the patch allowing pagedResults to cross two databases. If the first returns an empty cookie (no more results), a new cookie is added. However, this should not be done if the last database returns no more results. Jonathan

1 0

(ITS#6509) slapo-memberof follow cascading group membership
by sspreitzer＠ch.ibm.com 08 Apr '10

08 Apr '10

Full_Name: Sascha Thomas Spreitzer Version: 2.4.21 OS: Linux RHEL 5.4 ppc64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.212.29.179) Dear openldap developers and maintainers of the memberof feature, it would be great if you could implement a cascading group membership functionality. Like say a group can be part of a group and those members will be listed respectively. Thank you very much in advance, yours sincerely, Sascha Thomas Spreitzer IBM Switzerland - unix engineering Fedora Project Ambassador

1 0

TLS issues
by Daniel Gomes 07 Apr '10

07 Apr '10

Dear list members, I am having some problems with TLS I would like to share and hopefully solve with your help. First of all, the specs: it's a OpenLDAP 2.4.19 compiled (manually, not via apt-get) on a Ubuntu 8.04 (Hardy). I don't think it matters, but I am using the dynlist overlay (that's why I had to compile manually and not via apt-get, as I couldn't get it to work with the package Ubuntu provides). Passing on to the problem itself, let me just start by saying that the SSL/TLS setup itself seems to be working fine, and I am always able to ldapsearch on port 636 with ldaps:// (SSL) or on port 389 with ldap:// and -ZZ (TLS). Unfortunately, using other clients (phpLDAPadmin and some custom php scripts I wrote), the behavior is rather random. Sometimes it fails, sometimes it works (at the beginning it worked more often than not, lately it has been working less and less). The server logs, unfortunately, are not so helpful (for me, at least!). The only error I see (with logs at -1, trying to connect via phpLDAPadmin with TLS on port 389) is: connection_read(15): TLS accept failure error=-1 id=23, closing Apr 7 16:45:18 gold slapd[7385]: connection_closing: readying conn=23 sd=15 for close Apr 7 16:45:18 gold slapd[7385]: connection_close: conn=23 sd=15 Apr 7 16:45:18 gold slapd[7385]: daemon: removing 15 Apr 7 16:45:18 gold slapd[7385]: daemon: activity on 1 descriptor Apr 7 16:45:18 gold slapd[7385]: daemon: activity on: Apr 7 16:45:18 gold slapd[7385]: conn=23 fd=15 closed (TLS negotiation failure) Trying on port 636 with ldaps:// yields the same error. But as I mentioned, it just happen sometimes, while on others the connection is successfully established! Although I did notice that even when it does work, I get the following error: connection_read(14): unable to get TLS client DN, error=49 id=8 but it is quickly followed by a "conn=8 fd=14 TLS established tls_ssf=256 ssf=256"... So, this is my problem and it is getting me quite puzzled... The fact that it does work on occasion makes me think it can't be my configuration or the usual file permission culprit... Here's my slapd.conf (I removed the ACL configuration, as I am guessing it's not important here): # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/dyngroup.schema include /usr/local/etc/openldap/schema/inetorgperson.schema #Custom Schemas include /usr/local/etc/openldap/schema/local.schema include /usr/local/etc/openldap/schema/postfix.schema pidfile /home/slapd/run/slapd.pid argsfile /home/slapd/run/slapd.args ####################################################################### # Database definitions ####################################################################### database hdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw secret directory /home/slapd/database index objectClass eq ####################################################################### # Replication ####################################################################### overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 ####################################################################### # TLS ####################################################################### TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /home/slapd/ssl/cacert.pem TLSCertificateFile /home/slapd/ssl/servercrt.pem TLSCertificateKeyFile /home/slapd/ssl/serverkey.pem TLSVerifyClient never ####################################################################### # Overlay (for dynamic lists) ####################################################################### overlay dynlist dynlist-attrset ipfnRole memberURL member If it helps for anything, in the ldap.conf files of the client I also have the "TLS_REQCERT never" setting, together with the TLS_CACERT and TLS_CACERTDIR for the CA's certificate. Thanks in advance for any help, -- Daniel Gomes (SysAdmin) dgomes(a)ipfn.ist.utl.pt Ext. 3487 - 218419487 Instituto de Plasmas e usão Nuclear Instituto Superior Técnico - UTL Av. Rovisco Pais - 1049-001 Lisboa - Portugal

2 1

(ITS#6508) memberof segmentation fault
by ndunbar＠llnw.com 07 Apr '10

07 Apr '10

Full_Name: Neil Dunbar Version: 2.4.21 OS: Debian 5, Ubuntu 9.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (68.142.115.87) Hi there, It looks like there's a small bug in memberof.c - it only manifests itself when "memberof_dangling" is set to "drop". I think that, while the overlay reduces the a->a_vals and a->a_nvals array by one, to strip out a non-existent DN, it needs to reduce the a->a_numvals variable as well. The end result of this is that if one adds a group which has a mix of members which exist in the DIT, and some which don't, the entry_encode() routing will segfault. [I can only reproduce the segv in back-bdb and back-hdb. back-ldif doesn't seem to exhibit this behaviour]. I've uploaded a tiny slapd.conf and test LDIF file (in ftp://ftp.openldap.org/incoming/memberof-segv-20100407.tar.gz) which is normally enough to trigger the fault. If one starts up slapd via slapd -f mof-slapd.conf -h ldap://localhost -d trace followed by ldapmodify -x -H ldap://localhost -D cn=admin,dc=test -w adminpw -f ldif/test-memberof.ldif one should see an assertion fail in entry_encode() with (i == a->a_numvals) failing. The following patch seems to fix it, but I haven't done real regression testing to see if it rolls other errors. The normal slapd unit tests seem to yield proper results though. ---8<----8<------ --- memberof.c.orig 2010-04-07 16:49:44.000000000 -0700 +++ memberof.c 2010-04-07 16:49:20.000000000 -0700 @@ -580,6 +580,7 @@ sizeof( struct berval ) * ( j - i ) ); } i--; + a->a_numvals--; } } ---8<----8<------ Hope this helps, Neil

1 0

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> Le 06/04/2010 20:55, masarati(a)aero.polimi.it a écrit : >> When requesting paged results control on glued databases, if a database >> (either >> superior or subordinate) returns one page that ends with the last >> corresponding >> entry in that database, the resulting cookie is empty. Thus, the result >> returned to the client corresponds to the final result of a paged >> response. >> However, other databases may have returned data. A fix is being >> designed. p. > > Your fix for this problem works well in my tests. > > Under the same subject, another problem arises: > > Consider this : > - back null > ---- back ldap 1 returning 3 results to a search > ---- back ldap 2 returning 3 results to a search > > And you search "back null" with a page size of 2: > - The first response contains 2 results from "back ldap 1" and a correct > cookie. > - The second response contains 1 result from "back ldap 1" and 1 result > from "back ldap 2", and another correct cookie. > - The third request, however, goes back to "back ldap 1", and returns > the same results as the first response. > - And so on... forever. > > As I mentioned, it seems that to solve this problem we would have to tie > a paged results cookie to a particular backend under glue... Should work now. The issue was related to the fact that unless the subordinate backends are local, the response to pgaed results has not been parsed into the connection structure... p.

1 0

Re: (ITS#6507) backglue and paged results issue
by jonathan＠phillipoux.net 06 Apr '10

06 Apr '10

Le 06/04/2010 20:55, masarati(a)aero.polimi.it a écrit : > When requesting paged results control on glued databases, if a database (either > superior or subordinate) returns one page that ends with the last corresponding > entry in that database, the resulting cookie is empty. Thus, the result > returned to the client corresponds to the final result of a paged response. > However, other databases may have returned data. A fix is being designed. p. Your fix for this problem works well in my tests. Under the same subject, another problem arises: Consider this : - back null ---- back ldap 1 returning 3 results to a search ---- back ldap 2 returning 3 results to a search And you search "back null" with a page size of 2: - The first response contains 2 results from "back ldap 1" and a correct cookie. - The second response contains 1 result from "back ldap 1" and 1 result from "back ldap 2", and another correct cookie. - The third request, however, goes back to "back ldap 1", and returns the same results as the first response. - And so on... forever. As I mentioned, it seems that to solve this problem we would have to tie a paged results cookie to a particular backend under glue... -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by jonathan＠phillipoux.net 06 Apr '10

06 Apr '10

Le 05/04/2010 23:40, masarati(a)aero.polimi.it a écrit : >>> Well, I've just fixed it. When changing database, I modified the paged >>> results control value by setting the page size to pagesize - >>> rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I >>> only have http access. >> >> Speedy patch - thank you! Just tried it out, and it works great for the >> issue I reported. >> >> Testing further shows a limitation in crossing databases though. A >> search that spans over two glued ldap databases, returns n< pagesize >> results from the first, and continues over to the second, returning >> pagesize-n results from it, making pagesize results all together. So >> far, so good. >> >> However, the subsequent search with the returned pagedresults cookie >> just starts a new search over, returning the same set of results. So it >> works fine for one page max. >> >> But it doesn't look simple to solve this issue, unless backglue starts >> recording pagedresults cookies, etc... >> >> Anyway, great improvement on not sending back free'd cookie :-) > > I see the issue, and it seems to be not related to my patch. Don't know > how to fix it (yet). It'll probably need a separate ITS. No, I don't think it is related to your patch. However, it has just appeared, as a result of going one hurdle further thanks to your patch :) I see you opened a separate ITS in #6507. I'll followup there. -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

Re: (ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

A fix is in HEAD; please test. p.

1 0

(ITS#6507) backglue and paged results issue
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.24) Submitted by: ando When requesting paged results control on glued databases, if a database (either superior or subordinate) returns one page that ends with the last corresponding entry in that database, the resulting cookie is empty. Thus, the result returned to the client corresponds to the final result of a paged response. However, other databases may have returned data. A fix is being designed. p.

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

masarati(a)aero.polimi.it wrote: > OK, I've found the problem, and it seems to be a configuration problem. > Please read below. Great. Thanks for taking the time to look at this. > ^^^ An entry with the same DN exists in the superior database. As a > consequence, this entry is returned by back-bdb's tool functions, but > backglue tries to release it using back-perl. Since back-perl does not > have any tool functions, what is considered a safe replacement is used. > Unfortunately, the safe replacement doesn't know how to deal with > read-only entries returned by back-bdb. The solution consists in: > > - temporarily commenting the instance of back-perl > > - removing this entry from your back-bdb > > - re-enabling the instance of back-perl > > A follow-on to this ITS could be to devise a means to detect whether a > superior database contains entries that belong to a subordinate one, and > warn the administrator of the inconsistency. Ah I see. I remember thinking at the time whether or not I needed a DN within my master database too (similar to a FS mount point) but obviously it has been this that has been causing the problem. At least now I know that this isn't the case and can work around it. I'd expect a subordinate database to always override the master (similar to the mount point idea again) but in the case of slapcat then I believe it should probably just ignore a subordinate that doesn't have a physical backing store presence such as back-perl. I'm not sure quite how you'd mark this though. An appropriately worded warning would definitely be a good start, especially as when I first started working with back-perl as a subordinate, I was confused that putting the subordinate definition after the master would always fail whereas putting it before would allow it to work. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

OK, I've found the problem, and it seems to be a configuration problem. Please read below. > Here is the slapd.conf used in the test: > > > # > # See slapd.conf(5) for details on configuration options. > # This file should NOT be world readable. > # > include /home/build/rel-openldap/etc/openldap/schema/core.schema > > # Define global ACLs to disable default read access. > > # Do not enable referrals until AFTER you have a working directory > # service AND an understanding of referrals. > #referral ldap://root.openldap.org > > pidfile /home/build/rel-openldap/var/run/slapd.pid > argsfile /home/build/rel-openldap/var/run/slapd.args > > # Load dynamic backend modules: > # modulepath /home/build/rel-openldap/libexec/openldap > # moduleload back_bdb.la > # moduleload back_hdb.la > # moduleload back_ldap.la > > # Sample security restrictions > # Require integrity protection (prevent hijacking) > # Require 112-bit (3DES or better) encryption for updates > # Require 63-bit encryption for simple bind > # security ssf=1 update_ssf=112 simple_bind=64 > > # Sample access control policy: > # Root DSE: allow anyone to read it > # Subschema (sub)entry DSE: allow anyone to read it > # Other DSEs: > # Allow self write access > # Allow authenticated users read access > # Allow anonymous users to authenticate > # Directives needed to implement policy: > # access to dn.base="" by * read > # access to dn.base="cn=Subschema" by * read > # access to * > # by self write > # by users read > # by anonymous auth > # > # if no access controls are present, the default policy > # allows anyone and everyone to read anything but restricts > # updates to rootdn. (e.g., "access to * by * read") > # > # rootdn can always read and write EVERYTHING! > > database perl > suffix "ou=perl,dc=my-domain,dc=com" ^^ This is the suffix where the instance of back-perl is rooted at > subordinate > perlModulePath /home/build/rel-openldap/etc/openldap > perlModule SampleLDAP > > ####################################################################### > # BDB database definitions > ####################################################################### > > database bdb > suffix "dc=my-domain,dc=com" > rootdn "cn=Manager,dc=my-domain,dc=com" > # Cleartext passwords, especially for the rootdn, should > # be avoid. See slappasswd(8) and slapd.conf(5) for details. > # Use of strong authentication encouraged. > rootpw secret > # The database directory MUST exist prior to running slapd AND > # should only be accessible by the slapd and slap tools. > # Mode 700 recommended. > directory /home/build/rel-openldap/var/openldap-data > # Indices to maintain > index objectClass eq > > > And here is the slapcat output when the perl database is disabled in > slapd.conf to prevent the crash: > > > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > structuralObjectClass: organization > entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120241Z > entryCSN: 20100406120241.310422Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120241Z > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > structuralObjectClass: organizationalUnit > entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120446Z > ou: real > entryCSN: 20100406120458.545769Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120458Z > > dn: ou=perl,dc=my-domain,dc=com ^^^ An entry with the same DN exists in the superior database. As a consequence, this entry is returned by back-bdb's tool functions, but backglue tries to release it using back-perl. Since back-perl does not have any tool functions, what is considered a safe replacement is used. Unfortunately, the safe replacement doesn't know how to deal with read-only entries returned by back-bdb. The solution consists in: - temporarily commenting the instance of back-perl - removing this entry from your back-bdb - re-enabling the instance of back-perl A follow-on to this ITS could be to devise a means to detect whether a superior database contains entries that belong to a subordinate one, and warn the administrator of the inconsistency. p.

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> masarati(a)aero.polimi.it wrote: > >>> *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: >> >> ^^^ this message is not quite informative, nor is what follows below. >> Please read <http://www.openldap.org/faq/data/cache/56.html> carefully, >> and provide the information required. >> >> p. > > Okay. I figured it was easy enough to recreate that I wouldn't need to > build a full debug build myself, but looks like I need to do that > anyway. Also, what is the best way to not get "strip" to be > automatically invoked during "make install"? I ended up temporarily > removing the binary just to get unstripped versions. What about make STRIP="" install ? Apart from the bug you manifest, which should not occur, I'd note that back-perl does not support slaptools, and thus no slaptool'ing should occur when using it. I can't debug this right now because I don't routinely build with back-perl. My guess is that the bug should appear with any other glued backend that does not support tools (but I couldn't reproduce it using back-ldap, for example). A (possible) workaround is to use slapcat -a '(!(entryDN:dnSubtreeMatch:=ou=perl,dc=my-domain,dc=com))' in order to exclude the subtree handled by back-perl. p. > > (gdb) bt full > #0 0x00007f18761dded5 in raise () from /lib/libc.so.6 > No symbol table info available. > #1 0x00007f18761df3f3 in abort () from /lib/libc.so.6 > No symbol table info available. > #2 0x00007f187621a3a8 in ?? () from /lib/libc.so.6 > No symbol table info available. > #3 0x00007f187621f948 in ?? () from /lib/libc.so.6 > No symbol table info available. > #4 0x00007f1876221a56 in free () from /lib/libc.so.6 > No symbol table info available. > #5 0x00007f1877296c52 in ber_memfree_x (p=0xa207b3, ctx=0x0) at > memory.c:152 > __PRETTY_FUNCTION__ = "ber_memfree_x" > #6 0x000000000044f785 in ch_free (ptr=0xa207b3) at ch_malloc.c:139 > ctx = (void *) 0x0 > #7 0x00000000004395e6 in entry_clean (e=0xa0bff8) at entry.c:489 > __PRETTY_FUNCTION__ = "entry_clean" > #8 0x00000000004396ab in entry_free (e=0xa0bff8) at entry.c:514 > No locals. > #9 0x00000000004ae4e4 in glue_entry_release_rw (op=0x7fffe262a540, > e=0xa0bff8, rw=0) at backglue.c:731 > b0 = (BackendDB *) 0x7fffe262a2d0 > rc = -1 > #10 0x00000000004b0952 in overlay_entry_release_ov (op=0x7fffe262a540, > e=0xa0bff8, rw=0, on=0x8997d0) at backover.c:421 > oi = (slap_overinfo *) 0x8995f0 > be = (BackendDB *) 0x89a510 > db = {bd_info = 0x8997d0, bd_self = 0x89a510, be_ctrls = > "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\0' > <repeats 17 times>, "\001", > be_flags = 2328, be_restrictops = 0, be_requires = 0, be_ssf_set = > {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, > sss_update_ssf = 0, > sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, > sss_simple_bind = 0}, be_suffix = 0x899270, be_nsuffix = 0x8992a0, > be_schemadn = {bv_len = 0, > bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn > = {bv_len = 30, bv_val = 0x899570 "cn=Manager,dc=my-domain,dc=com"}, > be_rootndn = {bv_len = 30, > bv_val = 0x8995c0 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = > {bv_len = 6, bv_val = 0x8993b0 "secret"}, be_max_deref_depth = 15, > be_def_limit = { > lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = > 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total > = 0}, be_limits = 0x0, > be_acl = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, > bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8978c0, > be_pcl_mutex = {__data = { > __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, > __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' > <repeats 39 times>, > __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7b8c00, > be_private = 0x898a30, be_next = {stqe_next = 0x0}} > bi = (BackendInfo *) 0x8995f0 > rc = 32768 > #11 0x00000000004b0ab2 in over_entry_release_rw (op=0x7fffe262a540, > e=0xa0bff8, rw=0) at backover.c:463 > oi = (slap_overinfo *) 0x8995f0 > on = (slap_overinst *) 0x8997d0 > __PRETTY_FUNCTION__ = "over_entry_release_rw" > #12 0x000000000043d3cf in be_entry_release_rw (op=0x7fffe262a540, > e=0xa0bff8, rw=0) at backend.c:880 > No locals. > #13 0x00000000004b5c5b in slapcat (argc=1, argv=0x7fffe262a8e8) at > slapcat.c:117 > data = 0xa20c50 "dn: ou=perl,dc=my-domain,dc=com\nobjectClass: > organizationalUnit\nobjectClass: top\nou: perl\nstructuralObjectClass: > organizationalUnit\nentryUUID: > 6438973e-d5c0-102e-9c05-81e0ba1bb1f2\ncreatorsName: cn=Man"... > len = 388 > e = (Entry *) 0xa0bff8 > id = 3 > rc = 0 > op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = > 0x898500, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = > 0, bv_val = 0x0}, > o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = > {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = > 0, bv_val = 0x0}, rb_ssf = 0, > rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = > 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, > rs_increment = 0}, > oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, > rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn > = {bv_len = 0, > bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = > {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = > 0x0, rs_attrsonly = 0, > rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, > bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, > oq_extended = {rs_reqoid = { > bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, > oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, > rs_flags = 0, > rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new > = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, > o_abandon = 0, o_cancel = 0, > o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', > o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', > o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', > o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, > o_controls = 0x0, o_authz = { > sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = > {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, > sai_ssf = 0, > sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = > 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = > 0, bv_val = 0x0}, > o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = > 0x0}} > progname = 0x55fc68 "slapcat" > #14 0x00000000004090d3 in main (argc=1, argv=0x7fffe262a8e8) at main.c:403 > i = 1 > no_detach = 0 > rc = 1 > urls = 0x0 > username = 0x0 > groupname = 0x0 > sandbox = 0x0 > syslogUser = 160 > g_argc = 1 > g_argv = (char **) 0x7fffe262a8e8 > configfile = 0x0 > configdir = 0x0 > serverName = 0x7fffe262c75e "slapcat" > serverMode = 1 > scp = (struct sync_cookie *) 0x0 > scp_entry = (struct sync_cookie *) 0x0 > debug_unknowns = (char **) 0x0 > syslog_unknowns = (char **) 0x0 > serverNamePrefix = 0x54076b "" > l = 4223483 > slapd_pid_file_unlink = 0 > slapd_args_file_unlink = 0 > firstopt = 1 > __PRETTY_FUNCTION__ = "main" > (gdb) > > > HTH, > > Mark. > > -- > Mark Cave-Ayland - Senior Technical Architect > PostgreSQL - PostGIS > Sirius Corporation plc - control through freedom > http://www.siriusit.co.uk > t: +44 870 608 0063 > > Sirius Labs: http://www.siriusit.co.uk/labs >

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

masarati(a)aero.polimi.it wrote: >> *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: > > ^^^ this message is not quite informative, nor is what follows below. > Please read <http://www.openldap.org/faq/data/cache/56.html> carefully, > and provide the information required. > > p. Okay. I figured it was easy enough to recreate that I wouldn't need to build a full debug build myself, but looks like I need to do that anyway. Also, what is the best way to not get "strip" to be automatically invoked during "make install"? I ended up temporarily removing the binary just to get unstripped versions. (gdb) bt full #0 0x00007f18761dded5 in raise () from /lib/libc.so.6 No symbol table info available. #1 0x00007f18761df3f3 in abort () from /lib/libc.so.6 No symbol table info available. #2 0x00007f187621a3a8 in ?? () from /lib/libc.so.6 No symbol table info available. #3 0x00007f187621f948 in ?? () from /lib/libc.so.6 No symbol table info available. #4 0x00007f1876221a56 in free () from /lib/libc.so.6 No symbol table info available. #5 0x00007f1877296c52 in ber_memfree_x (p=0xa207b3, ctx=0x0) at memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #6 0x000000000044f785 in ch_free (ptr=0xa207b3) at ch_malloc.c:139 ctx = (void *) 0x0 #7 0x00000000004395e6 in entry_clean (e=0xa0bff8) at entry.c:489 __PRETTY_FUNCTION__ = "entry_clean" #8 0x00000000004396ab in entry_free (e=0xa0bff8) at entry.c:514 No locals. #9 0x00000000004ae4e4 in glue_entry_release_rw (op=0x7fffe262a540, e=0xa0bff8, rw=0) at backglue.c:731 b0 = (BackendDB *) 0x7fffe262a2d0 rc = -1 #10 0x00000000004b0952 in overlay_entry_release_ov (op=0x7fffe262a540, e=0xa0bff8, rw=0, on=0x8997d0) at backover.c:421 oi = (slap_overinfo *) 0x8995f0 be = (BackendDB *) 0x89a510 db = {bd_info = 0x8997d0, bd_self = 0x89a510, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\0' <repeats 17 times>, "\001", be_flags = 2328, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x899270, be_nsuffix = 0x8992a0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 30, bv_val = 0x899570 "cn=Manager,dc=my-domain,dc=com"}, be_rootndn = {bv_len = 30, bv_val = 0x8995c0 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0x8993b0 "secret"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x8978c0, be_pcl_mutex = {__data = { __lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\0' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7b8c00, be_private = 0x898a30, be_next = {stqe_next = 0x0}} bi = (BackendInfo *) 0x8995f0 rc = 32768 #11 0x00000000004b0ab2 in over_entry_release_rw (op=0x7fffe262a540, e=0xa0bff8, rw=0) at backover.c:463 oi = (slap_overinfo *) 0x8995f0 on = (slap_overinst *) 0x8997d0 __PRETTY_FUNCTION__ = "over_entry_release_rw" #12 0x000000000043d3cf in be_entry_release_rw (op=0x7fffe262a540, e=0xa0bff8, rw=0) at backend.c:880 No locals. #13 0x00000000004b5c5b in slapcat (argc=1, argv=0x7fffe262a8e8) at slapcat.c:117 data = 0xa20c50 "dn: ou=perl,dc=my-domain,dc=com\nobjectClass: organizationalUnit\nobjectClass: top\nou: perl\nstructuralObjectClass: organizationalUnit\nentryUUID: 6438973e-d5c0-102e-9c05-81e0ba1bb1f2\ncreatorsName: cn=Man"... len = 388 e = (Entry *) 0xa0bff8 id = 3 rc = 0 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x898500, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = { bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = { sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} progname = 0x55fc68 "slapcat" #14 0x00000000004090d3 in main (argc=1, argv=0x7fffe262a8e8) at main.c:403 i = 1 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 g_argc = 1 g_argv = (char **) 0x7fffe262a8e8 configfile = 0x0 configdir = 0x0 serverName = 0x7fffe262c75e "slapcat" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x54076b "" l = 4223483 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __PRETTY_FUNCTION__ = "main" (gdb) HTH, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> masarati(a)aero.polimi.it wrote: > >> ^^^ I think the culprit is here. No point in tracking down further this >> issue unless you re-link as recommended by this message. >> >> p. > > Sorry - I experienced the error on a production box running Debian > packages, and re-built from source on my local machine just to confirm > the bug still exists. However, my local machine already has other LDAP > libraries installed which seems to have resulted in some of the wrong > libraries being picked up at compile time. > > I've now removed all pre-built openldap packages, re-built again from > source and can confirm that the bug still stands since the > "ldap_int_global_options" warning has now disappeared: > > > zeno:/home/build/rel-openldap# ./sbin/slapcat > Here in new > Posix Var 8192 and 4096 > bdb_db_open: database "dc=my-domain,dc=com": unclean shutdown detected; > attempting recovery. > bdb_db_open: warning - no DB_CONFIG file found in directory > /home/build/rel-openldap/var/openldap-data: (2). > Expect poor performance for suffix "dc=my-domain,dc=com". > bdb_db_open: database "dc=my-domain,dc=com": recovery skipped in > read-only mode. Run manual recovery if errors are encountered. > bdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > structuralObjectClass: organization > entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120241Z > entryCSN: 20100406120241.310422Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120241Z > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > structuralObjectClass: organizationalUnit > entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120446Z > ou: real > entryCSN: 20100406120458.545769Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120458Z > > *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: ^^^ this message is not quite informative, nor is what follows below. Please read <http://www.openldap.org/faq/data/cache/56.html> carefully, and provide the information required. p. > 0x00000000009c4fd3 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7f4ea6fd0948] > /lib/libc.so.6(cfree+0x76)[0x7f4ea6fd2a56] > ./sbin/slapcat[0x42c11d] > ./sbin/slapcat[0x42c1c9] > ./sbin/slapcat[0x481448] > ./sbin/slapcat[0x484c93] > ./sbin/slapcat[0x4874b9] > ./sbin/slapcat[0x408d40] > /lib/libc.so.6(__libc_start_main+0xe6)[0x7f4ea6f7b1a6] > ./sbin/slapcat[0x4087d9] > > > Many thanks, > > Mark. > > -- > Mark Cave-Ayland - Senior Technical Architect > PostgreSQL - PostGIS > Sirius Corporation plc - control through freedom > http://www.siriusit.co.uk > t: +44 870 608 0063 > > Sirius Labs: http://www.siriusit.co.uk/labs >

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

masarati(a)aero.polimi.it wrote: > ^^^ I think the culprit is here. No point in tracking down further this > issue unless you re-link as recommended by this message. > > p. Sorry - I experienced the error on a production box running Debian packages, and re-built from source on my local machine just to confirm the bug still exists. However, my local machine already has other LDAP libraries installed which seems to have resulted in some of the wrong libraries being picked up at compile time. I've now removed all pre-built openldap packages, re-built again from source and can confirm that the bug still stands since the "ldap_int_global_options" warning has now disappeared: zeno:/home/build/rel-openldap# ./sbin/slapcat Here in new Posix Var 8192 and 4096 bdb_db_open: database "dc=my-domain,dc=com": unclean shutdown detected; attempting recovery. bdb_db_open: warning - no DB_CONFIG file found in directory /home/build/rel-openldap/var/openldap-data: (2). Expect poor performance for suffix "dc=my-domain,dc=com". bdb_db_open: database "dc=my-domain,dc=com": recovery skipped in read-only mode. Run manual recovery if errors are encountered. bdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: 0x00000000009c4fd3 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f4ea6fd0948] /lib/libc.so.6(cfree+0x76)[0x7f4ea6fd2a56] ./sbin/slapcat[0x42c11d] ./sbin/slapcat[0x42c1c9] ./sbin/slapcat[0x481448] ./sbin/slapcat[0x484c93] ./sbin/slapcat[0x4874b9] ./sbin/slapcat[0x408d40] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f4ea6f7b1a6] ./sbin/slapcat[0x4087d9] Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by masarati＠aero.polimi.it 06 Apr '10

06 Apr '10

> Full_Name: Mark Cave-Ayland > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.187.123.11) > > > Hi there, > > Having implemented a custom perl module as a subordinate with back-perl, > we've > found a segfault when using slapcat to dump the database. The backtrace > looks > like this: > > > zeno:/home/build/rel-openldap# ./sbin/slapcat > ./sbin/slapcat: Symbol `ldap_int_global_options' has different size in > shared > object, consider re-linking ^^^ I think the culprit is here. No point in tracking down further this issue unless you re-link as recommended by this message. p. > Here in new > Posix Var 8192 and 4096 > bdb_db_open: warning - no DB_CONFIG file found in directory > /home/build/rel-openldap/var/openldap-data: (2). > Expect poor performance for suffix "dc=my-domain,dc=com". > bdb_monitor_db_open: monitoring disabled; configure monitor database to > enable > dn: dc=my-domain,dc=com > objectClass: top > objectClass: dcObject > objectClass: organization > o:: bXlkb21haW4uY29tIA== > dc: my-domain > structuralObjectClass: organization > entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120241Z > entryCSN: 20100406120241.310422Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120241Z > > dn: ou=real,dc=my-domain,dc=com > objectClass: organizationalUnit > objectClass: top > structuralObjectClass: organizationalUnit > entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 > creatorsName: cn=Manager,dc=my-domain,dc=com > createTimestamp: 20100406120446Z > ou: real > entryCSN: 20100406120458.545769Z#000000#000#000000 > modifiersName: cn=Manager,dc=my-domain,dc=com > modifyTimestamp: 20100406120458Z > > *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: > 0x00000000009c5063 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7f1adc150948] > /lib/libc.so.6(cfree+0x76)[0x7f1adc152a56] > ./sbin/slapcat[0x42c11d] > ./sbin/slapcat[0x42c1c9] > ./sbin/slapcat[0x481448] > ./sbin/slapcat[0x484c93] > ./sbin/slapcat[0x4874b9] > ./sbin/slapcat[0x408d40] > /lib/libc.so.6(__libc_start_main+0xe6)[0x7f1adc0fb1a6] > ./sbin/slapcat[0x4087d9] > > > Looks like an invalid pointer is being deferenced when running slapcat. > > > ATB, > > Mark. > > >

1 0

Re: (ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

Here is the slapd.conf used in the test: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /home/build/rel-openldap/etc/openldap/schema/core.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /home/build/rel-openldap/var/run/slapd.pid argsfile /home/build/rel-openldap/var/run/slapd.args # Load dynamic backend modules: # modulepath /home/build/rel-openldap/libexec/openldap # moduleload back_bdb.la # moduleload back_hdb.la # moduleload back_ldap.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! database perl suffix "ou=perl,dc=my-domain,dc=com" subordinate perlModulePath /home/build/rel-openldap/etc/openldap perlModule SampleLDAP ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /home/build/rel-openldap/var/openldap-data # Indices to maintain index objectClass eq And here is the slapcat output when the perl database is disabled in slapd.conf to prevent the crash: dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z dn: ou=perl,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top ou: perl structuralObjectClass: organizationalUnit entryUUID: 6438973e-d5c0-102e-9c05-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120509Z entryCSN: 20100406120509.555750Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120509Z ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

1 0

(ITS#6506) Use of back-perl in slapd.conf in subordinate database causes slapcat to segfault
by mark.cave-ayland＠siriusit.co.uk 06 Apr '10

06 Apr '10

Full_Name: Mark Cave-Ayland Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.187.123.11) Hi there, Having implemented a custom perl module as a subordinate with back-perl, we've found a segfault when using slapcat to dump the database. The backtrace looks like this: zeno:/home/build/rel-openldap# ./sbin/slapcat ./sbin/slapcat: Symbol `ldap_int_global_options' has different size in shared object, consider re-linking Here in new Posix Var 8192 and 4096 bdb_db_open: warning - no DB_CONFIG file found in directory /home/build/rel-openldap/var/openldap-data: (2). Expect poor performance for suffix "dc=my-domain,dc=com". bdb_monitor_db_open: monitoring disabled; configure monitor database to enable dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject objectClass: organization o:: bXlkb21haW4uY29tIA== dc: my-domain structuralObjectClass: organization entryUUID: 0bdc2650-d5c0-102e-9fe7-3350c645132d creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120241Z entryCSN: 20100406120241.310422Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120241Z dn: ou=real,dc=my-domain,dc=com objectClass: organizationalUnit objectClass: top structuralObjectClass: organizationalUnit entryUUID: 5644fb04-d5c0-102e-9c04-81e0ba1bb1f2 creatorsName: cn=Manager,dc=my-domain,dc=com createTimestamp: 20100406120446Z ou: real entryCSN: 20100406120458.545769Z#000000#000#000000 modifiersName: cn=Manager,dc=my-domain,dc=com modifyTimestamp: 20100406120458Z *** glibc detected *** ./sbin/slapcat: free(): invalid pointer: 0x00000000009c5063 *** ======= Backtrace: ========= /lib/libc.so.6[0x7f1adc150948] /lib/libc.so.6(cfree+0x76)[0x7f1adc152a56] ./sbin/slapcat[0x42c11d] ./sbin/slapcat[0x42c1c9] ./sbin/slapcat[0x481448] ./sbin/slapcat[0x484c93] ./sbin/slapcat[0x4874b9] ./sbin/slapcat[0x408d40] /lib/libc.so.6(__libc_start_main+0xe6)[0x7f1adc0fb1a6] ./sbin/slapcat[0x4087d9] Looks like an invalid pointer is being deferenced when running slapcat. ATB, Mark.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 05 Apr '10

05 Apr '10

>> Well, I've just fixed it. When changing database, I modified the paged >> results control value by setting the page size to pagesize - >> rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I >> only have http access. > > Speedy patch - thank you! Just tried it out, and it works great for the > issue I reported. > > Testing further shows a limitation in crossing databases though. A > search that spans over two glued ldap databases, returns n < pagesize > results from the first, and continues over to the second, returning > pagesize-n results from it, making pagesize results all together. So > far, so good. > > However, the subsequent search with the returned pagedresults cookie > just starts a new search over, returning the same set of results. So it > works fine for one page max. > > But it doesn't look simple to solve this issue, unless backglue starts > recording pagedresults cookies, etc... > > Anyway, great improvement on not sending back free'd cookie :-) I see the issue, and it seems to be not related to my patch. Don't know how to fix it (yet). It'll probably need a separate ITS. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by jonathan＠phillipoux.net 05 Apr '10

05 Apr '10

Le 02/04/2010 06:44, masarati(a)aero.polimi.it a écrit : >> masarati(a)aero.polimi.it wrote: >>>> masarati(a)aero.polimi.it wrote: >>>>>> Also, I note that the glued paged response seems to work incorrectly. >>>>>> I >>>>>> made a simple test system, where the root database contains exactly >>>>>> one >>>>>> entry (the suffix) and a back-ldap is glued on top. If I request >>>>>> entries >>>>>> with a page size of 2, searching the suffix return 3 entries; >>>>>> subsequent >>>>>> searches return 2 entries from the proxy. I haven't figured out yet >>>>>> where >>>>>> the issue is. >>>>> >>>>> I figured out how to fix the issue you reported. It is related to the >>>>> fact that slapd internally assumes that ldctl_oid values are constant >>>>> strings, so it doesn't duplicate nor free them. However, control OIDs >>>>> returned by back-ldap (and friends) have been decoded from the wire by >>>>> the >>>>> client library, so they are actually malloc'ed. That's why backglue >>>>> ends >>>>> up with a dangling pointer. >>>>> >>>>> I'm fixing it by having backglue duplicate (and free) control OIDs >>>>> consistently. Another option would be to replace those values with >>>>> constant strings for known control values. This would prevent gluing >>>>> for >>>>> unknown proxied controls. >>>> >>>> Or just tmpalloc them and don't bother to clean them up. >>> >>> Yes, I've reworked all the temporary controls allocation using tmpalloc. >>> Too bad OIDs are char* and not bervals. >>> >>> With respect to the other issue, to honor the requested pagesize we'd >>> need >>> to intercept pagedresult requests, modify the page size in the request >>> when a page crosses two databases, requesting the original page size >>> minus >>> entries already returned. I wonder whether it's worth the effort, >>> though. >> >> IMO pagedresults should be a (global) overlay, and backends shouldn't do >> anything about it. Note that the sssvlv overlay already intercepts >> pagedresults, it's impossible to handle things correctly otherwise. > > Well, I've just fixed it. When changing database, I modified the paged > results control value by setting the page size to pagesize - > rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I > only have http access. Speedy patch - thank you! Just tried it out, and it works great for the issue I reported. Testing further shows a limitation in crossing databases though. A search that spans over two glued ldap databases, returns n < pagesize results from the first, and continues over to the second, returning pagesize-n results from it, making pagesize results all together. So far, so good. However, the subsequent search with the returned pagedresults cookie just starts a new search over, returning the same set of results. So it works fine for one page max. But it doesn't look simple to solve this issue, unless backglue starts recording pagedresults cookies, etc... Anyway, great improvement on not sending back free'd cookie :-) -- -------------------------------------------------------------- Jonathan Clarke - jonathan(a)phillipoux.net -------------------------------------------------------------- Ldap Synchronization Connector (LSC) - http://lsc-project.org --------------------------------------------------------------

1 0

RE: (ITS#6505) ldap_search_* functions missing const qualifiers
by EHASZLA＠transunion.com 05 Apr '10

05 Apr '10

>From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] > >> hmm... I'm not quite sure how to attach a file to a ticket through the >> web interface, > >In general, upload to ftp.openldap.org according to contribution >instructions, and post a message with the URL; the way you provided it >makes it pretty unusable. Fwiw, I uploaded the two patches as ehaszla-ldap.h-20100405.patch and ehaszla-search.c-20100405.patch eric

1 0

RE: (ITS#6505) ldap_search_* functions missing const qualifiers
by masarati＠aero.polimi.it 05 Apr '10

05 Apr '10

> Anyway, if the change doesn't get accepted it won't be the end of the > world, but obviously I'm hoping you find the above convincing. Just to clarify: if I were to design the API from scratch, I'd CONST those args... so I agree with your suggestion. p.

1 0

RE: (ITS#6505) ldap_search_* functions missing const qualifiers
by EHASZLA＠transunion.com 04 Apr '10

04 Apr '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CAD483.E1DB174F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- >From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] >In general, upload to ftp.openldap.org according to contribution >instructions, and post a message with the URL; the way you provided it >makes it pretty unusable. I saw the instructions about using the ftp site some time after I sent = the patches. Sorry. The patch was just the obvious, mechanical change to add const to the attrs parameter in the functions that have it. Maybe a reminder to keep reading the rest of the page in the section on "patches" would be helpful. I got to the part that started talking = about attribution of large changes, and assumed the rest of the page wasn't relevant to what I was trying to do. >However, I think your patch will not be considered, although in = principle >perfectly acceptable, because an API change of this type would probably >break a lot of code out there, without significant advantages. Well, a couple of observations: 1) At least one other ldap implementation already does this. 2) I consider being able to turn on the compiler warnings that tell you = about parameters that might be changed when do don't expect them to be = a significant advantage. For many of the source trees I've worked on, = doing so (and treating warnings as errors, to force them to be fixed)=20 has helped uncover a variety of bugs. 3) If you're not being pedantic about warnings, and causing them to be=20 treated as errors, this API change just results in an extra warning,=20 which wouldn't actually break any code. 4) Adding "const" effectively and simply documents the fact that those=20 parameters aren't going to be changed. If the API doesn't say so, it would be nice if that was at least explicitly mentions in the man = page. At the moment, I had to go read an analyze the ldap code to figure that out. I'd rather spend my time working on my own code instead, = and be able to simply use the great library you guys have created. :) Anyway, if the change doesn't get accepted it won't be the end of the world, but obviously I'm hoping you find the above convincing. eric ------_=_NextPart_001_01CAD483.E1DB174F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>RE: (ITS#6505) ldap_search_* functions missing const = qualifiers</TITLE> </HEAD> <BODY>  -----Original Message----- >From: masarati(a)aero.polimi.it [<A = HREF=3D"mailto:masarati@aero.polimi.it">mailto:masarati@aero.polimi.it</A= >] >In general, upload to ftp.openldap.org according to contribution >instructions, and post a message with the URL; the way you provided = it >makes it pretty unusable.   I saw the instructions about using the ftp site some time after I = sent the patches.  Sorry.  The patch was just the obvious, = mechanical change to add const to the attrs parameter in the functions that have it. Maybe a reminder to keep reading the rest of the page in the section = on "patches" would be helpful.  I got to the part that = started talking about attribution of large changes, and assumed the rest of the page = wasn't relevant to what I was trying to do. >However, I think your patch will not be considered, although in = principle >perfectly acceptable, because an API change of this type would = probably >break a lot of code out there, without significant advantages. Well, a couple of observations:  1) At least one other ldap implementation already does this.  2) I consider being able to turn on the compiler warnings that = tell you   about parameters that might be changed when do don't expect them = to be   a significant advantage.  For many of the source trees I've = worked on,   doing so (and treating warnings as errors, to force them to be = fixed)   has helped uncover a variety of bugs.  3) If you're not being pedantic about warnings, and causing them = to be   treated as errors, this API change just results in an extra = warning,   which wouldn't actually break any code.  4) Adding "const" effectively and simply documents the = fact that those   parameters aren't going to be changed.  If the API doesn't = say so, it   would be nice if that was at least explicitly mentions in the man = page.   At the moment, I had to go read an analyze the ldap code to = figure   that out.  I'd rather spend my time working on my own code = instead, and   be able to simply use the great library you guys have created. = :) Anyway, if the change doesn't get accepted it won't be the end of = the  world, but obviously I'm hoping you find the above convincing. eric </BODY> </HTML> ------_=_NextPart_001_01CAD483.E1DB174F--

1 0

Re: (ITS#6505) ldap_search_* functions missing const qualifiers
by masarati＠aero.polimi.it 02 Apr '10

02 Apr '10

> hmm... I'm not quite sure how to attach a file to a ticket through the > web interface, In general, upload to ftp.openldap.org according to contribution instructions, and post a message with the URL; the way you provided it makes it pretty unusable. However, I think your patch will not be considered, although in principle perfectly acceptable, because an API change of this type would probably break a lot of code out there, without significant advantages. p.

1 0

Re: (ITS#6505) ldap_search_* functions missing const qualifiers
by EHASZLA＠transunion.com 02 Apr '10

02 Apr '10

hmm... I'm not quite sure how to attach a file to a ticket through the web interface, so I'm just going to paste the patches in here: --- ldap.h.1.349.orig 2010-04-02 15:32:34.113126200 -0500 +++ ldap.h 2010-04-02 15:33:55.252793400 -0500 @@ -1841,7 +1841,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **serverctrls, LDAPControl **clientctrls, @@ -1855,7 +1855,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **serverctrls, LDAPControl **clientctrls, @@ -1870,7 +1870,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly )); =20 LDAP_F( int ) @@ -1879,7 +1879,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPMessage **res )); =20 @@ -1889,7 +1889,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, struct timeval *timeout, LDAPMessage **res )); --- search.c.1.88.orig 2010-04-02 15:26:34.268550800 -0500 +++ search.c 2010-04-02 15:32:36.939198200 -0500 @@ -47,7 +47,7 @@ * attrsonly 1 =3D> attributes only 0 =3D> attributes and values * * Example: - * char *attrs[] =3D { "mail", "title", 0 }; + * const char *attrs[] =3D { "mail", "title", 0 }; * ldap_search_ext( ld, "dc=3Dexample,dc=3Dcom", LDAP_SCOPE_SUBTREE, "cn~=3Dbob", * attrs, attrsonly, sctrls, ctrls, timeout, sizelimit, * &msgid ); @@ -58,7 +58,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -76,7 +76,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -139,7 +139,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -157,7 +157,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -210,14 +210,14 @@ * attrsonly 1 =3D> attributes only 0 =3D> attributes and values * * Example: - * char *attrs[] =3D { "mail", "title", 0 }; + * const char *attrs[] =3D { "mail", "title", 0 }; * msgid =3D ldap_search( ld, "dc=3Dexample,dc=3Dcom", LDAP_SCOPE_SUBTREE, "cn~=3Dbob", * attrs, attrsonly ); */ int ldap_search( LDAP *ld, LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, int attrsonly ) + LDAP_CONST char **attrs, int attrsonly ) { BerElement *ber; ber_int_t id; @@ -246,7 +246,7 @@ LDAP_CONST char *base, ber_int_t scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, ber_int_t attrsonly, LDAPControl **sctrls, LDAPControl **cctrls, @@ -390,7 +390,7 @@ int ldap_search_st( LDAP *ld, LDAP_CONST char *base, int scope, - LDAP_CONST char *filter, char **attrs, + LDAP_CONST char *filter, LDAP_CONST char **attrs, int attrsonly, struct timeval *timeout, LDAPMessage **res ) { int msgid; @@ -419,7 +419,7 @@ LDAP_CONST char *base, int scope, LDAP_CONST char *filter, - char **attrs, + LDAP_CONST char **attrs, int attrsonly, LDAPMessage **res ) {

1 0

(ITS#6505) ldap_search_* functions missing const qualifiers
by ehaszla＠transunion.com 02 Apr '10

02 Apr '10

Full_Name: Eric Haszlakiewicz Version: cvsweb OS: RHEL5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.106.254.66) The ldap_search_ext, ldap_search_ext_s, ldap_search, ldap_search_s and ldap_search_st functions should use const for the attrs parameter. I checked revision 1.88 of libraries/libldap/search.c and it appears that those strings do not get modified so there is no reason that a list of string constants couldn't be passed in. I have a short patch that changes libraries/libldap/search.c and include/ldap.h (rev 1.349) to add the const qualifier.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> masarati(a)aero.polimi.it wrote: >>> masarati(a)aero.polimi.it wrote: >>>>> Also, I note that the glued paged response seems to work incorrectly. >>>>> I >>>>> made a simple test system, where the root database contains exactly >>>>> one >>>>> entry (the suffix) and a back-ldap is glued on top. If I request >>>>> entries >>>>> with a page size of 2, searching the suffix return 3 entries; >>>>> subsequent >>>>> searches return 2 entries from the proxy. I haven't figured out yet >>>>> where >>>>> the issue is. >>>> >>>> I figured out how to fix the issue you reported. It is related to the >>>> fact that slapd internally assumes that ldctl_oid values are constant >>>> strings, so it doesn't duplicate nor free them. However, control OIDs >>>> returned by back-ldap (and friends) have been decoded from the wire by >>>> the >>>> client library, so they are actually malloc'ed. That's why backglue >>>> ends >>>> up with a dangling pointer. >>>> >>>> I'm fixing it by having backglue duplicate (and free) control OIDs >>>> consistently. Another option would be to replace those values with >>>> constant strings for known control values. This would prevent gluing >>>> for >>>> unknown proxied controls. >>> >>> Or just tmpalloc them and don't bother to clean them up. >> >> Yes, I've reworked all the temporary controls allocation using tmpalloc. >> Too bad OIDs are char* and not bervals. >> >> With respect to the other issue, to honor the requested pagesize we'd >> need >> to intercept pagedresult requests, modify the page size in the request >> when a page crosses two databases, requesting the original page size >> minus >> entries already returned. I wonder whether it's worth the effort, >> though. > > IMO pagedresults should be a (global) overlay, and backends shouldn't do > anything about it. Note that the sssvlv overlay already intercepts > pagedresults, it's impossible to handle things correctly otherwise. Well, I've just fixed it. When changing database, I modified the paged results control value by setting the page size to pagesize - rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I only have http access. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by hyc＠symas.com 01 Apr '10

01 Apr '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >>>> Also, I note that the glued paged response seems to work incorrectly. >>>> I >>>> made a simple test system, where the root database contains exactly one >>>> entry (the suffix) and a back-ldap is glued on top. If I request >>>> entries >>>> with a page size of 2, searching the suffix return 3 entries; >>>> subsequent >>>> searches return 2 entries from the proxy. I haven't figured out yet >>>> where >>>> the issue is. >>> >>> I figured out how to fix the issue you reported. It is related to the >>> fact that slapd internally assumes that ldctl_oid values are constant >>> strings, so it doesn't duplicate nor free them. However, control OIDs >>> returned by back-ldap (and friends) have been decoded from the wire by >>> the >>> client library, so they are actually malloc'ed. That's why backglue >>> ends >>> up with a dangling pointer. >>> >>> I'm fixing it by having backglue duplicate (and free) control OIDs >>> consistently. Another option would be to replace those values with >>> constant strings for known control values. This would prevent gluing >>> for >>> unknown proxied controls. >> >> Or just tmpalloc them and don't bother to clean them up. > > Yes, I've reworked all the temporary controls allocation using tmpalloc. > Too bad OIDs are char* and not bervals. > > With respect to the other issue, to honor the requested pagesize we'd need > to intercept pagedresult requests, modify the page size in the request > when a page crosses two databases, requesting the original page size minus > entries already returned. I wonder whether it's worth the effort, though. IMO pagedresults should be a (global) overlay, and backends shouldn't do anything about it. Note that the sssvlv overlay already intercepts pagedresults, it's impossible to handle things correctly otherwise. -- -- 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#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> masarati(a)aero.polimi.it wrote: >>> Also, I note that the glued paged response seems to work incorrectly. >>> I >>> made a simple test system, where the root database contains exactly one >>> entry (the suffix) and a back-ldap is glued on top. If I request >>> entries >>> with a page size of 2, searching the suffix return 3 entries; >>> subsequent >>> searches return 2 entries from the proxy. I haven't figured out yet >>> where >>> the issue is. >> >> I figured out how to fix the issue you reported. It is related to the >> fact that slapd internally assumes that ldctl_oid values are constant >> strings, so it doesn't duplicate nor free them. However, control OIDs >> returned by back-ldap (and friends) have been decoded from the wire by >> the >> client library, so they are actually malloc'ed. That's why backglue >> ends >> up with a dangling pointer. >> >> I'm fixing it by having backglue duplicate (and free) control OIDs >> consistently. Another option would be to replace those values with >> constant strings for known control values. This would prevent gluing >> for >> unknown proxied controls. > > Or just tmpalloc them and don't bother to clean them up. Yes, I've reworked all the temporary controls allocation using tmpalloc. Too bad OIDs are char* and not bervals. With respect to the other issue, to honor the requested pagesize we'd need to intercept pagedresult requests, modify the page size in the request when a page crosses two databases, requesting the original page size minus entries already returned. I wonder whether it's worth the effort, though. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by hyc＠symas.com 01 Apr '10

01 Apr '10

masarati(a)aero.polimi.it wrote: >> Also, I note that the glued paged response seems to work incorrectly. I >> made a simple test system, where the root database contains exactly one >> entry (the suffix) and a back-ldap is glued on top. If I request entries >> with a page size of 2, searching the suffix return 3 entries; subsequent >> searches return 2 entries from the proxy. I haven't figured out yet where >> the issue is. > > I figured out how to fix the issue you reported. It is related to the > fact that slapd internally assumes that ldctl_oid values are constant > strings, so it doesn't duplicate nor free them. However, control OIDs > returned by back-ldap (and friends) have been decoded from the wire by the > client library, so they are actually malloc'ed. That's why backglue ends > up with a dangling pointer. > > I'm fixing it by having backglue duplicate (and free) control OIDs > consistently. Another option would be to replace those values with > constant strings for known control values. This would prevent gluing for > unknown proxied controls. Or just tmpalloc them and don't bother to clean them up. -- -- 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#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> Also, I note that the glued paged response seems to work incorrectly. I > made a simple test system, where the root database contains exactly one > entry (the suffix) and a back-ldap is glued on top. If I request entries > with a page size of 2, searching the suffix return 3 entries; subsequent > searches return 2 entries from the proxy. I haven't figured out yet where > the issue is. I figured out how to fix the issue you reported. It is related to the fact that slapd internally assumes that ldctl_oid values are constant strings, so it doesn't duplicate nor free them. However, control OIDs returned by back-ldap (and friends) have been decoded from the wire by the client library, so they are actually malloc'ed. That's why backglue ends up with a dangling pointer. I'm fixing it by having backglue duplicate (and free) control OIDs consistently. Another option would be to replace those values with constant strings for known control values. This would prevent gluing for unknown proxied controls. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

>> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.57.67.241) >> >> >> This is similar to ITS #5191 (http://www.openldap.org/its/?findid=5191), >> except >> it happens with a subordinate LDAP database. >> >> Consider this configuration : >> 8<--------------------------------------- >> database ldap >> suffix "o=test,o=sub" >> uri "ldap://localhost:1234" >> subordinate >> idassert-bind mode=none bindmethod=simple flags=prescriptive timeout=0 >> network-timeout=0 binddn="cn=svc,o=test" credentials="verysecret" >> idassert-authzFrom dn.regex:.* >> single-conn yes >> >> overlay rwm >> rwm-suffixmassage "o=test,o=sub" "o=test" >> >> database null >> suffix "o=sub" >> rootdn "cn=Manager,o=sub" >> rootpw secret >> overlay glue >> 8<--------------------------------------- >> >> A search with pagedResults control returns results as expected, but with >> a >> response control containing some garbage: >> >> result: 0 Success >> control:: >> qOEpCDg0MC4xMTM1NTYuMS40LjMxOSBmYWxzZSBNSVFBQUFBSkFnRUFCQVFFQUFBQQ== >> >> Some gdb'ing shows that backglue copies over the pointers to >> rs->sr_ctrls >> into >> glue_state->ctrls. But then, back-ldap's ldap_back_search does a >> ldap_controls_free() on rs->sr_ctrls. And so, the returned control >> contains >> garbage (mostly). >> >> I haven't been able to come up with a patch yet, just commenting line >> 454 >> of >> back-ldap/search.c works. Running out of time for now... >> >> > > Probably, backglue should rather ldap_controls_dup() them. However, in > this case we need to make sure that the glued databases delete their own > copy. Also, I note that the glued paged response seems to work incorrectly. I made a simple test system, where the root database contains exactly one entry (the suffix) and a back-ldap is glued on top. If I request entries with a page size of 2, searching the suffix return 3 entries; subsequent searches return 2 entries from the proxy. I haven't figured out yet where the issue is. p.

1 0

Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by masarati＠aero.polimi.it 01 Apr '10

01 Apr '10

> Full_Name: Jonathan Clarke > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.57.67.241) > > > This is similar to ITS #5191 (http://www.openldap.org/its/?findid=5191), > except > it happens with a subordinate LDAP database. > > Consider this configuration : > 8<--------------------------------------- > database ldap > suffix "o=test,o=sub" > uri "ldap://localhost:1234" > subordinate > idassert-bind mode=none bindmethod=simple flags=prescriptive timeout=0 > network-timeout=0 binddn="cn=svc,o=test" credentials="verysecret" > idassert-authzFrom dn.regex:.* > single-conn yes > > overlay rwm > rwm-suffixmassage "o=test,o=sub" "o=test" > > database null > suffix "o=sub" > rootdn "cn=Manager,o=sub" > rootpw secret > overlay glue > 8<--------------------------------------- > > A search with pagedResults control returns results as expected, but with a > response control containing some garbage: > > result: 0 Success > control:: > qOEpCDg0MC4xMTM1NTYuMS40LjMxOSBmYWxzZSBNSVFBQUFBSkFnRUFCQVFFQUFBQQ== > > Some gdb'ing shows that backglue copies over the pointers to rs->sr_ctrls > into > glue_state->ctrls. But then, back-ldap's ldap_back_search does a > ldap_controls_free() on rs->sr_ctrls. And so, the returned control > contains > garbage (mostly). > > I haven't been able to come up with a patch yet, just commenting line 454 > of > back-ldap/search.c works. Running out of time for now... > > Probably, backglue should rather ldap_controls_dup() them. However, in this case we need to make sure that the glued databases delete their own copy. p.

1 0

LDAP bind using ldap_sasl_interactive_bind_s and DIGEST-MD5 fails the second time
by James Bong 01 Apr '10

01 Apr '10

I am currently using Mac OS X 10.6.2 and am attempting to use the ldap_sasl_interactive_bind_s API to do a digest-md5 authentication against Active Directory (2008, though I don't think it matters what flavor of AD is used). The bind works fine the first time. However, if I unbind and attempt to rebind as the same user, it fails with ldap_sasl_interactive_bind_s: Invalid credentials (49). If I bind with a different user, then unbind, and bind as the original user, it works. I created a simple program that illustrates the issue. When run, it binds correctly, unbinds, and then fails on the second bind: trying ldap_sasl_interactive_bind_s callback callback done ldap_sasl_interactive_bind_s Done Unbinding Unbound. ldap_sasl_interactive_bind_s callback callback done ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0904D1, comment: AcceptSecurityContext error, data 57, v1772 Any idea why it is not possible to use the same credentials twice? Here is the test program. I tried reinitializing the sasl library with sasl_done and sasl_client_init, but that doesn't seem to make a difference. #include <ldap.h> #include <sasl/sasl.h> #include <stdio.h> typedef struct sasl_defaults { char *mech; char *realm; char *authcid; char *passwd; char *authzid; } sasl_defaults; int callback(LDAP *ld, unsigned flags, void* defaults, void *interact ) { printf("callback\n"); sasl_interact_t *in_out=(sasl_interact_t *)interact; sasl_defaults *in_defaults=(sasl_defaults *)defaults; while (in_out->id !=SASL_CB_LIST_END) { switch (in_out->id) { case SASL_CB_USER: in_out->result=in_defaults->authcid; in_out->len=strlen(in_defaults->authcid); break; case SASL_CB_AUTHNAME: in_out->result=in_defaults->authcid; in_out->len=strlen(in_defaults->authcid); break; case SASL_CB_PASS: in_out->result=in_defaults->passwd; in_out->len=strlen(in_defaults->passwd); break; case SASL_CB_GETREALM: in_out->result=""; in_out->len=strlen(""); break; } in_out++; } printf("callback done\n"); return 0; } int main (int argv, char ** argc) { printf("trying\n"); for (;;) { LDAP *ld; ldap_initialize(&ld, "ldap://dc.ad.domain.com:389"); ldap_set_option(ld,LDAP_OPT_REFERRALS,LDAP_OPT_OFF); int version=3; ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &version ); int timelimit=5; if (ldap_set_option( ld, LDAP_OPT_TIMELIMIT, (void *) &timelimit ) != LDAP_OPT_SUCCESS ) { printf("err\n"); return -1; } sasl_defaults defaults; defaults.mech = "DIGEST-MD5"; defaults.passwd="password"; defaults.authcid="user"; defaults.realm="realm.com"; defaults.authzid="user"; printf("ldap_sasl_interactive_bind_s\n"); int rc=ldap_sasl_interactive_bind_s( ld, NULL,defaults.mech, NULL, NULL, LDAP_SASL_QUIET, callback, &defaults ); if( rc != LDAP_SUCCESS ) { ldap_perror( ld, "ldap_sasl_interactive_bind_s" ); ldap_unbind(ld); return -1; } printf("ldap_sasl_interactive_bind_s Done\n"); printf("Unbinding\n"); ldap_unbind(ld); printf("Unbound.\n"); sleep(5); } }

2 1

(ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
by jonathan＠phillipoux.net 01 Apr '10

01 Apr '10

Full_Name: Jonathan Clarke Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.57.67.241) This is similar to ITS #5191 (http://www.openldap.org/its/?findid=5191), except it happens with a subordinate LDAP database. Consider this configuration : 8<--------------------------------------- database ldap suffix "o=test,o=sub" uri "ldap://localhost:1234" subordinate idassert-bind mode=none bindmethod=simple flags=prescriptive timeout=0 network-timeout=0 binddn="cn=svc,o=test" credentials="verysecret" idassert-authzFrom dn.regex:.* single-conn yes overlay rwm rwm-suffixmassage "o=test,o=sub" "o=test" database null suffix "o=sub" rootdn "cn=Manager,o=sub" rootpw secret overlay glue 8<--------------------------------------- A search with pagedResults control returns results as expected, but with a response control containing some garbage: result: 0 Success control:: qOEpCDg0MC4xMTM1NTYuMS40LjMxOSBmYWxzZSBNSVFBQUFBSkFnRUFCQVFFQUFBQQ== Some gdb'ing shows that backglue copies over the pointers to rs->sr_ctrls into glue_state->ctrls. But then, back-ldap's ldap_back_search does a ldap_controls_free() on rs->sr_ctrls. And so, the returned control contains garbage (mostly). I haven't been able to come up with a patch yet, just commenting line 454 of back-ldap/search.c works. Running out of time for now...

1 0

RE: (ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by bcolston＠xtec.com 01 Apr '10

01 Apr '10

Provider slapd configuration (partial): serverID 000 database bdb suffix "dc=authentx" rootdn "SUPPRESSED" rootpw SUPPRESSED directory /authentx/db/ldap/authentx-sync1 overlay syncprov syncprov-checkpoint 100 15 syncprov-sessionlog 5000 checkpoint 128 20 index objectClass eq,pres index entryCSN,entryUUID eq cachesize 100000 dncachesize 200000 idlcachesize 1000 sizelimit 500000 timelimit 36000 Consumer slapd configuration (partial): serverID 001 database bdb suffix "dc=authentx" rootdn "SUPPRESSED" rootpw SUPPRESSED directory /authentx/db/ldap/authentx-sync2 syncrepl rid=001 provider=ldap://localhost:3891 type=refreshAndPersist retry="300 60 60 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="SUPPRESSED" credentials="SUPPRESSED" checkpoint 128 20 index objectClass eq,pres index entryCSN,entryUUID eq cachesize 100000 dncachesize 200000 idlcachesize 1000 sizelimit 500000 timelimit 36000 Barry -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Wednesday, March 31, 2010 9:17 PM To: bcolston(a)xtec.com Cc: openldap-its(a)openldap.org Subject: Re: (ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.21 > OS: Fedora 12 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.255.208.210) > > > When a consumer slapd is started, if the provider slapd has had only Add > operations performed while the consumer slapd was down, the provider slapd sends > the consumer slapd the entryUUIDs of all records in the provider database. > Note: this is not a list of all records that have been added/changed/deleted > since the previous synchronization based on the consumer's contextCSN, it is a > list of all records in the LDAP database (for some of our customers, this is > 10,000,000 entryUUIDs that are returned to the consumer slapd.) That is the normal behavior of syncrepl. Read the Admin Guide and/or RFC4533. > The scenario to reproduce this problem is: > 1. Start provider slapd > 2. Start consumer slapd > 3. Ensure that provider contextCSN matches consumer contextCSN > 4. Shutdown consumer slapd > 5. Add records to provider slapd (1 record is sufficient to create the problem) > 6. Start consumer slapd with debug turned on (so the messages being sent can be > viewed). The consumer slapd receives 1 to N LDAP_RES_INTERMEDIATE SYNC_ID_SETs > (message type = 121) containing the entryUUIDs of the records in the provider's > database, followed by a LDAP_RES_SEARCH_ENTRY, LDAP_SYNC_ADD (message type = > 100) message for each record added to the provider, then finally a > LDAP_RES_INTERMEDIATE, REFRESH_PRESENT message (message type = 121) message > containing the provider's sync cookie. > > I am running OpenLDAP 2.4.21 with Berkeley 4.6.21 (with all patches) on Fedora > 12. Running sync replication in RefreshAndPersist mode. > > Note: if at least 1 Modify or Delete operation is performed against the provider > slapd while the consumer slapd is down, when the consumer slapd is started, the > provider slapd does NOT send the Sync ID sets containing the entryUUIDs of all > records in the provider database. Using the syncprov_sessionlog can allow the provider to shortcut this. Since you haven't show any details of your configuration, we can't say if this difference in behavior is a bug or a config error. -- -- 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#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by hyc＠symas.com 31 Mar '10

31 Mar '10

bcolston(a)xtec.com wrote: > Full_Name: Barry Colston > Version: 2.4.21 > OS: Fedora 12 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.255.208.210) > > > When a consumer slapd is started, if the provider slapd has had only Add > operations performed while the consumer slapd was down, the provider slapd sends > the consumer slapd the entryUUIDs of all records in the provider database. > Note: this is not a list of all records that have been added/changed/deleted > since the previous synchronization based on the consumer's contextCSN, it is a > list of all records in the LDAP database (for some of our customers, this is > 10,000,000 entryUUIDs that are returned to the consumer slapd.) That is the normal behavior of syncrepl. Read the Admin Guide and/or RFC4533. > The scenario to reproduce this problem is: > 1. Start provider slapd > 2. Start consumer slapd > 3. Ensure that provider contextCSN matches consumer contextCSN > 4. Shutdown consumer slapd > 5. Add records to provider slapd (1 record is sufficient to create the problem) > 6. Start consumer slapd with debug turned on (so the messages being sent can be > viewed). The consumer slapd receives 1 to N LDAP_RES_INTERMEDIATE SYNC_ID_SETs > (message type = 121) containing the entryUUIDs of the records in the provider's > database, followed by a LDAP_RES_SEARCH_ENTRY, LDAP_SYNC_ADD (message type = > 100) message for each record added to the provider, then finally a > LDAP_RES_INTERMEDIATE, REFRESH_PRESENT message (message type = 121) message > containing the provider's sync cookie. > > I am running OpenLDAP 2.4.21 with Berkeley 4.6.21 (with all patches) on Fedora > 12. Running sync replication in RefreshAndPersist mode. > > Note: if at least 1 Modify or Delete operation is performed against the provider > slapd while the consumer slapd is down, when the consumer slapd is started, the > provider slapd does NOT send the Sync ID sets containing the entryUUIDs of all > records in the provider database. Using the syncprov_sessionlog can allow the provider to shortcut this. Since you haven't show any details of your configuration, we can't say if this difference in behavior is a bug or a config error. -- -- 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#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by bcolston＠xtec.com 31 Mar '10

31 Mar '10

Full_Name: Barry Colston Version: 2.4.21 OS: Fedora 12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.255.208.210) When a consumer slapd is started, if the provider slapd has had only Add operations performed while the consumer slapd was down, the provider slapd sends the consumer slapd the entryUUIDs of all records in the provider database. Note: this is not a list of all records that have been added/changed/deleted since the previous synchronization based on the consumer's contextCSN, it is a list of all records in the LDAP database (for some of our customers, this is 10,000,000 entryUUIDs that are returned to the consumer slapd.) The scenario to reproduce this problem is: 1. Start provider slapd 2. Start consumer slapd 3. Ensure that provider contextCSN matches consumer contextCSN 4. Shutdown consumer slapd 5. Add records to provider slapd (1 record is sufficient to create the problem) 6. Start consumer slapd with debug turned on (so the messages being sent can be viewed). The consumer slapd receives 1 to N LDAP_RES_INTERMEDIATE SYNC_ID_SETs (message type = 121) containing the entryUUIDs of the records in the provider's database, followed by a LDAP_RES_SEARCH_ENTRY, LDAP_SYNC_ADD (message type = 100) message for each record added to the provider, then finally a LDAP_RES_INTERMEDIATE, REFRESH_PRESENT message (message type = 121) message containing the provider's sync cookie. I am running OpenLDAP 2.4.21 with Berkeley 4.6.21 (with all patches) on Fedora 12. Running sync replication in RefreshAndPersist mode. Note: if at least 1 Modify or Delete operation is performed against the provider slapd while the consumer slapd is down, when the consumer slapd is started, the provider slapd does NOT send the Sync ID sets containing the entryUUIDs of all records in the provider database.

1 0

Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org 31 Mar '10

31 Mar '10

Hi, any word on if this can be incorporated? Thanks. On Sun, 2010-03-07 at 01:24 +0000, openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6488. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6488) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6488) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6488 > > Please remember to retain your issue tracking number (ITS#6488) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

1 0

Re: (ITS#6501) DBTzeros in bdb/hdb
by hyc＠symas.com 30 Mar '10

30 Mar '10

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.4, HEAD > OS: any > URL: > Submission from: (NULL) (76.88.107.46) > > > The lockobj's in BDB aren't being DBTzero()'d fully before use; they > consist of more than just .data and .size, so this leaves uninit > memory that gets branched on. > > Needs to be applied to HEAD and 2.4. (2.3 as well, for those still > tracking that for some reason, probably all branches with BDB/HDB) Thanks, fixed in HEAD. The dn2id.c patch is obsolete, that function is no longer used. > > Patch vs HEAD: > > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v > retrieving revision 1.214 > diff -u -u -r1.214 cache.c > --- cache.c 4 Nov 2009 05:09:51 -0000 1.214 > +++ cache.c 29 Mar 2010 16:41:59 -0000 > @@ -184,6 +184,7 @@ > > if ( !lock ) return 0; > > + DBTzero(&lockobj ); > lockobj.data =&ei->bei_id; > lockobj.size = sizeof(ei->bei_id) + 1; > > @@ -225,6 +226,7 @@ > else > db_rw = DB_LOCK_READ; > > + DBTzero(&lockobj ); > lockobj.data =&ei->bei_id; > lockobj.size = sizeof(ei->bei_id) + 1; > > Index: dn2id.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/dn2id.c,v > retrieving revision 1.169 > diff -u -u -r1.169 dn2id.c > --- dn2id.c 15 Feb 2010 14:25:47 -0000 1.169 > +++ dn2id.c 29 Mar 2010 16:41:59 -0000 > @@ -42,6 +42,7 @@ > else > db_rw = DB_LOCK_READ; > > + DBTzero(&lockobj ); > lockobj.data = dn->bv_val; > lockobj.size = dn->bv_len; > > -- -- 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#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by masarati＠aero.polimi.it 30 Mar '10

30 Mar '10

> On Tue, 2010-03-02 at 15:30 +1100, Andrew Bartlett wrote: >> On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: >> > [Resending because I forgot the ITS number in the subject] >> > >> > I have a simple prototype that on add/modrdn populates/maintains an >> > attribute (rdnValue) with the distinguished values of the naming >> > attributes of the RDN. While doing this, it also checks for >> uniqueness of >> > the rdnValue value within siblings. >> > >> > You can find it here >> > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.c> >> > >> > Please test and comment. I hope it does what intended. >> >> I'm starting to look at this now. I'm sorry so many months have past >> since you posted it. > > I've now added it into Samba's provision, and using the diff I attach, > against current 'master', I get the attached error. > > It seems to be unable to add the base DN. (The very first entry in the > database). Try this: <www.aero.polimi.it/masarati/Download/pierangelo-masarati-2010-03-30-rdnval.…>. In fact, when adding the suffix entry, the overlay was erroneously checking its siblings from its superior, which is very likely to fail. p.

1 0

Re: (ITS#6500) get_ldap_property returns stale data from time to time
by alinachegalati＠yahoo.com 30 Mar '10

30 Mar '10

--0-808694875-1269950414=:35747 Content-Type: text/plain; charset=us-ascii i was using the deprecated function from openldap. i switched to ldap_value_free_len, i'll run more tests to see if i still have the problem. ________________________________ From: "masarati(a)aero.polimi.it" <masarati(a)aero.polimi.it> To: alinachegalati(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Tue, March 30, 2010 7:15:51 AM Subject: Re: (ITS#6500) get_ldap_property returns stale data from time to time Not clear why you think this is an OpenLDAP bug. There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.17) > > > Hi, > > In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > 30 if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > > char ** v = ldap_get_values(ldap, entry, attribute); > > if ( v != NULL && v[0] != NULL ) { > char* ret = apr_pstrdup(context, v[0] ); > ldap_value_free( v ); > return ret; > } > > return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin > --0-808694875-1269950414=:35747 Content-Type: text/html; charset=us-ascii <html><head><style type="text/css"></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div> </div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">i was using the deprecated function from openldap. i switched to ldap_value_free_len, i'll run more tests to see if  i still have the problem. <div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><hr size="1">From: "masarati(a)aero.polimi.it" <masarati(a)aero.polimi.it> To: alinachegalati(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Tue, March 30, 2010 7:15:51 AM Subject: Re: (ITS#6500) get_ldap_property returns stale data from time to time Not clear why you think this is an OpenLDAP bug.  There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: <a href="ftp://ftp.openldap.org/incoming/" target="_blank">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (194.237.142.17) > > > Hi, > >  In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0  0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) >    at ldap_query.c:30 > 30          if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0  0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) >    at ldap_query.c:30 > #1  0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > >    char ** v = ldap_get_values(ldap, entry, attribute); > >    if ( v != NULL && v[0] != NULL ) { >        char* ret = apr_pstrdup(context,  v[0] ); >        ldap_value_free( v ); >        return ret; >    } > >    return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin > </div></div> </div> </body></html> --0-808694875-1269950414=:35747--

1 0

Re: (ITS#6502) Build failure tls_g.c
by hyc＠symas.com 30 Mar '10

30 Mar '10

This is a dup of ITS#5930 (and probably a few others). Solaris ships with a prehistoric version of GnuTLS (even before they added version stamps to the gnutls.h header file). You cannot use it. Use OpenSSL or install a recent version of GnuTLS instead. kenneth.greiner(a)paetec.com wrote: > Full_Name: Ken Greiner > Version: 2.4.21 > OS: SunOS 5.10 Generic_141445-09 i86pc i386 i86pc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.80.108.55) > > > ./configure --disable-slapd --prefix=$HOME > OK > ./make depend > OK > ./make > ... lots of good stuff.. then -> > > /bin/sh ../../libtool --mode=compile gcc -g -O2 -I../../include > -I../../include -DLDAP_LIBRARY -c tls_g.c > gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC > -DPIC -o .libs/tls_g.o > tls_g.c:73: error: syntax error before "gnutls_kx_algorithm_t" > tls_g.c:73: warning: no semicolon at end of struct or union > tls_g.c:74: warning: data definition has no type or storage class > tls_g.c:75: error: syntax error before "mac" > tls_g.c:75: warning: data definition has no type or storage class > .. and so on. > oops! Failed on this tls_g.c file. > > -- -- 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#6500) get_ldap_property returns stale data from time to time
by masarati＠aero.polimi.it 29 Mar '10

29 Mar '10

Not clear why you think this is an OpenLDAP bug. There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.17) > > > Hi, > > In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > 30 if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > > char ** v = ldap_get_values(ldap, entry, attribute); > > if ( v != NULL && v[0] != NULL ) { > char* ret = apr_pstrdup(context, v[0] ); > ldap_value_free( v ); > return ret; > } > > return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin >

1 0

(ITS#6502) Build failure tls_g.c
by kenneth.greiner＠paetec.com 29 Mar '10

29 Mar '10

Full_Name: Ken Greiner Version: 2.4.21 OS: SunOS 5.10 Generic_141445-09 i86pc i386 i86pc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.80.108.55) ./configure --disable-slapd --prefix=$HOME OK ./make depend OK ./make ... lots of good stuff.. then -> /bin/sh ../../libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC -DPIC -o .libs/tls_g.o tls_g.c:73: error: syntax error before "gnutls_kx_algorithm_t" tls_g.c:73: warning: no semicolon at end of struct or union tls_g.c:74: warning: data definition has no type or storage class tls_g.c:75: error: syntax error before "mac" tls_g.c:75: warning: data definition has no type or storage class .. and so on. oops! Failed on this tls_g.c file.

1 0

(ITS#6501) DBTzeros in bdb/hdb
by mbackes＠symas.com 29 Mar '10

29 Mar '10

Full_Name: Matthew Backes Version: 2.4, HEAD OS: any URL: Submission from: (NULL) (76.88.107.46) The lockobj's in BDB aren't being DBTzero()'d fully before use; they consist of more than just .data and .size, so this leaves uninit memory that gets branched on. Needs to be applied to HEAD and 2.4. (2.3 as well, for those still tracking that for some reason, probably all branches with BDB/HDB) Patch vs HEAD: =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v retrieving revision 1.214 diff -u -u -r1.214 cache.c --- cache.c 4 Nov 2009 05:09:51 -0000 1.214 +++ cache.c 29 Mar 2010 16:41:59 -0000 @@ -184,6 +184,7 @@ if ( !lock ) return 0; + DBTzero( &lockobj ); lockobj.data = &ei->bei_id; lockobj.size = sizeof(ei->bei_id) + 1; @@ -225,6 +226,7 @@ else db_rw = DB_LOCK_READ; + DBTzero( &lockobj ); lockobj.data = &ei->bei_id; lockobj.size = sizeof(ei->bei_id) + 1; Index: dn2id.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/dn2id.c,v retrieving revision 1.169 diff -u -u -r1.169 dn2id.c --- dn2id.c 15 Feb 2010 14:25:47 -0000 1.169 +++ dn2id.c 29 Mar 2010 16:41:59 -0000 @@ -42,6 +42,7 @@ else db_rw = DB_LOCK_READ; + DBTzero( &lockobj ); lockobj.data = dn->bv_val; lockobj.size = dn->bv_len;

1 0

(ITS#6500) get_ldap_property returns stale data from time to time
by alinachegalati＠yahoo.com 29 Mar '10

29 Mar '10

Full_Name: Alin Vasile Version: 2.4.19 OS: SuSE 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.17) Hi, In a high load apache environment I am performing some ldap searches for some requests using a custom developed application and the OpenLdap client libraries. >From time to time I have the following segmentation fault: Program terminated with signal 11, Segmentation fault. #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, entry=0x841160, attribute=0x87aa50 "smIMEI", context=0x76fc38) at ldap_query.c:30 30 if ( v != NULL && v[0] != NULL ) { (gdb) backtrace #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, entry=0x841160, attribute=0x87aa50 "smIMEI", context=0x76fc38) at ldap_query.c:30 #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, ldap_request=0x76ff60) at ldap_query.c:353 And the function is : char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, apr_pool_t* context) { char ** v = ldap_get_values(ldap, entry, attribute); if ( v != NULL && v[0] != NULL ) { char* ret = apr_pstrdup(context, v[0] ); ldap_value_free( v ); return ret; } return NULL; } Note that most of the queries (99%) work fine. Did anyone experienced something simmilar? Thanks, Alin

1 0

Re: (ITS#6490) dds and pcache overlays not checking NULL value
by etienne.bagnoud＠irovision.ch 29 Mar '10

29 Mar '10

--Sig_/_7pgY/8RXQkx3sc0s2ymL2R Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I've tested dds and it seems fine to me. Thanks. --Sig_/_7pgY/8RXQkx3sc0s2ymL2R Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJLsH3qAAoJEMFfL/bTFBa43e8P/A2TTN5sAFs8x6G7W2mKq/UA R3UcfP0gH1IfxW8eM6ZkIxgi+hI9f0fPEZf1j9KgC4baKsof50jeKBKrx3+iholH oItObH9D2feLIJL3cd+mYyS0mYZOhmD5KtS2cwLwlpgK3HS5crZJYrV0rPctD/xR kCmFcSpX3+KsQaksEqPHMN6Tac3N600yiBs6L9WF5L4Vor1eAVUh10qomr0SVeQ2 zpw8IZBMhUjnn88tJJSWy96Ig0gUeUpKym0jJg8Nsh7AlSd4FpSUKOMjmfSwpfNT VFFTOb7KulyMdvFipZbJ02t5Pgw05zJKfucsGje57YTWUdW2AtpF/sFrh48ULo0x u/cdI2P8NH5ht7VnLVZkYp70vT93G6Jg14RmMGv1Nl6Qsv2S4dNxMo73En8Prwwk RbuEtFcvUNPDXUaB6IATSi4JcLTTFaTZJkKqTlJHB/pVaFUDLLtdIYdWJnOJMb8L PemlIgVU9l9W83WQMmaGoHOdK7EW9TLHeew0uhsP8hoJIydqYIhWO9iyhkdhVV9Q Z9TrN3D1MElanEU4ljMt9QyBHO6IuwW61PsLAjgN+a3H46DWVDhReJa7/27nwGfg PI8YzlDWmaBjsBCFxwu2ppTCsEQy7SOBesTy+Tx5++aZFO/lmPZT8scbfBK4I+O0 gCQitsPuhA5DwP6UMDKG =r9DC -----END PGP SIGNATURE----- --Sig_/_7pgY/8RXQkx3sc0s2ymL2R--

1 0

Re: (ITS#6497) Infinite loop in translucent.c
by ondrej.kuznik＠acision.com 29 Mar '10

29 Mar '10

masarati(a)aero.polimi.it wrote: > The committed patch already contains this change. Please test and report. > > Thanks, p. Sorry, I have only limited and indirect access to CVS because it runs a port blocked by our proxies so I didn't notice how you carried out the change. Meanwhile I have tested the patch and everything looks fine. Hope you reconsider the switch to git as it would (among other things) allow people like us to pull directly. Thanks, Ondra This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: (ITS#6497) Infinite loop in translucent.c
by masarati＠aero.polimi.it 26 Mar '10

26 Mar '10

> --------------000706010609000308080803 > Content-Type: text/plain; charset="ISO-8859-15" > Content-Transfer-Encoding: 7bit > > masarati(a)aero.polimi.it wrote: >> Fixed in HEAD; please test. Thanks, p. > > The patch works, however gcc with "-Wall -pedantic" complains that > according to C standards, behaviour of line like this is undefined. > > For maximum portability, it is probably best to increment "i" > individually instead, as seen in the attached patch. I apologise for the > inconvenience of patching a tiny bug like this in two stages. The committed patch already contains this change. Please test and report. Thanks, p.

1 0

(ITS#6247)
by daniel＠pluta.biz 26 Mar '10

26 Mar '10

Hi, I've uploaded a new patch implementing the specifications from http://www.ietf.org/id/draft-pluta-ldap-srv-side-current-time-match-00.txt The code compiles and runs against todays "HEAD". The patch can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-100325.patch Best regards Daniel

1 0

Re: (ITS#6499) ftp.openldap.org: no space left on device
by Kurt＠OpenLDAP.org 25 Mar '10

25 Mar '10

On Mar 25, 2010, at 4:36 PM, daniel(a)pluta.biz wrote: > Full_Name: Daniel Pluta > Version: - > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.64.112.2) > > > Connected to www.openldap.org. > > 150 Opening ASCII mode data connection for 'firstname-lastname-date.patch'. > 452 Error writing to file: No space left on device. > > 39730 bytes sent in 0.02 secs (2197.7 kB/s) Fixed. Thanks, Kurt

1 0

(ITS#6499) ftp.openldap.org: no space left on device
by daniel＠pluta.biz 25 Mar '10

25 Mar '10

Full_Name: Daniel Pluta Version: - OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.64.112.2) Connected to www.openldap.org. 150 Opening ASCII mode data connection for 'firstname-lastname-date.patch'. 452 Error writing to file: No space left on device. 39730 bytes sent in 0.02 secs (2197.7 kB/s)

1 0

Re: (ITS#6497) Infinite loop in translucent.c
by ondrej.kuznik＠acision.com 25 Mar '10

25 Mar '10

--------------000706010609000308080803 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit masarati(a)aero.polimi.it wrote: > Fixed in HEAD; please test. Thanks, p. The patch works, however gcc with "-Wall -pedantic" complains that according to C standards, behaviour of line like this is undefined. For maximum portability, it is probably best to increment "i" individually instead, as seen in the attached patch. I apologise for the inconvenience of patching a tiny bug like this in two stages. Ondrej Kuznik This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. --------------000706010609000308080803 Content-Type: text/x-patch; name="fix.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="fix.diff" Content-Description: fix.diff Index: openldap-2.4.20/servers/slapd/overlays/translucent.c =================================================================== --- openldap-2.4.20.orig/servers/slapd/overlays/translucent.c 2010-03-25 14:38:21.000000000 +0100 +++ openldap-2.4.20/servers/slapd/overlays/translucent.c 2010-03-25 14:38:38.000000000 +0100 @@ -205,7 +205,8 @@ i = c->valx; ch_free( (*an)[i].an_name.bv_val ); do { - (*an)[i] = (*an)[++i]; + (*an)[i] = (*an)[i+1]; + i++; } while ( !BER_BVISNULL( &(*an)[i].an_name )); } return 0; --------------000706010609000308080803--

1 0

Re: (ITS#6478) slapd crashes with segfault
by wolfgang.hummel＠hp.com 25 Mar '10

25 Mar '10

We managed to install it with debug-symbols now, but did not have a new crash (yet). However we did a deeper anaylysis of existing crashes. Here is the outcome: GNU gdb Red Hat Linux (6.5-25.el5rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar= e welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread= _db library "/lib64/libthread_db.so.1". Reading symbols from /usr/lib64/libltdl.so.3...done. Loaded symbols for /usr/lib64/libltdl.so.3 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libuuid.so.1...done. Loaded symbols for /lib64/libuuid.so.1 Reading symbols from /usr/lib64/libslapd_db-4.7.so...done. Loaded symbols for /usr/lib64/libslapd_db-4.7.so Reading symbols from /usr/lib64/libodbc.so.1...done. Loaded symbols for /usr/lib64/libodbc.so.1 Reading symbols from /usr/lib64/libsasl2.so.2...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /lib64/libssl.so.6...done. Loaded symbols for /lib64/libssl.so.6 Reading symbols from /lib64/libcrypto.so.6...done. Loaded symbols for /lib64/libcrypto.so.6 Reading symbols from /lib64/libcrypt.so.1...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libresolv.so.2...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libpthread.so.0...done. Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libwrap.so.0...done. Loaded symbols for /usr/lib64/libwrap.so.0 Reading symbols from /lib64/libc.so.6...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 Reading symbols from /usr/lib64/libkrb5.so.3...done. Loaded symbols for /usr/lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /usr/lib64/libk5crypto.so.3...done. Loaded symbols for /usr/lib64/libk5crypto.so.3 Reading symbols from /usr/lib64/libz.so.1...done. Loaded symbols for /usr/lib64/libz.so.1 Reading symbols from /lib64/libnsl.so.1...done. Loaded symbols for /lib64/libnsl.so.1 Reading symbols from /usr/lib64/libkrb5support.so.0...done. Loaded symbols for /usr/lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libsepol.so.1...done. Loaded symbols for /lib64/libsepol.so.1 Reading symbols from /lib64/libnss_dns.so.2...done. Loaded symbols for /lib64/libnss_dns.so.2 Reading symbols from /lib64/libnss_files.so.2...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /usr/lib64/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib64/sasl2/libplain.so.2 Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 Reading symbols from /usr/lib64/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 Reading symbols from /usr/lib64/openldap/syncprov-2.4.so.2...Reading symbol= s from /usr/lib/debug/usr/lib64/openldap/syncprov-2.4.so.2.5.4.debug...done= . done. Loaded symbols for /usr/lib64/openldap/syncprov-2.4.so.2 Reading symbols from /usr/lib64/openldap/cms_template-2.4.so.2...Reading sy= mbols from /usr/lib/debug/usr/lib64/openldap/cms_template-2.4.so.2.5.4.debu= g...done. done. Loaded symbols for /usr/lib64/openldap/cms_template-2.4.so.2 Reading symbols from /usr/lib64/openldap/cms_modif-2.4.so.2...Reading symbo= ls from /usr/lib/debug/usr/lib64/openldap/cms_modif-2.4.so.2.5.4.debug...do= ne. done. Loaded symbols for /usr/lib64/openldap/cms_modif-2.4.so.2 Reading symbols from /lib64/libgcc_s.so.1...done. Loaded symbols for /lib64/libgcc_s.so.1 Core was generated by `/usr/sbin/slapd -h ldap:/// -u ldap'. Program terminated with signal 6, Aborted. #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 10 (process 12403): #0 0x00000037a5a075a5 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000043402c in slapd_daemon () at ../../../servers/slapd/daemon.= c:2834 #2 0x0000000000420d75 in main (argc=3D5, argv=3D0x7fff57a47818) at ../../.= ./servers/slapd/main.c:953 Thread 9 (process 12406): #0 0x00000037a5a0a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/lib= pthread.so.0 #1 0x00000000005302bd in ldap_int_thread_pool_wrapper (xpool=3D<value opti= mized out>) at ../../../libraries/libldap_r/tpool.c:712 #2 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 Thread 8 (process 12407): #0 0x00000037a5a0a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/lib= pthread.so.0 #1 0x00000000005302bd in ldap_int_thread_pool_wrapper (xpool=3D<value opti= mized out>) at ../../../libraries/libldap_r/tpool.c:712 #2 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 Thread 7 (process 12408): #0 0x00000037a5a0a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/lib= pthread.so.0 #1 0x00000000005302bd in ldap_int_thread_pool_wrapper (xpool=3D<value opti= mized out>) at ../../../libraries/libldap_r/tpool.c:712 #2 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 Thread 6 (process 12409): #0 0x00000037a5a0a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/lib= pthread.so.0 #1 0x00000000005302bd in ldap_int_thread_pool_wrapper (xpool=3D<value opti= mized out>) at ../../../libraries/libldap_r/tpool.c:712 #2 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 Thread 5 (process 12410): #0 0x00000037a5a0a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/lib= pthread.so.0 #1 0x00000000005302bd in ldap_int_thread_pool_wrapper (xpool=3D<value opti= mized out>) at ../../../libraries/libldap_r/tpool.c:712 #2 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 Thread 4 (process 12411): #0 0x00000037a5a0a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/lib= pthread.so.0 #1 0x00000000005302bd in ldap_int_thread_pool_wrapper (xpool=3D<value opti= mized out>) at ../../../libraries/libldap_r/tpool.c:712 #2 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 Thread 3 (process 12412): #0 0x00000037a4eda178 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x00000037a4e73c07 in _L_lock_14089 () from /lib64/libc.so.6 #2 0x00000037a4e72a61 in free () from /lib64/libc.so.6 #3 0x0000000000438a99 in connection2anonymous (c=3D0x2af6540b0a50) at ../.= ./../servers/slapd/connection.c:563 #4 0x0000000000438df3 in connection_close (c=3D0x2af6540b0a50) at ../../..= /servers/slapd/connection.c:616 #5 0x0000000000439c50 in connection_operation (ctx=3D0x44e17db0, arg_v=3D<= value optimized out>) at ../../../servers/slapd/connection.c:1159 #6 0x000000000043a201 in connection_read_thread (ctx=3D0x44e17db0, argv=3D= <value optimized out>) at ../../../servers/slapd/connection.c:1440 #7 0x0000000000530268 in ldap_int_thread_pool_wrapper (xpool=3D0x16fafc80)= at ../../../libraries/libldap_r/tpool.c:700 #8 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #9 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 Thread 2 (process 12413): #0 0x00000037a5a0a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/lib= pthread.so.0 #1 0x00000000005302bd in ldap_int_thread_pool_wrapper (xpool=3D<value opti= mized out>) at ../../../libraries/libldap_r/tpool.c:712 #2 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #3 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 Thread 1 (process 12405): #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 #3 0x00000037a4e6da07 in malloc_consolidate () from /lib64/libc.so.6 #4 0x00000037a4e6f1fb in _int_free () from /lib64/libc.so.6 #5 0x00000037a4e72a6c in free () from /lib64/libc.so.6 #6 0x00000037a4ecabda in __vsyslog_chk () from /lib64/libc.so.6 #7 0x00000037a4ecaf33 in __syslog_chk () from /lib64/libc.so.6 #8 0x0000000000437869 in slapd_daemon_task (ptr=3D<value optimized out>) a= t ../../../servers/slapd/daemon.c:2771 #9 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #10 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 (gdb) thread 3 [Switching to thread 3 (process 12412)]#0 0x00000037a4eda178 in __lll_mute= x_lock_wait () from /lib64/libc.so.6 (gdb) bt #0 0x00000037a4eda178 in __lll_mutex_lock_wait () from /lib64/libc.so.6 #1 0x00000037a4e73c07 in _L_lock_14089 () from /lib64/libc.so.6 #2 0x00000037a4e72a61 in free () from /lib64/libc.so.6 #3 0x0000000000438a99 in connection2anonymous (c=3D0x2af6540b0a50) at ../.= ./../servers/slapd/connection.c:563 #4 0x0000000000438df3 in connection_close (c=3D0x2af6540b0a50) at ../../..= /servers/slapd/connection.c:616 #5 0x0000000000439c50 in connection_operation (ctx=3D0x44e17db0, arg_v=3D<= value optimized out>) at ../../../servers/slapd/connection.c:1159 #6 0x000000000043a201 in connection_read_thread (ctx=3D0x44e17db0, argv=3D= <value optimized out>) at ../../../servers/slapd/connection.c:1440 #7 0x0000000000530268 in ldap_int_thread_pool_wrapper (xpool=3D0x16fafc80)= at ../../../libraries/libldap_r/tpool.c:700 #8 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #9 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 (gdb) fr 3 #3 0x0000000000438a99 in connection2anonymous (c=3D0x2af6540b0a50) at ../.= ./../servers/slapd/connection.c:563 563 if ( !BER_BVISNULL( &c->c_authmech ) ) { (gdb) p * 0x2af6540b0a50 $1 =3D 3 (gdb) thread 1 [Switching to thread 1 (process 12405)]#0 0x00000037a4e30045 in raise () f= rom /lib64/libc.so.6 (gdb) bt #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 #3 0x00000037a4e6da07 in malloc_consolidate () from /lib64/libc.so.6 #4 0x00000037a4e6f1fb in _int_free () from /lib64/libc.so.6 #5 0x00000037a4e72a6c in free () from /lib64/libc.so.6 #6 0x00000037a4ecabda in __vsyslog_chk () from /lib64/libc.so.6 #7 0x00000037a4ecaf33 in __syslog_chk () from /lib64/libc.so.6 #8 0x0000000000437869 in slapd_daemon_task (ptr=3D<value optimized out>) a= t ../../../servers/slapd/daemon.c:2771 #9 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #10 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 (gdb) fr 8 #8 0x0000000000437869 in slapd_daemon_task (ptr=3D<value optimized out>) a= t ../../../servers/slapd/daemon.c:2771 2771 Debug( LDAP_DEBUG_ANY, (gdb) thread 3 [Switching to thread 3 (process 12412)]#0 0x00000037a4eda178 in __lll_mute= x_lock_wait () from /lib64/libc.so.6 (gdb) fr 4 #4 0x0000000000438df3 in connection_close (c=3D0x2af6540b0a50) at ../../..= /servers/slapd/connection.c:616 616 backend_connection_destroy(c); (gdb) p * 0x2af6540b0a50 $2 =3D 3 (gdb) fr 3 #3 0x0000000000438a99 in connection2anonymous (c=3D0x2af6540b0a50) at ../.= ./../servers/slapd/connection.c:563 563 if ( !BER_BVISNULL( &c->c_authmech ) ) { (gdb) p * 0x2af6540b0a50 $3 =3D 3 (gdb) quit GNU gdb Red Hat Linux (6.5-25.el5rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar= e welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread= _db library "/lib64/libthread_db.so.1". Reading symbols from /usr/lib64/libltdl.so.3...done. Loaded symbols for /usr/lib64/libltdl.so.3 Reading symbols from /lib64/libdl.so.2...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libuuid.so.1...done. Loaded symbols for /lib64/libuuid.so.1 Reading symbols from /usr/lib64/libslapd_db-4.7.so...done. Loaded symbols for /usr/lib64/libslapd_db-4.7.so Reading symbols from /usr/lib64/libodbc.so.1...done. Loaded symbols for /usr/lib64/libodbc.so.1 Reading symbols from /usr/lib64/libsasl2.so.2...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /lib64/libssl.so.6...done. Loaded symbols for /lib64/libssl.so.6 Reading symbols from /lib64/libcrypto.so.6...done. Loaded symbols for /lib64/libcrypto.so.6 Reading symbols from /lib64/libcrypt.so.1...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libresolv.so.2...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libpthread.so.0...done. Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libwrap.so.0...done. Loaded symbols for /usr/lib64/libwrap.so.0 Reading symbols from /lib64/libc.so.6...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 Reading symbols from /usr/lib64/libkrb5.so.3...done. Loaded symbols for /usr/lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /usr/lib64/libk5crypto.so.3...done. Loaded symbols for /usr/lib64/libk5crypto.so.3 Reading symbols from /usr/lib64/libz.so.1...done. Loaded symbols for /usr/lib64/libz.so.1 Reading symbols from /lib64/libnsl.so.1...done. Loaded symbols for /lib64/libnsl.so.1 Reading symbols from /usr/lib64/libkrb5support.so.0...done. Loaded symbols for /usr/lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libsepol.so.1...done. Loaded symbols for /lib64/libsepol.so.1 Reading symbols from /lib64/libnss_dns.so.2...done. Loaded symbols for /lib64/libnss_dns.so.2 Reading symbols from /lib64/libnss_files.so.2...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /usr/lib64/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib64/sasl2/libplain.so.2 Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 Reading symbols from /usr/lib64/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 Reading symbols from /usr/lib64/openldap/syncprov-2.4.so.2...Reading symbol= s from /usr/lib/debug/usr/lib64/openldap/syncprov-2.4.so.2.5.4.debug...done= . done. Loaded symbols for /usr/lib64/openldap/syncprov-2.4.so.2 Reading symbols from /usr/lib64/openldap/cms_template-2.4.so.2...Reading sy= mbols from /usr/lib/debug/usr/lib64/openldap/cms_template-2.4.so.2.5.4.debu= g...done. done. Loaded symbols for /usr/lib64/openldap/cms_template-2.4.so.2 Reading symbols from /usr/lib64/openldap/cms_modif-2.4.so.2...Reading symbo= ls from /usr/lib/debug/usr/lib64/openldap/cms_modif-2.4.so.2.5.4.debug...do= ne. done. Loaded symbols for /usr/lib64/openldap/cms_modif-2.4.so.2 Reading symbols from /lib64/libgcc_s.so.1...done. Loaded symbols for /lib64/libgcc_s.so.1 Core was generated by `/usr/sbin/slapd -h ldap:/// -u ldap'. Program terminated with signal 6, Aborted. #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 (gdb) thread apply all bt Thread 3 (process 17892): #0 0x00000037a5a075a5 in pthread_join () from /lib64/libpthread.so.0 #1 0x000000000043402c in slapd_daemon () at ../../../servers/slapd/daemon.= c:2834 #2 0x0000000000420d75 in main (argc=3D5, argv=3D0x7fff3a6ee4b8) at ../../.= ./servers/slapd/main.c:953 Thread 2 (process 17894): #0 0x00000037a5a0a496 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/lib= pthread.so.0 #1 0x000000000052fdab in ldap_pvt_thread_pool_destroy (tpool=3D0x8635e8, r= un_pending=3D487320688) at ../../../libraries/libldap_r/tpool.c:558 #2 0x000000000043767c in slapd_daemon_task (ptr=3D<value optimized out>) a= t ../../../servers/slapd/daemon.c:2764 #3 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #4 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 Thread 1 (process 17895): #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 #3 0x00000037a4e6f444 in _int_free () from /lib64/libc.so.6 #4 0x00000037a4e72a6c in free () from /lib64/libc.so.6 #5 0x0000000000559e07 in sb_rdahead_remove (sbiod=3D0x2aaac488d0d0) at ../= ../../libraries/liblber/sockbuf.c:606 #6 0x0000000000559fb9 in ber_sockbuf_free (sb=3D0x2aaac488d0d0) at ../../.= ./libraries/liblber/sockbuf.c:71 #7 0x0000000000000000 in ?? () (gdb) thread 1 [Switching to thread 1 (process 17895)]#0 0x00000037a4e30045 in raise () f= rom /lib64/libc.so.6 (gdb) bt #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 #3 0x00000037a4e6f444 in _int_free () from /lib64/libc.so.6 #4 0x00000037a4e72a6c in free () from /lib64/libc.so.6 #5 0x0000000000559e07 in sb_rdahead_remove (sbiod=3D0x2aaac488d0d0) at ../= ../../libraries/liblber/sockbuf.c:606 #6 0x0000000000559fb9 in ber_sockbuf_free (sb=3D0x2aaac488d0d0) at ../../.= ./libraries/liblber/sockbuf.c:71 #7 0x0000000000000000 in ?? () (gdb) frame 5 #5 0x0000000000559e07 in sb_rdahead_remove (sbiod=3D0x2aaac488d0d0) at ../= ../../libraries/liblber/sockbuf.c:606 in ../../../libraries/liblber/sockbuf.c (gdb) p sbiod $1 =3D (Sockbuf_IO_Desc *) 0x2aaac488d0d0 (gdb) p * 0x2aaac488d0d0 $2 =3D 10 (gdb) p * sbiod $3 =3D {sbiod_level =3D 10, sbiod_sb =3D 0x2aaac49fc5c0, sbiod_io =3D 0x7e8= 340, sbiod_pvt =3D 0x2aaac48944c0, sbiod_next =3D 0x0} (gdb) p * 0x2aaac49fc5c0 $4 =3D 3 (gdb) p * 0x2aaac48944c0 $5 =3D 1601201012 (gdb) quit [root@ts2mstsv010 dumps]# From: De Bonis Hamelin, Marie Antoinette (Marian - HP Software - CMS) Sent: Donnerstag, 25. M=E4rz 2010 14:20 To: Hummel, Wolfgang Subject: ldap core analysis Wolfgang, If you check I have let 2 files which have all stack trace for a core.<pid>= on the ldap. In one of the core file txt anayzis, we can see the call to sb_rdahead_remo= ve() just after the libc is doing is malloc/free check and it aborts. I have checked the code (see below), sbiod is not null plus we have an asse= rt in the code. So according to me, p is corrupted because sbiod->sbiod_pvt is not a valid = address. Marian -> openldap/dist/libraries/liblber/sockbuf.c static int sb_rdahead_remove( Sockbuf_IO_Desc *sbiod ) { Sockbuf_Buf *p; assert( sbiod !=3D NULL ); p =3D (Sockbuf_Buf *)sbiod->sbiod_pvt; if ( p->buf_ptr !=3D p->buf_end ) return -1; ber_pvt_sb_buf_destroy( (Sockbuf_Buf *)(sbiod->sbiod_pvt) ); LBER_FREE( sbiod->sbiod_pvt ); sbiod->sbiod_pvt =3D NULL; return 0; } Wolfgang Hummel

1 0

Re: (ITS#6481) Asssert with acl-sets and referals
by raphael.ouazana＠linagora.com 24 Mar '10

24 Mar '10

Le Lun 22 mars 2010 21:51, masarati(a)aero.polimi.it a écrit : > Fixed in HEAD; please test. Thanks, p. > > Thank you, that seems to work fine. Regards, Raphael Ouazana.

1 0

(ITS#6498) SLAPI functions missing
by maci＠satgnu.net 24 Mar '10

24 Mar '10

Full_Name: Marcel Wysocki Version: 2.4.21 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.79.126.162) I noticed that all of the SLAPI functions do manipulate LDAPMod** are missing. from the fedora ds slapi-plugin.h: /* * LDAPMod manipulation routines */ Slapi_Mods* slapi_mods_new( void ); void slapi_mods_init(Slapi_Mods *smods, int initCount); void slapi_mods_init_byref(Slapi_Mods *smods, LDAPMod **mods); void slapi_mods_init_passin(Slapi_Mods *smods, LDAPMod **mods); void slapi_mods_free(Slapi_Mods **smods); void slapi_mods_done(Slapi_Mods *smods); void slapi_mods_insert_at(Slapi_Mods *smods, LDAPMod *mod, int pos); void slapi_mods_insert_smod_at(Slapi_Mods *smods, Slapi_Mod *smod, int pos); void slapi_mods_insert_before(Slapi_Mods *smods, LDAPMod *mod); void slapi_mods_insert_smod_before(Slapi_Mods *smods, Slapi_Mod *smod); void slapi_mods_insert_after(Slapi_Mods *smods, LDAPMod *mod); void slapi_mods_insert_after(Slapi_Mods *smods, LDAPMod *mod); void slapi_mods_add( Slapi_Mods *smods, int modtype, const char *type, unsigned long len, const char *val); void slapi_mods_add_ldapmod(Slapi_Mods *smods, LDAPMod *mod); void slapi_mods_add_modbvps( Slapi_Mods *smods, int modtype, const char *type, struct berval **bvps ); void slapi_mods_add_mod_values( Slapi_Mods *smods, int modtype, const char *type, Slapi_Value **va ); void slapi_mods_add_smod(Slapi_Mods *smods, Slapi_Mod *smod); void slapi_mods_add_string( Slapi_Mods *smods, int modtype, const char *type, const char *val); void slapi_mods_remove(Slapi_Mods *smods); LDAPMod *slapi_mods_get_first_mod(Slapi_Mods *smods); LDAPMod *slapi_mods_get_next_mod(Slapi_Mods *smods); Slapi_Mod *slapi_mods_get_first_smod(Slapi_Mods *smods, Slapi_Mod *smod); Slapi_Mod *slapi_mods_get_next_smod(Slapi_Mods *smods, Slapi_Mod *smod); void slapi_mods_iterator_backone(Slapi_Mods *smods); LDAPMod **slapi_mods_get_ldapmods_byref(Slapi_Mods *smods); LDAPMod **slapi_mods_get_ldapmods_passout(Slapi_Mods *smods); int slapi_mods_get_num_mods(const Slapi_Mods *smods); void slapi_mods_dump(const Slapi_Mods *smods, const char *text); Slapi_Mod* slapi_mod_new( void ); void slapi_mod_init(Slapi_Mod *smod, int initCount); void slapi_mod_init_byval(Slapi_Mod *smod, const LDAPMod *mod); void slapi_mod_init_byref(Slapi_Mod *smod, LDAPMod *mod); void slapi_mod_init_passin(Slapi_Mod *smod, LDAPMod *mod); /* init a mod and set the mod values to be a copy of the given valueset */ void slapi_mod_init_valueset_byval(Slapi_Mod *smod, int op, const char *type, const Slapi_ValueSet *svs); void slapi_mod_add_value(Slapi_Mod *smod, const struct berval *val); void slapi_mod_remove_value(Slapi_Mod *smod); struct berval *slapi_mod_get_first_value(Slapi_Mod *smod); struct berval *slapi_mod_get_next_value(Slapi_Mod *smod); const char *slapi_mod_get_type(const Slapi_Mod *smod); int slapi_mod_get_operation(const Slapi_Mod *smod); void slapi_mod_set_type(Slapi_Mod *smod, const char *type); void slapi_mod_set_operation(Slapi_Mod *smod, int op); int slapi_mod_get_num_values(const Slapi_Mod *smod); const LDAPMod *slapi_mod_get_ldapmod_byref(const Slapi_Mod *smod); LDAPMod *slapi_mod_get_ldapmod_passout(Slapi_Mod *smod); void slapi_mod_free(Slapi_Mod **smod); void slapi_mod_done(Slapi_Mod *mod); int slapi_mod_isvalid(const Slapi_Mod *mod); void slapi_mod_dump(LDAPMod *mod, int n); /* helper functions to translate between entry and a set of mods */ int slapi_mods2entry(Slapi_Entry **e, const char *dn, LDAPMod **attrs); int slapi_entry2mods(const Slapi_Entry *e, char **dn, LDAPMod ***attrs); there might be some more missing. most of it can be found in fedora ds's modutils.c should be worth porting to openldap

1 0

Re: (ITS#6478) slapd crashes with segfault
by masarati＠aero.polimi.it 23 Mar '10

23 Mar '10

> Hello, here is a backtrace > of the crash, however not yet from > a version with full debug symbols enabled. > We are still working on that. You rbacktrace, although incomplete, looks weird: > #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 > #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 > #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 > #3 0x00000037a4e6da07 in malloc_consolidate () from /lib64/libc.so.6 > #4 0x00000037a4e6f1fb in _int_free () from /lib64/libc.so.6 > #5 0x00000037a4e72a6c in free () from /lib64/libc.so.6 > #6 0x00000037a4ecabda in __vsyslog_chk () from /lib64/libc.so.6 > #7 0x00000037a4ecaf33 in __syslog_chk () from /lib64/libc.so.6 > #8 0x0000000000437869 in slapd_remove () > #9 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 > #10 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 libc is raising an assertion during a free related to printing something on syslog. However, in slapd_remove() I don't see anything that could be harmful for syslog, as the only information that may be printed is printed at a very verbose loglevel, and basically consists of integers, so it seems impossible that things like NULL or invalid pointers slip through. p.

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by crispy＠cluenet.org 23 Mar '10

23 Mar '10

I found that there's an alternate way to achieve this same functionality that's more elegant, probably more efficient, and doesn't require any patches. The approach uses the authorizedService attributes on the host entry. With nssov, individual users can be granted or revoked access based on the slapd ACLs and whether or not they have "compare" access to the authorizedService attribute. I created groups of users underneath the host entry - one for each service - and used regex's in the ACLs to grant compare access to the correct authorizedService attribute when the user is present in the corresponding group. Also the buffer sizes were determined to be a non-issue and do not need to be changed. Chris Breneman On Mon, 2010-03-22 at 00:03 -0500, Kean Johnston wrote: > I like what this offers administrators but I have a comment about how you > handle "wildcards". They aren't wild at all, but "magic strings" with only > one possible meaning: all users/services with the single magic character > "*". If you have a defined user naming convention like i_whatever for > interns and c_whatever for contractors, it would be useful to be able to > either include or exclude such users from using certain services. > > My patch at http://www.openldap.org/its/index.cgi?findid=6495 does this for > userhost and userservices attributes, and includes negation. Would you be > interested in working with me to expand this to support real wildcards? > Also I suggest you make this two patches, as the patch submission > guidelines clearly state that one patch for 1 feature, and the meaty parts > of this are obfuscated by increasing the buffer sizes which should probably > be in a separate patch. > > Regards, Kean

1 0

Re: (ITS#6497) Infinite loop in translucent.c
by masarati＠aero.polimi.it 23 Mar '10

23 Mar '10

Fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6478) slapd crashes with segfault
by wolfgang.hummel＠hp.com 23 Mar '10

23 Mar '10

Hello, here is a backtrace of the crash, however not yet from a version with full debug symbols enabled. We are still working on that. [root@ts2mstsv010 dumps]# gdb /usr/sbin/slapd core.slapd.12403 GNU gdb Red Hat Linux (6.5-25.el5rh) Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar= e welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu"...(no debugging symbol= s found) Using host libthread_db library "/lib64/libthread_db.so.1". Reading symbols from /usr/lib64/libltdl.so.3...(no debugging symbols found)= ...done. Loaded symbols for /usr/lib64/libltdl.so.3 Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...don= e. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libuuid.so.1...(no debugging symbols found)...d= one. Loaded symbols for /lib64/libuuid.so.1 Reading symbols from /usr/lib64/libslapd_db-4.7.so...(no debugging symbols = found)...done. Loaded symbols for /usr/lib64/libslapd_db-4.7.so Reading symbols from /usr/lib64/libodbc.so.1...(no debugging symbols found)= ...done. Loaded symbols for /usr/lib64/libodbc.so.1 Reading symbols from /usr/lib64/libsasl2.so.2... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/libsasl2.so.2 Reading symbols from /lib64/libssl.so.6...(no debugging symbols found)...do= ne. Loaded symbols for /lib64/libssl.so.6 Reading symbols from /lib64/libcrypto.so.6...(no debugging symbols found)..= .done. Loaded symbols for /lib64/libcrypto.so.6 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...= done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)..= .done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libpthread.so.0... (no debugging symbols found)...done. Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /usr/lib64/libwrap.so.0...(no debugging symbols found)= ...done. Loaded symbols for /usr/lib64/libwrap.so.0 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done= . Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols fo= und)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /usr/lib64/libgssapi_krb5.so.2...(no debugging symbols= found)...done. Loaded symbols for /usr/lib64/libgssapi_krb5.so.2 Reading symbols from /usr/lib64/libkrb5.so.3... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/libkrb5.so.3 Reading symbols from /lib64/libcom_err.so.2...(no debugging symbols found).= ..done. Loaded symbols for /lib64/libcom_err.so.2 Reading symbols from /usr/lib64/libk5crypto.so.3...(no debugging symbols fo= und)...done. Loaded symbols for /usr/lib64/libk5crypto.so.3 Reading symbols from /usr/lib64/libz.so.1...(no debugging symbols found)...= done. Loaded symbols for /usr/lib64/libz.so.1 Reading symbols from /lib64/libnsl.so.1...(no debugging symbols found)...do= ne. Loaded symbols for /lib64/libnsl.so.1 Reading symbols from /usr/lib64/libkrb5support.so.0... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/libkrb5support.so.0 Reading symbols from /lib64/libkeyutils.so.1...(no debugging symbols found)= ...done. Loaded symbols for /lib64/libkeyutils.so.1 Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found).= ..done. Loaded symbols for /lib64/libselinux.so.1 Reading symbols from /lib64/libsepol.so.1...(no debugging symbols found)...= done. Loaded symbols for /lib64/libsepol.so.1 Reading symbols from /lib64/libnss_dns.so.2...(no debugging symbols found).= ..done. Loaded symbols for /lib64/libnss_dns.so.2 Reading symbols from /lib64/libnss_files.so.2... (no debugging symbols found)...done. Loaded symbols for /lib64/libnss_files.so.2 Reading symbols from /usr/lib64/sasl2/libplain.so.2...(no debugging symbols= found)...done. Loaded symbols for /usr/lib64/sasl2/libplain.so.2 Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...(no debugging sym= bols found)...done. Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2 Reading symbols from /usr/lib64/sasl2/liblogin.so.2...(no debugging symbols= found)...done. Loaded symbols for /usr/lib64/sasl2/liblogin.so.2 Reading symbols from /usr/lib64/openldap/syncprov-2.4.so.2...(no debugging = symbols found)...done. Loaded symbols for /usr/lib64/openldap/syncprov-2.4.so.2 Reading symbols from /usr/lib64/openldap/cms_template-2.4.so.2... (no debugging symbols found)...done. Loaded symbols for /usr/lib64/openldap/cms_template-2.4.so.2 Reading symbols from /usr/lib64/openldap/cms_modif-2.4.so.2...(no debugging= symbols found)...done. Loaded symbols for /usr/lib64/openldap/cms_modif-2.4.so.2 Reading symbols from /lib64/libgcc_s.so.1...(no debugging symbols found)...= done. Loaded symbols for /lib64/libgcc_s.so.1 Core was generated by `/usr/sbin/slapd -h ldap:/// -u ldap'. Program terminated with signal 6, Aborted. #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00000037a4e30045 in raise () from /lib64/libc.so.6 #1 0x00000037a4e31ae0 in abort () from /lib64/libc.so.6 #2 0x00000037a4e681bb in __libc_message () from /lib64/libc.so.6 #3 0x00000037a4e6da07 in malloc_consolidate () from /lib64/libc.so.6 #4 0x00000037a4e6f1fb in _int_free () from /lib64/libc.so.6 #5 0x00000037a4e72a6c in free () from /lib64/libc.so.6 #6 0x00000037a4ecabda in __vsyslog_chk () from /lib64/libc.so.6 #7 0x00000037a4ecaf33 in __syslog_chk () from /lib64/libc.so.6 #8 0x0000000000437869 in slapd_remove () #9 0x00000037a5a062e7 in start_thread () from /lib64/libpthread.so.0 #10 0x00000037a4ece3bd in clone () from /lib64/libc.so.6 (gdb) Wolfgang Hummel

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by quanah＠zimbra.com 22 Mar '10

22 Mar '10

--On Monday, March 22, 2010 9:00 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > As already noted, there is no need to give root access to admins. My > guess is you really do not understand how ACLs work. I would advise > carefully reading the slapd-access(5) man page. You may also find a page I wrote some time ago useful in helping to understand how ACLs work: <http://www.stanford.edu/services/directory/openldap/configuration/slapd-acl…> Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by quanah＠zimbra.com 22 Mar '10

22 Mar '10

--On Monday, March 22, 2010 12:41 PM +0000 kean.johnston(a)gmail.com wrote: >> Authorization is the job of the ACL engine. Putting ad-hoc rules into >> user entries is, in a word, stupid. It's also unscaleable and will >> become an administration nightmare. > Well OK then. Using a configuration mechanism like ACL's that cannot be > distributed to multiple users (like editing a directory can) is, in a > word, stupid. It is also unscaleable and will become an administration > nightmare. And authorisation is not (or SHOULD not be) the job of ACL's > its the job of authorisation modules, which nssov is. > > Being forced to give admins who simply want to be able to change access > to a random host in a centralised server root access to what may be a > critical server with other sensitive data on it is simply wrong. As already noted, there is no need to give root access to admins. My guess is you really do not understand how ACLs work. I would advise carefully reading the slapd-access(5) man page. Regards, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6481) Asssert with acl-sets and referals
by masarati＠aero.polimi.it 22 Mar '10

22 Mar '10

Fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6490) dds and pcache overlays not checking NULL value
by masarati＠aero.polimi.it 22 Mar '10

22 Mar '10

Fixed (slighlty differently) in HEAD. Please test. Thanks, p.

1 0

(ITS#6497) Infinite loop in translucent.c
by ondrej.kuznik＠acision.com 22 Mar '10

22 Mar '10

Full_Name: Ondrej Kuznik Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.168.56.1) Hi, there is a bug in translucent.c:208 in translucent_cf_gen such that modification of olcTranslucentRemote or olcTranslucentLocal can trigger an infinite loop, making the server unresponsive. Please see the attached patch that fixes the issue and consider including it in your codebase: --- servers/slapd/overlays/translucent.c 2009-11-30 12:59:06.000000000 +0100 +++ servers/slapd/overlays/fixed.c 2010-03-22 16:23:39.000000000 +0100 @@ -205,7 +205,7 @@ i = c->valx; ch_free( (*an)[i].an_name.bv_val ); do { - (*an)[i] = (*an)[i+1]; + (*an)[i] = (*an)[++i]; } while ( !BER_BVISNULL( &(*an)[i].an_name )); } return 0;

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

> So let them edit the host permissions. Delegate the privileges to > groups, and give them write access to their respective groups. ... > Irrelevant. Using slapd.conf doesn't preclude delegation of privileges > or dynamic updates to privilege memberships. I have read the admin guide from cover to cover, several times. I am not an LDAP expert (yet) so perhaps some things you take for granted are not obvious to the newcomer. Everything I have read just makes me confused about how the above can work. If you can point me at a relevant place in teh the man pages, or the admin guide, or an example of how this is possible, I will both be very grateful and have a deeper understanding of why this patch isn't necessary. The documentation says: Authorization is checked by performing an LDAP Compare operation looking for the PAM service name in the authorizedService attribute. slapd ACLs should be set to grant or deny Compare privilege to the appropriate users or groups as desired. As the OpenLDAP architect and someone who has been using LDAP for decades, that may seem obvious to you. It is not to others. As I understand that to mean, I would have to have something like: access to dn.exact="cn=host1,ou=hosts,dc=example,dc=com" attrs=authroizedService by dn="uid=user1,ou=people,dc=example,dc=com" compare by dn=uid=user2,ou=people,dc=example,dc=com" compare by group.exact="cn=somegroup,ou=groups,dc=example,dc=com" compare by * none which is how I would give access to a group of people as well as individuals. Now I want to grant special access to user3, who isn't part of any particular group, just a random user who needs access to the host. Now I have to change the above ACL. That ACL is in slapd.conf. How to I delegate being able to give a non-root user permissions to add user3 to that host. How do I delegate a non-root user to set permissions for host2 and host 3 etc. I realise this may be incorrect but thats how I understand the docs. I am not particularly dumb so if thats what I took away from the docs, chances are others did too, and at best, the documentation needs beefing up. > On the contrary - for security management, it's the BEST thing. Keeping > your authorization rules scattered across the data space not only makes > it harder to administer, it also makes it easier to subvert. Keeping it > all isolated in a single administrative space negates both of those > problems. Clearly you have never worked in an organisation with several tens or even hundreds of thousands of users. I don't see how putting everything in the one place helps at all. In fact it makes it a bottleneck of the worst kind. But being able to partition things and giving team A responsibility over access to this group of hosts and team B responsibility over that group of hosts and having the host access and authorization information actually be in the host entry just makes more sense, and it scales better.

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by hyc＠symas.com 22 Mar '10

22 Mar '10

Kean Johnston wrote: >> This patch was rejected. The functionality it offered was already >> provided by the slapd ACL engine. > Could I ask you to reconsider your position on using ACL's? Using ACL's for > this kind of thing is a little bit like asking the security guard that > makes your entry badge also be in charge of all of your HR data and > documents. I understand the ACL engine may be quick but it completely > defeats the purpose of having a centralised directory. No, doing anything else defeats that purpose. > What if I want > directory administrators to be able to edit host permissions but I don't > want them to have root so they can edit slapd.conf or change the SLAPD > configuration? So let them edit the host permissions. Delegate the privileges to groups, and give them write access to their respective groups. > what if I cant even use the modern configuration because > overlays I want to use don't support it and I am forced to use slapd.conf? Irrelevant. Using slapd.conf doesn't preclude delegation of privileges or dynamic updates to privilege memberships. > It also moves away from the model of having data about the host in one dn: > cn=host,dc=example,dc=com entry to now having pretty vital information > about the host moved completely out of the directory itself and into the > directory server's configuration. That surely can't be a good thing. On the contrary - for security management, it's the BEST thing. Keeping your authorization rules scattered across the data space not only makes it harder to administer, it also makes it easier to subvert. Keeping it all isolated in a single administrative space negates both of those problems. The key to scalable security is centralized control with distributed access, not distributed control. The more widely you distribute the actual points of control, the more likely you are to make a mistake and open a hole between the points. > What if I want to move from OpenLDAP to some other server? Then you probably should be using nss-pam-ldapd, and not nssov. -- -- 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#6495) nssov patch to better emulate pam_ldap behaviour
by hyc＠symas.com 22 Mar '10

22 Mar '10

Kean Johnston wrote: >> Authorization is the job of the ACL engine. Putting ad-hoc rules into >> user entries is, in a word, stupid. It's also unscaleable and will >> become an administration nightmare. > Well OK then. Using a configuration mechanism like ACL's that cannot be > distributed to multiple users (like editing a directory can) is, in a word, > stupid. It is also unscaleable and will become an administration nightmare. > And authorisation is not (or SHOULD not be) the job of ACL's its the job of > authorisation modules, which nssov is. > > Being forced to give admins who simply want to be able to change access to > a random host in a centralised server root access to what may be a critical > server with other sensitive data on it is simply wrong. You seem to be laboring under the false premise that root privileges are required to administer authorization in slapd. Since that is false, the rest of your statements are moot. >> The user host attribute functionality is deprecated. I have no desire to >> make it even vaguely appear to be useful. > Then don't sell it as one. You claim pam_ldap compatibility but that is > false. The user docs also aren't nearly as strongly worded, saying that the > hostserver and ACL's is preferable, not that userhost is deprecated. > A flexible solution gives administrators the opportunity to use the tool in > ways you haven't conceived of because it works for them and their > environment. A ridgid and dictatorial tool forces people to do things one > way and one way only. I have worked for one of the larger software > companies and can tell you that the ACL mechanism would scale orders of > magnitude worse, and they did, in fact have authorisation info stored in > user and host attributes because that was the only way to delegate > responsibility to multiple groups. That may have been true of that other software package. That is not true here. > PS, you may wanna consider dropping the Ulrich Drepper attitude. When a > contributor, especially a first time one, who has gone to considerable > lengths to follow all the guidelines and do things just your way has, as > his first experience someone calling things "stupid" ... well, that will > thin the development herd considerably. No, I should rather step it up a notch. I don't want contributions from J. Random Developer. I want contributions from people who participate in the community. That means reading up on how things are done, following the established practices, and demonstrating a familiarity with the way things are done and establishing a familiarity with the other community members. That means showing that you'll take the time to stick around and continue to maintain/support your code if we pull it in. If a developer won't put that time in up front, then I don't care how good their code is; I don't want to be saddled with it when they inevitably disappear. The established practice for contributing new code is to discuss it on the openldap-devel mailing list first, before spending any time on actual coding. After the developer community gets a chance to think about it and weigh in on whether it's a good idea or not, then you start (or don't start) writing the code and submitting to the ITS. -- -- 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#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

> Authorization is the job of the ACL engine. Putting ad-hoc rules into > user entries is, in a word, stupid. It's also unscaleable and will > become an administration nightmare. Well OK then. Using a configuration mechanism like ACL's that cannot be distributed to multiple users (like editing a directory can) is, in a word, stupid. It is also unscaleable and will become an administration nightmare. And authorisation is not (or SHOULD not be) the job of ACL's its the job of authorisation modules, which nssov is. Being forced to give admins who simply want to be able to change access to a random host in a centralised server root access to what may be a critical server with other sensitive data on it is simply wrong. > The user host attribute functionality is deprecated. I have no desire to > make it even vaguely appear to be useful. Then don't sell it as one. You claim pam_ldap compatibility but that is false. The user docs also aren't nearly as strongly worded, saying that the hostserver and ACL's is preferable, not that userhost is deprecated. A flexible solution gives administrators the opportunity to use the tool in ways you haven't conceived of because it works for them and their environment. A ridgid and dictatorial tool forces people to do things one way and one way only. I have worked for one of the larger software companies and can tell you that the ACL mechanism would scale orders of magnitude worse, and they did, in fact have authorisation info stored in user and host attributes because that was the only way to delegate responsibility to multiple groups. PS, you may wanna consider dropping the Ulrich Drepper attitude. When a contributor, especially a first time one, who has gone to considerable lengths to follow all the guidelines and do things just your way has, as his first experience someone calling things "stupid" ... well, that will thin the development herd considerably.

1 0

Re: (ITS#6487) Nssov pam_authz authorizedUserService
by kean.johnston＠gmail.com 22 Mar '10

22 Mar '10

> This patch was rejected. The functionality it offered was already > provided by the slapd ACL engine. Could I ask you to reconsider your position on using ACL's? Using ACL's for this kind of thing is a little bit like asking the security guard that makes your entry badge also be in charge of all of your HR data and documents. I understand the ACL engine may be quick but it completely defeats the purpose of having a centralised directory. What if I want directory administrators to be able to edit host permissions but I don't want them to have root so they can edit slapd.conf or change the SLAPD configuration? what if I cant even use the modern configuration because overlays I want to use don't support it and I am forced to use slapd.conf? It also moves away from the model of having data about the host in one dn: cn=host,dc=example,dc=com entry to now having pretty vital information about the host moved completely out of the directory itself and into the directory server's configuration. That surely can't be a good thing. What if I want to move from OpenLDAP to some other server? Kean

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by hyc＠symas.com 21 Mar '10

21 Mar '10

kean.johnston(a)gmail.com wrote: > Full_Name: Kean Johnston > Version: HEAD > OS: Linux (CentOS 5.3) > URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch > Submission from: (NULL) (196.210.34.161) > > > The nssov manual page states that some of it's options "duplicates the original > pam_ldap authorization behavior". However, they don't quite. pam_ldap has the > ability for you to use "wildcards" in a user's host: attribute. I say > "wildcards" in quotes because the pam_ldap implementation does not actually use > regex matching, but rather check for two special strings, "*" and "!". > > The ability to use actual wildcards, especially ones you can negate, on a per > user basis is extremely useful to an administrator of large networks. For > example you may want all developers to have access to the machines in > developers.mydomain.com but you want to disallow access to some of those > machines to contractors or interns. > > This patch allows such behaviour, so it serves the dual purpose of actually > implementing existing pam_ldap behaviour in case people already depend on that, > as well as extends it to be a more generally usable feature by using actual > regular expressions. The code is simple, and the man page change describes it > well enough. Please consider adding this code to nssov. Thank you. > Authorization is the job of the ACL engine. Putting ad-hoc rules into user entries is, in a word, stupid. It's also unscaleable and will become an administration nightmare. The user host attribute functionality is deprecated. I have no desire to make it even vaguely appear to be useful. -- -- 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#6487) Nssov pam_authz authorizedUserService
by hyc＠symas.com 21 Mar '10

21 Mar '10

kean.johnston(a)gmail.com wrote: > I like what this offers administrators but I have a comment about how you > handle "wildcards". They aren't wild at all, but "magic strings" with only > one possible meaning: all users/services with the single magic character > "*". If you have a defined user naming convention like i_whatever for > interns and c_whatever for contractors, it would be useful to be able to > either include or exclude such users from using certain services. > > My patch at http://www.openldap.org/its/index.cgi?findid=6495 does this for > userhost and userservices attributes, and includes negation. Would you be > interested in working with me to expand this to support real wildcards? > Also I suggest you make this two patches, as the patch submission > guidelines clearly state that one patch for 1 feature, and the meaty parts > of this are obfuscated by increasing the buffer sizes which should probably > be in a separate patch. > > Regards, Kean This patch was rejected. The functionality it offered was already provided by the slapd ACL engine. -- -- 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#6487) Nssov pam_authz authorizedUserService
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

I like what this offers administrators but I have a comment about how you handle "wildcards". They aren't wild at all, but "magic strings" with only one possible meaning: all users/services with the single magic character "*". If you have a defined user naming convention like i_whatever for interns and c_whatever for contractors, it would be useful to be able to either include or exclude such users from using certain services. My patch at http://www.openldap.org/its/index.cgi?findid=6495 does this for userhost and userservices attributes, and includes negation. Would you be interested in working with me to expand this to support real wildcards? Also I suggest you make this two patches, as the patch submission guidelines clearly state that one patch for 1 feature, and the meaty parts of this are obfuscated by increasing the buffer sizes which should probably be in a separate patch. Regards, Kean

1 0

Re: (ITS#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

ftp.openldap.org reports no space on the device, so the URL for the patch is at: http://64.34.163.232/openldap/kean-johnston-100321.patch

1 0

(ITS#6496) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

Full_Name: Kean Johnston Version: HEAD OS: Linux (CentOS 5.3) URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch Submission from: (NULL) (196.210.34.161) The nssov manual page states that some of it's options "duplicates the original pam_ldap authorization behavior". However, they don't quite. pam_ldap has the ability for you to use "wildcards" in a user's host: attribute. I say "wildcards" in quotes because the pam_ldap implementation does not actually use regex matching, but rather check for two special strings, "*" and "!". The ability to use actual wildcards, especially ones you can negate, on a per user basis is extremely useful to an administrator of large networks. For example you may want all developers to have access to the machines in developers.mydomain.com but you want to disallow access to some of those machines to contractors or interns. This patch allows such behaviour, so it serves the dual purpose of actually implementing existing pam_ldap behaviour in case people already depend on that, as well as extends it to be a more generally usable feature by using actual regular expressions. The code is simple, and the man page change describes it well enough. Please consider adding this code to nssov. Thank you.

1 0

(ITS#6495) nssov patch to better emulate pam_ldap behaviour
by kean.johnston＠gmail.com 21 Mar '10

21 Mar '10

Full_Name: Kean Johnston Version: HEAD OS: Linux (CentOS 5.3) URL: ftp://ftp.openldap.org/incoming/kean-johnston-100321.patch Submission from: (NULL) (196.210.34.161) The nssov manual page states that some of it's options "duplicates the original pam_ldap authorization behavior". However, they don't quite. pam_ldap has the ability for you to use "wildcards" in a user's host: attribute. I say "wildcards" in quotes because the pam_ldap implementation does not actually use regex matching, but rather check for two special strings, "*" and "!". The ability to use actual wildcards, especially ones you can negate, on a per user basis is extremely useful to an administrator of large networks. For example you may want all developers to have access to the machines in developers.mydomain.com but you want to disallow access to some of those machines to contractors or interns. This patch allows such behaviour, so it serves the dual purpose of actually implementing existing pam_ldap behaviour in case people already depend on that, as well as extends it to be a more generally usable feature by using actual regular expressions. The code is simple, and the man page change describes it well enough. Please consider adding this code to nssov. Thank you.

1 0

(ITS#6494) replication doesn't works if directory contains more than one tree
by Ikonta＠yandex.ru 19 Mar '10

19 Mar '10

Full_Name: Sergey A. Starikov Version: 2.4.21 OS: FreeBSD 7.2-RELEASE-p4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.229.208.12) Also (currently the main OS) is FreeBSD 6.4-RELEASE-p9. Configuration stored in slapd.conf. Two servers in mirror mode. The slapd.conf is: <includes> serverID pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules: modulepath /usr/local/libexec/openldap moduleload back_bdb <ACLs set (replicator user can read everything in replicated tree)> sizelimit 1024 # ####################################################################### # BDB database definitions ####################################################################### # db #1 (caotus userbase, main database) database bdb suffix "dc=mydomain,dc=ru" rootdn "uid=admin,dc=mydomain,dc=ru" rootpw {SSHA}<some hash> overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/db/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub <and some other indexes> # syncprov specific indexing index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncrepl rid=002 provider=ldap://ldapN.mydomain.ru:389 type=refreshOnly interval=00:00:12:00 retry="64 16 256 4" searchbase="dc=mydomain,dc=ru" scope=sub sizelimit=unlimited timelimit=512 schemachecking=on bindmethod=simple binddn="uid=Replicator,ou=People,dc=mydomain,dc=ru" credentials=secret mirrormode on # db #2 (ESPP certs database accesslog) database bdb suffix "cn=accesslog" # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/log/openldap-accesslog # Indices to maintain index reqStart eq In described case accesslog overlay works normally. But overlay syncprov is _particularly_ inoperate (transferred only one of about 28 changes in source database). Both in refreshAndPersist and refreshOnly replication modes. If I remove the accesslog overlay from slapd.conf --- replication works as it should. Also, if I try to add instead the accesslog another tree, for example: slapd.conf: ... # db #2 database bdb suffix "dc=public,dc=org" directory /var/db/openldap-db2 # Indices to maintain index objectClass eq <other indexes> ... replication also doesn't works.

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by korvus＠comcast.net 18 Mar '10

18 Mar '10

On 3/17/2010 9:25 PM, Quanah Gibson-Mount wrote: > --On Wednesday, March 17, 2010 8:17 PM +0000 korvus(a)comcast.net wrote: > >> tjoen wrote: >>> On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: >>>> After some chatter on the mailing list, the problem is now >>>> understood: >>>> - TLS error messages are indeed reported by OpenLDAP: >>>> TLS: could not use key file >>>> `/usr/local/etc/openldap/certs/ldap.key.pem'. >>> ... >>>> - The only way to see these error messages is to start the daemon >>>> with >>>> '-d stats' >>> ... >>>> My suggestions: print the TLS error messages out to syslog, or if >>>> that's not possible, print them to stdout regardless of whether the >>>> daemon is running in the foreground or not. >>> >>> Isn't it in local4.* ? >>> >> >> No, they do not get sent to local4.* - the only TLS message which makes >> it there in this scenario is: slapd[72041]: main: TLS init def ctx >> failed: -1 >> >> Like I said, the ONLY way to get the actual TLS error messages is to run >> the daemon by hand in the foreground with loglevel stats by way of >> 'slapd >> -d stats'. Per the manpage this also prevents slapd from forking: >> -d debug-level >> Turn on debugging as defined by debug-level. If this >> option is specified, even with a zero argument, slapd >> will not fork or disassociate from the invoking >> terminal. >> >> >> Let me know if I'm still not being clear. > > If you are trying to debug an issue, you most certainly should be > running slapd -d <level>... that's why it exists. > > --Quanah > That's a valid point. However, it does not explain why the TLS errors aren't (or "shouldn't be") logged via syslog.

1 0

Re: (ITS#6493) Broken link in online openldap administrator's guide
by ghenry＠OpenLDAP.org 18 Mar '10

18 Mar '10

----- "felix wolfsteller" <felix.wolfsteller(a)intevation.de> wrote: > Full_Name: Felix Wolfsteller > Version: n/a > OS: na/a > URL: http://www.openldap.org/doc/admin24/schema.html > Submission from: (NULL) (212.95.107.190) > > > In the online openldap administrator's guide, section 13.2.1 > ( http://www.openldap.org/doc/admin24/schema.html ) > , > > " http://www.alvestrand.no/harald/objectid/ " > > is referenced, where it should be > > " http://www.alvestrand.no/objectid/ " , i guess. Thanks, will fix. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6493) Broken link in online openldap administrator's guide
by felix.wolfsteller＠intevation.de 18 Mar '10

18 Mar '10

Full_Name: Felix Wolfsteller Version: n/a OS: na/a URL: http://www.openldap.org/doc/admin24/schema.html Submission from: (NULL) (212.95.107.190) In the online openldap administrator's guide, section 13.2.1 ( http://www.openldap.org/doc/admin24/schema.html ) , " http://www.alvestrand.no/harald/objectid/ " is referenced, where it should be " http://www.alvestrand.no/objectid/ " , i guess.

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by quanah＠zimbra.com 17 Mar '10

17 Mar '10

--On Wednesday, March 17, 2010 8:17 PM +0000 korvus(a)comcast.net wrote: > tjoen wrote: >> On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: >>> After some chatter on the mailing list, the problem is now understood: >>> - TLS error messages are indeed reported by OpenLDAP: >>> TLS: could not use key file >>> `/usr/local/etc/openldap/certs/ldap.key.pem'. >> ... >>> - The only way to see these error messages is to start the daemon with >>> '-d stats' >> ... >>> My suggestions: print the TLS error messages out to syslog, or if >>> that's not possible, print them to stdout regardless of whether the >>> daemon is running in the foreground or not. >> >> Isn't it in local4.* ? >> > > No, they do not get sent to local4.* - the only TLS message which makes > it there in this scenario is: slapd[72041]: main: TLS init def ctx > failed: -1 > > Like I said, the ONLY way to get the actual TLS error messages is to run > the daemon by hand in the foreground with loglevel stats by way of 'slapd > -d stats'. Per the manpage this also prevents slapd from forking: > -d debug-level > Turn on debugging as defined by debug-level. If this > option is specified, even with a zero argument, slapd > will not fork or disassociate from the invoking > terminal. > > > Let me know if I'm still not being clear. If you are trying to debug an issue, you most certainly should be running slapd -d <level>... that's why it exists. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6491) LDAP Error code 80 - Dn index delete failed
by quanah＠zimbra.com 17 Mar '10

17 Mar '10

--On Tuesday, March 16, 2010 8:31 PM +0000 robert.hanson(a)calabrio.com wrote: > Full_Name: Robert Hanson > Version: 2.4.21 > OS: RedHat 4.7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.203.208.250) > > > 1) start with an empty database; use slapadd to add a large (3 MB) > database. 2) Use ldapbrowser to delete nearly all the nodes. After this > process, I get to a point where a subnode can't be deleted; I see the > message "12:00:27 PM: Failed to delete entry ou=Agents, lcc=Call Center > 1, ou=Company, o=Spanlink Communications > Reason: [LDAP: error code 80 - DN index delete failed] > 12:15:19 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, > ou=Company, o=Spanlink Communications > Reason: [LDAP: error code 80 - DN index delete failed]" in the ldapbrowser > window. > > Steps to reproduce: (on redhat linux; I think any linux will do) > 1) build bdb 4.8.26 from the distro; build openldap 2.4.21 from the > distro. 2) copy built slapd to an appropriate place. link it to slapadd. > 3) FTP: ftp.calabrio.com, user openldap, pass *a68pcJH (Account is > scheduled to close 3/23/2010; let me know if you need the file uploaded > again). unzip the file, it contains the slapcat.out; a blank database > (in a subfolder), and a slapd.conf file. > 4) Edit the slapd.conf file as needed to point to the directory where you > put the database. > > That was the setup, now here are the steps to reproduce the problem: > > 5) use slapadd -c -f slapd.conf -l slapcat.out to create the database. > 6) start slapd (using slapd -d 1 -f slapd.conf) > 7) use ldapbrowser to delete the "lcc=call center 1" node. > > It takes a long time, but eventually you'll see it fail while trying to > delete the "agents" node. > Do you see this problem using BDB 4.7.25+patches instead of BDB 4.8? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by korvus＠comcast.net 17 Mar '10

17 Mar '10

tjoen wrote: >On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: >> After some chatter on the mailing list, the problem is now understood: >> - TLS error messages are indeed reported by OpenLDAP: >> TLS: could not use key file `/usr/local/etc/openldap/certs/ldap.key.pem'. >... >> - The only way to see these error messages is to start the daemon with >> '-d stats' >... >> My suggestions: print the TLS error messages out to syslog, or if that's >> not possible, print them to stdout regardless of whether the daemon is >> running in the foreground or not. > >Isn't it in local4.* ? > No, they do not get sent to local4.* - the only TLS message which makes it there in this scenario is: slapd[72041]: main: TLS init def ctx failed: -1 Like I said, the ONLY way to get the actual TLS error messages is to run the daemon by hand in the foreground with loglevel stats by way of 'slapd -d stats'. Per the manpage this also prevents slapd from forking: -d debug-level Turn on debugging as defined by debug-level. If this option is specified, even with a zero argument, slapd will not fork or disassociate from the invoking terminal. Let me know if I'm still not being clear.

1 0

(ITS#6492) sendmail+openldap
by exclusivedesign＠yandex.ru 17 Mar '10

17 Mar '10

Full_Name: Leo Version: openldap-sasl-client-2.4.21 OS: freebsd 7.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.247.195.163) Hello. I use ldap_routing feature in the sendmail (8.14.4). When I upgrade openldap from 2.4.19 to 2.4.21, ldap routing stopped working. SYSERR(root): Error getting LDAP results in map ldapmra: Partial results and referral received downgrade to old version - not helped. Help me please.

1 0

(ITS#6491) LDAP Error code 80 - Dn index delete failed
by robert.hanson＠calabrio.com 16 Mar '10

16 Mar '10

Full_Name: Robert Hanson Version: 2.4.21 OS: RedHat 4.7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.203.208.250) 1) start with an empty database; use slapadd to add a large (3 MB) database. 2) Use ldapbrowser to delete nearly all the nodes. After this process, I get to a point where a subnode can't be deleted; I see the message "12:00:27 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, ou=Company, o=Spanlink Communications Reason: [LDAP: error code 80 - DN index delete failed] 12:15:19 PM: Failed to delete entry ou=Agents, lcc=Call Center 1, ou=Company, o=Spanlink Communications Reason: [LDAP: error code 80 - DN index delete failed]" in the ldapbrowser window. Steps to reproduce: (on redhat linux; I think any linux will do) 1) build bdb 4.8.26 from the distro; build openldap 2.4.21 from the distro. 2) copy built slapd to an appropriate place. link it to slapadd. 3) FTP: ftp.calabrio.com, user openldap, pass *a68pcJH (Account is scheduled to close 3/23/2010; let me know if you need the file uploaded again). unzip the file, it contains the slapcat.out; a blank database (in a subfolder), and a slapd.conf file. 4) Edit the slapd.conf file as needed to point to the directory where you put the database. That was the setup, now here are the steps to reproduce the problem: 5) use slapadd -c -f slapd.conf -l slapcat.out to create the database. 6) start slapd (using slapd -d 1 -f slapd.conf) 7) use ldapbrowser to delete the "lcc=call center 1" node. It takes a long time, but eventually you'll see it fail while trying to delete the "agents" node.

1 0

Re: ITS#6475
by masarati＠aero.polimi.it 14 Mar '10

14 Mar '10

> <masarati(a)aero.polimi.it> wrote: > >> > access to * attrs=cmusaslsecretOTP >> > by dn.regex="cn=replica,o=test" write stop >> > by * break >> >> This is orthogonal to the sasl auxprops discussion. It's a matter of >> well-configuring the authorizing identity in slapo-chain(5). > > I pointed it here for future reference because this is an unusual case. > I suspect everyone configure replicas with universal read-only access. > For this to work, replica must also have write access to > cmusaslsecretOTP. Well, if a shadow uses slapo-chain(5), the producer must be configured in order to allow writes coming from the shadow. >> > Another point: bind on the replica is impossible when the master is >> > down. I understand this is to prevent replaying the same OTP on >> multiple >> > replicas, but that defeats the purpose of setting up replicas for fail >> > over. >> >> This was clearly pointed out at the beginning of the discussion. You >> can't have both, it should be clear. > > Yes, I understand that. > >> Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is >> used, OTP breaks. If it is acceptable to have it broken, we can remove >> the hardcoding, and let admins decide whether they prefer fail-over over >> consistency. I'd have no doubt, and favor consistency. > > When you tell about using the shadow copy, the modification will still > be sent to the master, right? Not in the original code. In that case, the modification was bypassing replication, thus it was being applied to the shadow without generating a referral. The alternative, inconsistent solution you seem to indicate would require to replay the modification as internal in case the modification to the producer failed because the service was not available. > Such a behavior allows replays attacks > within the modification propagation time frame, but it ensures that bind > are still possible when then master is down. I think it could be > interesting to have a configuration setting for that. We should bring this to -devel, to see whether it makes sense and whether it would be acceptable. p.

1 0

Re: ITS#6475
by manu＠netbsd.org 14 Mar '10

14 Mar '10

<masarati(a)aero.polimi.it> wrote: > > access to * attrs=cmusaslsecretOTP > > by dn.regex="cn=replica,o=test" write stop > > by * break > > This is orthogonal to the sasl auxprops discussion. It's a matter of > well-configuring the authorizing identity in slapo-chain(5). I pointed it here for future reference because this is an unusual case. I suspect everyone configure replicas with universal read-only access. For this to work, replica must also have write access to cmusaslsecretOTP. > > Another point: bind on the replica is impossible when the master is > > down. I understand this is to prevent replaying the same OTP on multiple > > replicas, but that defeats the purpose of setting up replicas for fail > > over. > > This was clearly pointed out at the beginning of the discussion. You > can't have both, it should be clear. Yes, I understand that. > Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is > used, OTP breaks. If it is acceptable to have it broken, we can remove > the hardcoding, and let admins decide whether they prefer fail-over over > consistency. I'd have no doubt, and favor consistency. When you tell about using the shadow copy, the modification will still be sent to the master, right? Such a behavior allows replays attacks within the modification propagation time frame, but it ensures that bind are still possible when then master is down. I think it could be interesting to have a configuration setting for that. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: ITS#6475
by masarati＠aero.polimi.it 14 Mar '10

14 Mar '10

> <masarati(a)aero.polimi.it> wrote: > >> Please test. p. > > It works, but needs to adjustement to the master ACL. My basic > configuration yield me this at OTP bind on replica: > ldap_sasl_interactive_bind_s: Bad parameter to an ldap routine (-9) > > replica slapd logs: > > conn=1001 op=0 RESULT tag=103 err=50 text= > SASL [conn=1001] Failure: Error putting OTP secret > send_ldap_result: conn=1001 op=0 p=3 > send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: > Error putting OTP secret" > > This has been fixed on the master, by adding this at the beginning of > the ACL: > > access to * attrs=cmusaslsecretOTP > by dn.regex="cn=replica,o=test" write stop > by * break This is orthogonal to the sasl auxprops discussion. It's a matter of well-configuring the authorizing identity in slapo-chain(5). > Another point: bind on the replica is impossible when the master is > down. I understand this is to prevent replaying the same OTP on multiple > replicas, but that defeats the purpose of setting up replicas for fail > over. This was clearly pointed out at the beginning of the discussion. You can't have both, it should be clear. > What about making the behavior configurable? Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is used, OTP breaks. If it is acceptable to have it broken, we can remove the hardcoding, and let admins decide whether they prefer fail-over over consistency. I'd have no doubt, and favor consistency. p.

1 0

Re: ITS#6475
by manu＠netbsd.org 14 Mar '10

14 Mar '10

<masarati(a)aero.polimi.it> wrote: > Please test. p. It works, but needs to adjustement to the master ACL. My basic configuration yield me this at OTP bind on replica: ldap_sasl_interactive_bind_s: Bad parameter to an ldap routine (-9) replica slapd logs: conn=1001 op=0 RESULT tag=103 err=50 text= SASL [conn=1001] Failure: Error putting OTP secret send_ldap_result: conn=1001 op=0 p=3 send_ldap_result: err=80 matched="" text="SASL(-1): generic failure: Error putting OTP secret" This has been fixed on the master, by adding this at the beginning of the ACL: access to * attrs=cmusaslsecretOTP by dn.regex="cn=replica,o=test" write stop by * break Another point: bind on the replica is impossible when the master is down. I understand this is to prevent replaying the same OTP on multiple replicas, but that defeats the purpose of setting up replicas for fail over. What about making the behavior configurable? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

(ITS#6490) dds and pcache overlays not checking NULL value
by etienne.bagnoud＠irovision.ch 10 Mar '10

10 Mar '10

Full_Name: Etienne Bagnoud Version: 2.4.11 and HEAD OS: Debian GNU/Linux 5.0.4 URL: http://www.tchetch.net/code/openldap/ Submission from: (NULL) (153.109.35.2) When sending a refresh request (RFC 2589) with an empty DN, the server segfault. This did work on default Debian installed version (slapd 2.4.11) as well as on the actual (today) version in HEAD. The actual return value returned by 'select_backend' is not checked for NULL value and passed directly to 'SLAP_DYNAMIC' macro. While digging through the code to find how others overlays where doing, if found that pcache has the same behavior. I can't test for that overlay (if the bug is corrected or not), but I suppose it's the same. So here are two patches to correct dds overlay and pcache overlay : - http://www.tchetch.net/code/openldap/servers-slapd-overlays-dds.patch - http://www.tchetch.net/code/openldap/servers-slapd-overlays-pcache.patch I'm not used to dig into openldap code (in fact, this is the first time), so I hope it's ok. Etienne.

1 0

(ITS#6489) Incomplete Master/Slave Replication
by Frank.Offermanns＠caseris.de 09 Mar '10

09 Mar '10

Full_Name: Frank Offermanns Version: 2.4.21 OS: Windwos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.189.242) I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am testing master/slave replication while adding 10000 users with 10 filled attributes. I am not using a specific time synchronization. Standard windows time synchronization in domains is active. But as far as I understood, a microsecond time synchronisation is only needed for master-master, which I am not testing. My problem is, that not every user and/or every attribute is replicated from my master to my slave. If the replicationmode is refreshAndPersist more entries are incorrect on the slave. When doing refreshOnly (every 5 mins) fewer entries have this problem. Switching to delta-syncrepl changes this behaviour. With delta-syncrepl once the intial content load has run, the replication seems to work 100%. But when I add entries while the inital content load (empty slave database) is running, a few complete users are missing (seems to be always a few in a row). But every written user has all attributes, so no missing attributes in this case. I will post my configuration (for refreshAndPersist replication). If you need any other info please let me known. Here my configurations: Master: ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/Personcaesar.schema include ./schema/ConfigObjects.schema loglevel 0 pidfile ./run/slapd.pid argsfile ./run/slapd.args access to * by dn.one="ou=Admins,o=caesar" write by * read ####################################################################### # BDB database definitions ####################################################################### database hdb cachesize 10000 idlcachesize 30000 suffix "" checkpoint 1024 5 rootdn "cn=Administrator,o=caesar" rootpw {SHA}secret... directory "c:/all2421/data" dbconfig set_cachesize 0 400000000 1 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 # Indices to maintain index sn pres,eq index cn pres,eq,sub index MasterApp pres,eq index RightVoice pres,eq index DCOMServer pres,eq index ExtensionSMS pres,eq index ExtensionFax pres,eq,sub index ExtensionVoice pres,eq,sub index ExtensionCTI pres,eq index Deleted pres,eq index GUID pres,eq index CTIServerName pres,eq,sub index LastSyncUser pres,eq index ApplicationPhoneNr pres,eq,sub index NetDialLoginName pres,eq index email pres,eq index FullExtensionVoice pres,eq,sub index FullExtensionFax pres,eq,sub index FullExtensionSMS pres,eq index FullName pres,eq index PersonalID pres,eq index entryUUID eq index entryCSN eq index objectClass eq overlay syncprov syncprov-checkpoint 1000 60 syncprov-sessionlog 10000 ________________________________________________ Slave: ucdata-path ./ucdata include ./schema/core.schema include ./schema/cosine.schema include ./schema/Personcaesar.schema include ./schema/ConfigObjects.schema loglevel 0 pidfile ./run/slapd.pid argsfile ./run/slapd.args access to * by dn.one="ou=Admins,o=caesar" write by * read ####################################################################### # BDB database definitions ####################################################################### database hdb cachesize 10000 idlcachesize 30000 suffix "" checkpoint 1024 5 rootdn "cn=Administrator,o=caesar" rootpw {SHA}secret.... directory "c:/all2421_48/data" dbconfig set_cachesize 0 400000000 1 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_regionmax 1048576 dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 # Indices to maintain index sn pres,eq index cn pres,eq,sub index MasterApp pres,eq index RightVoice pres,eq index DCOMServer pres,eq index ExtensionSMS pres,eq index ExtensionFax pres,eq,sub index ExtensionVoice pres,eq,sub index ExtensionCTI pres,eq index Deleted pres,eq index GUID pres,eq index CTIServerName pres,eq,sub index LastSyncUser pres,eq index ApplicationPhoneNr pres,eq,sub index NetDialLoginName pres,eq index email pres,eq index FullExtensionVoice pres,eq,sub index FullExtensionFax pres,eq,sub index FullExtensionSMS pres,eq index FullName pres,eq index PersonalID pres,eq index entryUUID eq index entryCSN eq index objectClass eq syncrepl rid=001 provider="ldap://CAS-WS091201.domain.local" searchbase="o=caesar" type=refreshAndPersist retry="5 3 15 +" binddn="cn=Administrator,o=caesar" bindmethod=simple credentials="secret" sizelimit size.soft=100 size.hard=1000 size.prtotal=unlimited limits dn.exact="cn=Administrator,o=caesar" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

1 0

Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org 08 Mar '10

08 Mar '10

The original patch compiled but didn't run correctly due to a function that was removed. A new patch that fixes this issue is at: http://hawking.cluenet.org/~crispy/nssov-nsspamldapd-update.patch

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by tjoen＠dds.nl 08 Mar '10

08 Mar '10

On Mon, 2010-03-08 at 16:19 +0000, korvus(a)comcast.net wrote: > After some chatter on the mailing list, the problem is now understood: > - TLS error messages are indeed reported by OpenLDAP: > TLS: could not use key file `/usr/local/etc/openldap/certs/ldap.key.pem'. ... > - The only way to see these error messages is to start the daemon with > '-d stats' ... > My suggestions: print the TLS error messages out to syslog, or if that's > not possible, print them to stdout regardless of whether the daemon is > running in the foreground or not. Isn't it in local4.* ?

1 0

Re: (ITS#6477) Clarify ambiguous TLS/SSL Errors in libldap/tls2c.
by korvus＠comcast.net 08 Mar '10

08 Mar '10

After some chatter on the mailing list, the problem is now understood: - TLS error messages are indeed reported by OpenLDAP: TLS: could not use key file `/usr/local/etc/openldap/certs/ldap.key.pem'. TLS: error:0200100D:system library:fopen:Permission denied /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:356 TLS: error:20074002:BIO routines:FILE_CTRL:system lib /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/bio/bss_file.c:358 TLS: error:140B0002:SSL routines:SSL_CTX_use_PrivateKey_file:system lib /usr/src/secure/lib/libssl/../../../crypto/openssl/ssl/ssl_rsa.c:648 - The only way to see these error messages is to start the daemon with '-d stats' -- Setting 'loglevel stats' in slapd.conf will not cause these error messages to be printed. They only appear if the daemon is started in foreground mode with '-d stats'. My suggestions: print the TLS error messages out to syslog, or if that's not possible, print them to stdout regardless of whether the daemon is running in the foreground or not.

1 0

(ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org 06 Mar '10

06 Mar '10

Full_Name: Chris Breneman Version: 2.4.21 OS: Debian Lenny URL: http://scalar.cluenet.org/~crispy/nssov-nsspamldapd-update.patch Submission from: (NULL) (98.212.227.43) The nssov overlay currently includes a very old version of the nss-ldapd (now nss-pam-ldapd) source. It's not necessary to keep a source tree of nss-pam-ldapd within openldap now, as the patches for pam_ldap support in the stub library were integrated upstream. This patch removes the nss-ldapd source tree from nssov, except for a few files which are unlikely to change, and on which nssov depends. This patch also updates nssov to support the newer versions of nss-pam-ldapd. There were some organizational changes, header changes, and changes of the names of constants since the version of nss-ldapd that is currently in the source. This patch also removes the dependence on the configure script of nss-ldapd. Currently, the configure script has to be run in the nss-ldapd subdirectory to generate a few constants which are needed by the parts of nss-ldapd that nssov depends on. These same constants are generated by the openldap configure script, and this patch changes the include path to include the relevant header from the openldap configure script, instead of requiring a separate configure script from nss-ldapd. This patch also updates the nssov Makefile to use the new nss-pam-ldapd files location and to create an install target that is separate from the all target. The README and man page are updated to reflect that nss-ldapd is no longer included in the source, and point to where to get it. They are also changed to reflect the new name of nss-ldapd: nss-pam-ldapd The patch is at: http://scalar.cluenet.org/~crispy/nssov-nsspamldapd-update.patch It applies on the nssov directory.

1 0

Re: (ITS#6486) OpenLDAP Admin Guide Backends Documentation
by hyc＠symas.com 05 Mar '10

05 Mar '10

ghenry(a)OpenLDAP.org wrote: > Thanks Ryan. > > I'll make sure this gets updated when I work through updating everything for cn=config syntax. > > Gavin. I already committed a patch to HEAD... http://www.openldap.org/lists/openldap-commit/201003/msg00007.html -- -- 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#6486) OpenLDAP Admin Guide Backends Documentation
by ghenry＠OpenLDAP.org 05 Mar '10

05 Mar '10

Thanks Ryan. I'll make sure this gets updated when I work through updating everything for cn=config syntax. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. 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