- openldap-bugs - openldap.org

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by hyc＠symas.com 09 Jan '08

09 Jan '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> daveh(a)coreng.com.au wrote: >>> As a followup, I should point out that this behaviour worked in at least >>> 2.2 and 2.3. >> Yes, I recall changing this in the 2.4 code; I guess I didn't update >> the manpage. > > Not sure which of this discussion should go where - I saw it first in > the ldap@umich list. But anyway, I suggest to revert that change. Hm... Where were you when we were originally discussing these changes? http://www.openldap.org/lists/openldap-devel/200611/msg00013.html http://www.openldap.org/lists/openldap-devel/200611/msg00022.html HEAD has been working this way for over a year, and it's clearly more correct in its behavior now than it was before. > If > anything, the LDIF RFC could be revised instead. This format has been > supported since umich ldap (before the LDIF RFC was written). That doesn't mean it has any relevance today; there's plenty of stuff UMich did that was long since deprecated. > Note that the format which OpenLDAP-2.4 ldapmodify reads is still not > LDIF, since "changetype:" defaults to modify instead of add. That's > incompatible with LDIF. OTOH default operation "replace:" for > changetype "modify" was compatible with LDIF, since LDIF does not > support a missing "add/delete/replace:" for changetype modify. > > Some history: > > - umich ldap-3.3 (1996): There were two LDIF defaults: Whether a missing > "changetype:" would default to "add" or "modify", and whether a > missing attribute operation type would default to "add" or "replace". > These were controlled by different flags: -a (or invoking as ldapadd) > for the first, -r (replace) for the second. > > - RFC 2849 - LDIF (2000): The defaults "changetype:modify" and > "replace:" were dropped, presumably because a file format could not > support command line options. > > - OpenLDAP 2.1 (2002): Removed the -r option and instead made it the > default when changetype was modify (and thus for ldapmodify). -r was > only used with ldapmodify and was usually what one wanted there. > (Note that "replace:" is equivalent to "add:" if the attribute does > not already exist in the entry.) It may be OK to revert this single aspect of the change. If you do so, just make sure that those other corner cases mentioned in the -devel thread are still handled correctly. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5315) Crash in ldap_parse_page_control
by rhafer＠suse.de 09 Jan '08

09 Jan '08

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.8.71.175) Applications using ldap_parse_page_control (e.g. nss_ldap) might crash. valgrind reports this: ==21971== Invalid write of size 8 ==21971== at 0x5BDFF04: ldap_parse_page_control (pagectrl.c:263) ==21971== by 0x599F170: do_result (ldap-nss.c:2511) ==21971== by 0x599F289: do_parse (ldap-nss.c:2844) ==21971== by 0x59A0245: _nss_ldap_getent_ex (ldap-nss.c:3413) [..] ==21971== Address 0x51fad38 is 0 bytes after a block of size 8 alloc'd ==21971== at 0x4C2460E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==21971== by 0x5E0652C: ber_memalloc_x (memory.c:226) ==21971== by 0x5BDFEEB: ldap_parse_page_control (pagectrl.c:259) ==21971== by 0x599F170: do_result (ldap-nss.c:2511) ==21971== by 0x599F289: do_parse (ldap-nss.c:2844) ==21971== by 0x59A0245: _nss_ldap_getent_ex (ldap-nss.c:3413) [..] Fix is on the way to HEAD.

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

hyc(a)symas.com writes: >daveh(a)coreng.com.au wrote: >> As a followup, I should point out that this behaviour worked in at least >> 2.2 and 2.3. > > Yes, I recall changing this in the 2.4 code; I guess I didn't update > the manpage. Not sure which of this discussion should go where - I saw it first in the ldap@umich list. But anyway, I suggest to revert that change. If anything, the LDIF RFC could be revised instead. This format has been supported since umich ldap (before the LDIF RFC was written). Note that the format which OpenLDAP-2.4 ldapmodify reads is still not LDIF, since "changetype:" defaults to modify instead of add. That's incompatible with LDIF. OTOH default operation "replace:" for changetype "modify" was compatible with LDIF, since LDIF does not support a missing "add/delete/replace:" for changetype modify. Some history: - umich ldap-3.3 (1996): There were two LDIF defaults: Whether a missing "changetype:" would default to "add" or "modify", and whether a missing attribute operation type would default to "add" or "replace". These were controlled by different flags: -a (or invoking as ldapadd) for the first, -r (replace) for the second. - RFC 2849 - LDIF (2000): The defaults "changetype:modify" and "replace:" were dropped, presumably because a file format could not support command line options. - OpenLDAP 2.1 (2002): Removed the -r option and instead made it the default when changetype was modify (and thus for ldapmodify). -r was only used with ldapmodify and was usually what one wanted there. (Note that "replace:" is equivalent to "add:" if the attribute does not already exist in the entry.) -- Regards, Hallvard

1 0

Re: (ITS#5313) Referral error
by ando＠sys-net.it 08 Jan '08

08 Jan '08

> Thank you so much. > > slapd or ldapadd should report a warning.. and not inform success: > "adding new entry "ou=domain1,o=Museu Goeldi"" No. What you added is a perfectly legitimate labeledURI, although not what you intended, where the URI is "ldap://<ip>/ou=domain1,o=Museu" and the label is "Goeldi"; there is no way (except a crystal ball) slapd can guess your intentions in this case. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by daveh＠coreng.com.au 08 Jan '08

08 Jan '08

On Tue, 8 Jan 2008, Howard Chu wrote: > Yes, I recall changing this in the 2.4 code; I guess I didn't update the > manpage. So it's officially dead? No worries; I've just finished converting the last of our legacy scripts. (I can see where you changed it in the source; should've checked that first...) -- Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by hyc＠symas.com 08 Jan '08

08 Jan '08

daveh(a)coreng.com.au wrote: > As a followup, I should point out that this behaviour worked in at least > 2.2 and 2.3. Yes, I recall changing this in the 2.4 code; I guess I didn't update the manpage. -- -- Howard Chu Chief Architect, 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#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by daveh＠coreng.com.au 08 Jan '08

08 Jan '08

As a followup, I should point out that this behaviour worked in at least 2.2 and 2.3.

1 0

Re: (ITS#5310) ppolicy
by mhardin＠symas.com 08 Jan '08

08 Jan '08

Hi Kevin, The ITS system is for reporting defects in OpenLDAP, and the symptoms you are describing are not indicative of that. The OpenLDAP team will probably close this ITS with a comment to that effect. The 'passwd' command is an OS tool, not part of OpenLDAP. Its interaction with OpenLDAP is through the pam_ldap module, and the conifguration of that module is most likely where your problem lies. I suggest posting this question on the pam_ldap mailing list that is operated by PADL, or requesting support from your OS vendor (RedHat?). Cheers, -Matt -- Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com khxie(a)directv.com wrote: > Full_Name: Kevin Xie > Version: 2.3.39 > OS: RHEL 4 update 3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (147.21.16.3) > > > I am testing ppolicy on OpenLDAP 2.3.39 and 2.3.38. > When user password expired, LDAP forced user to change password using "passwd", > it bypassed all the ppolicy settings, like, PwdMinLength, PwdInHistory. > Is there a way to force "passwd" to check LDAP ppolicy like "ldappasswd" does? > Is it because "passwd" and "ldappasswd" using different encryption methods? > > I've uploaded ppolicy and slapd.conf in khxie_ppolicy.txt. > I've google searched the issue and didn't find any anwser. > > Thanks for your help. > > Kevin Xie > > > . > >

1 0

(ITS#5314) slapd crashed in syncrepl and mirror mode when deleting entry
by savithri＠yahoo.com 08 Jan '08

08 Jan '08

Full_Name: Savithri Version: OpenLDAP 2.4.7 OS: SunOS 5.9 Generic_118558-08 sun4u sparc SUNW,Sun-Fire-V210 URL: ftp://ftp.openldap.org/incoming/savithri-pkg-080108.tar.gz Submission from: (NULL) (12.111.90.130) Hi, Im using fresh install of OpenLDAP 2.4.7 and using the mirrormode and syncrepl. My setup has 2 LDAP nodes, one as master and other as slave through a VIP. When the master goes down, the slave will become master and vice-versa. At any point to keep both the LDAP in sync I'm using mirror mode and syncrepl. When one node , say A is up (that is the active node) and the other node B is down, I delete some LDAP entry from node A. Then when i start node B, the slapd on node B crashes and a core file is generated. I have zipped the following files: 1. slapd.conf/s from both nodes (slapd.conf.node_A and slapd.conf.node_B ) 2. sample data ( sample_data.ldif ) 3. compile, run options ( build_run_option.txt) 4. the core file ( core) 5. log files from both the nodes A and B ( node_A_ldap.out and node_B_ldap.out) and have ftp the file "savithri-pkg-080108.tar.gz" to ftp://ftp.openldap.org/incoming/

1 0

Re: (ITS#5313) Referral error
by ando＠sys-net.it 08 Jan '08

08 Jan '08

reinaldoc(a)gmail.com wrote: > Full_Name: Reinaldo de Carvalho > Version: 2.3.30 > OS: Debian DNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (201.72.201.200) > > > #cat ref.ldif > dn: ou=domain1,o=Museu Goeldi > objectClass: referral > objectClass: extensibleObject > ref: ldap://10.0.0.2/ou=domain1,o=Museu Goeldi > ou: domain1 > > # ldapadd -x -D "cn=admin,o=Museu Goeldi" -w xxxxx -f ref.ldif > adding new entry "ou=domain1,o=Museu Goeldi" > > # ldapsearch -x -b "o=Museu Goeldi" -LLL 'ref=*' > # refldap://10.0.0.2/ou=domain1,o=Museu??sub > > OpenLdap return erroneous referral ou=domain1,o=Museu??sub Please read the specifications of the "ref" attribute. Its value is treated as an LDAP URI, optionally followed by a label; an LDAP URI, like all URIs, does not allow spaces, which must be escaped using "%20". Please fix your data. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5313) Referral error
by reinaldoc＠gmail.com 08 Jan '08

08 Jan '08

Full_Name: Reinaldo de Carvalho Version: 2.3.30 OS: Debian DNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (201.72.201.200) #cat ref.ldif dn: ou=domain1,o=Museu Goeldi objectClass: referral objectClass: extensibleObject ref: ldap://10.0.0.2/ou=domain1,o=Museu Goeldi ou: domain1 # ldapadd -x -D "cn=admin,o=Museu Goeldi" -w xxxxx -f ref.ldif adding new entry "ou=domain1,o=Museu Goeldi" # ldapsearch -x -b "o=Museu Goeldi" -LLL 'ref=*' # refldap://10.0.0.2/ou=domain1,o=Museu??sub OpenLdap return erroneous referral ou=domain1,o=Museu??sub

1 0

Re: (ITS#5311) Custom client searching cn=Monitor crashes SLAPD
by ando＠sys-net.it 08 Jan '08

08 Jan '08

Howard Chu wrote: > ando(a)sys-net.it wrote: >> I couldn't reproduce with a test (mostly unloaded) slapd. Since >> back-monitor dynamically builds the results based on the activity of >> slapd, the root cause could be related to the type of activity your >> slapd is doing (e.g. active connections, running operations and so). >> >> I don't have a FreeBSD at hand right now, could you post a "thread apply >> all bt" from gdb? I might need to ask for further core inspection >> with gdb. > > The tarball he posted has more information. You can see from the debug > output that the first search succeeds and the second fails. It's failing > while preparing the cn=Tasklist entry for output. In the first search, > it shows that the BDB checkpoint task is running. Very likely it's not > running in the second search, and the cn=Tasklist entry has been > corrupted in the subsequent update. However I haven't gotten far enough > to see how any corruption could happen or reproduce it. If you can pick > it up from these clues, I'll get back to other work... OK, thanks. I'll look at it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5311) Custom client searching cn=Monitor crashes SLAPD
by daveh＠coreng.com.au 08 Jan '08

08 Jan '08

On Tue, 8 Jan 2008, Pierangelo Masarati wrote: > I couldn't reproduce with a test (mostly unloaded) slapd. Since > back-monitor dynamically builds the results based on the activity of > slapd, the root cause could be related to the type of activity your > slapd is doing (e.g. active connections, running operations and so). Howard and I are already looking at this; sorry for not keeping you in the loop... -- Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

Re: (ITS#5311) Custom client searching cn=Monitor crashes SLAPD
by hyc＠symas.com 08 Jan '08

08 Jan '08

ando(a)sys-net.it wrote: > I couldn't reproduce with a test (mostly unloaded) slapd. Since > back-monitor dynamically builds the results based on the activity of > slapd, the root cause could be related to the type of activity your > slapd is doing (e.g. active connections, running operations and so). > > I don't have a FreeBSD at hand right now, could you post a "thread apply > all bt" from gdb? I might need to ask for further core inspection with gdb. The tarball he posted has more information. You can see from the debug output that the first search succeeds and the second fails. It's failing while preparing the cn=Tasklist entry for output. In the first search, it shows that the BDB checkpoint task is running. Very likely it's not running in the second search, and the cn=Tasklist entry has been corrupted in the subsequent update. However I haven't gotten far enough to see how any corruption could happen or reproduce it. If you can pick it up from these clues, I'll get back to other work... -- -- Howard Chu Chief Architect, 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#5311) Custom client searching cn=Monitor crashes SLAPD
by ando＠sys-net.it 08 Jan '08

08 Jan '08

daveh(a)coreng.com.au wrote: > Full_Name: Dave Horsfall > Version: 2.4.7 + ITS #5291 patch > OS: FreeBSD 6.2 > URL: http://www.horsfall.org/slapd-crash/ > Submission from: (NULL) (192.65.182.30) > > > We have a custom client called LGET (which is not much more than a fancy output > formatter based on the example code kicking around somewhere; I can provide the > source, but there's no way that it will compile anywhere but here) that reliably > crashes SLAPD when doing a search on "cn=Monitor". > > Example: > > lget -h localhost -b cn=monitor '(objectClass=*)' '*' > (May need to do this several times; it will crash eventually) > lget: Can't contact LDAP server > > slapd.log: > > Jan 8 10:37:33 mippet slapd[59883]: conn=14 fd=66 ACCEPT from > IP=127.0.0.1:52984 (IP=0.0.0.0:389) > Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH base="cn=monitor" scope=2 > deref=0 filter="(objectClass=*)" > Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH attr=* + Looking at the logs, it appears that it's also requesting '+'. > > This is sometimes followed by e.g.: > > Jan 8 10:39:29 mippet slapd[83101]: ch_malloc of 1195801456 bytes failed > > Although the debug shows traffic on the wire the client only shows a few blank > lines (but that's not really relevant). > > Debug output in "debug.out.gz", and GDB output in "gdb.out". I couldn't reproduce with a test (mostly unloaded) slapd. Since back-monitor dynamically builds the results based on the activity of slapd, the root cause could be related to the type of activity your slapd is doing (e.g. active connections, running operations and so). I don't have a FreeBSD at hand right now, could you post a "thread apply all bt" from gdb? I might need to ask for further core inspection with gdb. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by daveh＠coreng.com.au 07 Jan '08

07 Jan '08

Full_Name: Dave Horsfall Version: 2.4.7 + ITS #5291 patch OS: FreeBSD 6.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.65.182.30) The man page for ldapmodify(1) says that: If no "changetype:" line is present, the default is "add" if the -a flag is set (or if the program was invoked as ldapadd) and "modify" otherwise. If changetype is "modify" and no "add:", "replace:", or "delete:" lines appear, the default is "replace" for ldapmodify(1) and "add" for lda- padd(1). This appears to be incorrect in practice: LDIF: dn: cn=uidpool,dc=coreng,dc=com,dc=au objectClass: ciUID objectClass: top cn: uidpool ciNextUID: 12020 ciLastUID: 12999 Command (abridged): ldapmodify -x -W -H "ldap://ldap.exanple.com" -f LDIF Enter LDAP Password: ldapmodify: modify operation type is missing at line 2, entry "cn=uidpool,dc=example,dc=com"

1 0

(ITS#5311) Custom client searching cn=Monitor crashes SLAPD
by daveh＠coreng.com.au 07 Jan '08

07 Jan '08

Full_Name: Dave Horsfall Version: 2.4.7 + ITS #5291 patch OS: FreeBSD 6.2 URL: http://www.horsfall.org/slapd-crash/ Submission from: (NULL) (192.65.182.30) We have a custom client called LGET (which is not much more than a fancy output formatter based on the example code kicking around somewhere; I can provide the source, but there's no way that it will compile anywhere but here) that reliably crashes SLAPD when doing a search on "cn=Monitor". Example: lget -h localhost -b cn=monitor '(objectClass=*)' '*' (May need to do this several times; it will crash eventually) lget: Can't contact LDAP server slapd.log: Jan 8 10:37:33 mippet slapd[59883]: conn=14 fd=66 ACCEPT from IP=127.0.0.1:52984 (IP=0.0.0.0:389) Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH base="cn=monitor" scope=2 deref=0 filter="(objectClass=*)" Jan 8 10:37:33 mippet slapd[59883]: conn=14 op=0 SRCH attr=* + This is sometimes followed by e.g.: Jan 8 10:39:29 mippet slapd[83101]: ch_malloc of 1195801456 bytes failed Although the debug shows traffic on the wire the client only shows a few blank lines (but that's not really relevant). Debug output in "debug.out.gz", and GDB output in "gdb.out".

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by ando＠sys-net.it 07 Jan '08

07 Jan '08

Hallvard B Furuseth wrote: > I wrote: >> I think setkey() is more readable than setkey_x(). If anything, >> it already has too many arguments to be very readable. > > Er, I meant the old setkey(), with fewer arguments:-) Oh well, > it doesn't matter greatly either way. Unless - do we care about > binary compatibility with 2.4.7 libldap_r? I don't think so. It's not meant to be publicly linked. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

I wrote: > I think setkey() is more readable than setkey_x(). If anything, > it already has too many arguments to be very readable. Er, I meant the old setkey(), with fewer arguments:-) Oh well, it doesn't matter greatly either way. Unless - do we care about binary compatibility with 2.4.7 libldap_r? -- Hallvard

1 0

(ITS#5310) ppolicy
by khxie＠directv.com 07 Jan '08

07 Jan '08

Full_Name: Kevin Xie Version: 2.3.39 OS: RHEL 4 update 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (147.21.16.3) I am testing ppolicy on OpenLDAP 2.3.39 and 2.3.38. When user password expired, LDAP forced user to change password using "passwd", it bypassed all the ppolicy settings, like, PwdMinLength, PwdInHistory. Is there a way to force "passwd" to check LDAP ppolicy like "ldappasswd" does? Is it because "passwd" and "ldappasswd" using different encryption methods? I've uploaded ppolicy and slapd.conf in khxie_ppolicy.txt. I've google searched the issue and didn't find any anwser. Thanks for your help. Kevin Xie

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

Pierangelo Masarati writes: > Would it make any sense, at this point, to simply change the API of > setkey(), eliminating that spurious setkey_x()? I think setkey() is more readable than setkey_x(). If anything, it already has too many arguments to be very readable. -- Regards, Hallvard

1 0

Re: (ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by ando＠sys-net.it 07 Jan '08

07 Jan '08

h.b.furuseth(a)usit.uio.no wrote: > HEAD has gotten a new function ldap_pvt_thread_pool_setkey_x() replacing > ldap_pvt_thread_pool_setkey() (now a macro), but the change is incomplete. > Fixing thr_stub & thr_debug, they still define ldap_pvt_thread_pool_setkey. > > Related: overlays/memberof.c, pool_<getkey and setkey_x> should receive > a pointer to a void variable, not a (void **) cast of the address of a > non-void pointer variable. Otherwise a void* pointer gets stored in a > non-void* pointer instead of being converted to void. > > I'll combine another of memberof's getkey() followed by setkey() into > setkey_x() while I'm at it. > > Also making passwd.c:slap_passwd_check() and backend.c:be_rootdn_bind() > reentrant: Use setkey_x()/setkey() to push/pop the key=slap_sasl_bind > value instead of setkey()/setkey() to set/reset it. Would it make any sense, at this point, to simply change the API of setkey(), eliminating that spurious setkey_x()? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5309) ldap_pvt_thread_pool_setkey_x() addition
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard HEAD has gotten a new function ldap_pvt_thread_pool_setkey_x() replacing ldap_pvt_thread_pool_setkey() (now a macro), but the change is incomplete. Fixing thr_stub & thr_debug, they still define ldap_pvt_thread_pool_setkey. Related: overlays/memberof.c, pool_<getkey and setkey_x> should receive a pointer to a void variable, not a (void **) cast of the address of a non-void pointer variable. Otherwise a void* pointer gets stored in a non-void* pointer instead of being converted to void. I'll combine another of memberof's getkey() followed by setkey() into setkey_x() while I'm at it. Also making passwd.c:slap_passwd_check() and backend.c:be_rootdn_bind() reentrant: Use setkey_x()/setkey() to push/pop the key=slap_sasl_bind value instead of setkey()/setkey() to set/reset it.

1 0

(ITS#5308) test034-translucent crashes with back-ldif
by h.b.furuseth＠usit.uio.no 07 Jan '08

07 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard "./run -b ldif test034-translucent" crashes in str2entry2() at: entry.c:298: if( ad_prev->ad_type->sat_equality && because ad_prev == NULL - which got through due to this statement: entry.c:278: if (( ad_prev && ad != ad_prev ) || ( i == lines )) { (gdb) backtrace full #0 0x080778b9 in str2entry2 (s=0x0, checkvals=1) at entry.c:298 j = 0 k = 0 rc = 0 e = (Entry *) 0x1bca12d4 type = (struct berval *) 0x1bc4af40 vals = (struct berval *) 0x1bc4af50 nvals = (struct berval *) 0x1bc4af60 freeval = 0x1bc4af70 "" ad = (AttributeDescription *) 0x1bc4b100 ad_prev = (AttributeDescription *) 0x0 text = 0x819642b "attribute type undefined" next = 0x1bc4af0d "" attr_cnt = 0 i = 0 lines = 0 ahead = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x8189305, a_numvals = 465874688, a_flags = 477302072, a_next = 0x1bcabc2c, a_comp_data = 0x0} atail = (Attribute *) 0x1bcabc2c #1 0x08076c28 in str2entry (s=0x1bc4af00 "dn") at entry.c:100 No locals. #2 0x0810084a in get_entry_for_fd (fd=12, pdn=0x1c730de4, pndn=0x1c730ddc) at ldif.c:339 entry = 0x1bc4af00 "dn" ldentry = (Entry *) 0x0 #3 0x08100a99 in get_entry (op=0x1bb0bc30, base_path=0x1bc315b0) at ldif.c:379 path = {bv_len = 100, bv_val = 0x1bc4adc8 "/usit/bombur/site/hbf/scratch/ldap/ol/HEAD/tests/testrun/db.2.a/o=translucent/ou=users/uid=fred.ldif"} pdn = {bv_len = 22, bv_val = 0x1bd2c185 "ou=users,o=translucent"} pndn = {bv_len = 22, bv_val = 0x1bd2c1e5 "ou=users,o=translucent"} fd = 12 #4 0x081018f1 in ldif_back_referrals (op=0x1bb0bc30, rs=0x1c731138) at ldif.c:719 li = (struct ldif_info *) 0x1bc315b0 entry = (Entry *) 0x1c730fc8 rc = 0 #5 0x080e1c31 in overlay_op_walk (op=0x1bb0bc30, rs=0x1c731138, which=op_aux_chk_referrals, oi=0x1bc31e80, on=0x0) at backover.c:653 func = (BI_op_bind **) 0x81dc15c rc = 32768 #6 0x080e1de6 in over_op_func (op=0x1bb0bc30, rs=0x1c731138, which=op_aux_chk_referrals) at backover.c:705 oi = (slap_overinfo *) 0x1bc31e80 on = (slap_overinst *) 0x1bc31fb0 be = (BackendDB *) 0x1bc31470 db = {bd_info = 0x81dc130, be_ctrls = '\0' <repeats 18 times>, "\001", '\0' <repeats 13 times>, "\001", be_flags = 259, 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 = 0x1bc31a18, be_nsuffix = 0x1bc31a58, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 13, bv_val = 0x1bc31cf8 "o=translucent"}, be_rootndn = {bv_len = 13, bv_val = 0x1bc31d80 "o=translucent"}, be_rootpw = {bv_len = 6, bv_val = 0x1bc31e00 "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 = 0x1bb23530, be_pcl_mutex = { wrapped = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 2, __m_lock = {__status = 0, __spinlock = 0}}, usage = { magic = ldap_debug_magic, self = 3829197487, mem = {ptr = 0x0, num = 0}, state = ldap_debug_state_inited}, owner = 4294967295}, be_pcl_mutexp = 0x1bc31538, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x81deca0, be_private = 0x1bc315b0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x80e10c3 <over_back_response>, sc_cleanup = 0, sc_private = 0x1bc31e80} rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #7 0x080e1fbe in over_aux_chk_referrals (op=0x1bb0bc30, rs=0x1c731138) at backover.c:787 No locals. #8 0x0807c586 in backend_check_referrals (op=0x1bb0bc30, rs=0x1c731138) at backend.c:1301 No locals. #9 0x0808b143 in fe_op_modrdn (op=0x1bb0bc30, rs=0x1c731138) at modrdn.c:274 newSuperior_be = (Backend *) 0x0 pdn = {bv_len = 0, bv_val = 0x0} op_be = (BackendDB *) 0x1bc31470 bd = (BackendDB *) 0x81e3aa0 #10 0x0808acb3 in do_modrdn (op=0x1bb0bc30, rs=0x1c731138) at modrdn.c:186 dn = {bv_len = 31, bv_val = 0x1bc4abe7 "uid=fred,ou=users,o=translucent"} newrdn = {bv_len = 11, bv_val = 0x1bc4ac08 "uid=someguy"} newSuperior = {bv_len = 0, bv_val = 0x0} deloldrdn = 0 pnewSuperior = {bv_len = 0, bv_val = 0x0} nnewSuperior = {bv_len = 0, bv_val = 0x0} length = 0 #11 0x0806b483 in connection_operation (ctx=0x1c731214, arg_v=0x1bb0bc30) at connection.c:1083 rc = 80 op = (Operation *) 0x1bb0bc30 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 108 opidx = SLAP_OP_MODRDN conn = (Connection *) 0x1be539e0 memctx = (void *) 0x1bb0c048 memctx_null = (void *) 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #12 0x0806b943 in connection_read_thread (ctx=0x1c731214, argv=0x9) at connection.c:1210 rc = 0 cri = {op = 0x1bb0bc30, func = 0, arg = 0x0, ctx = 0x1c731214, nullop = 0} s = 9 #13 0x08144a1c in ldap_int_thread_pool_wrapper (xpool=0x1bb50e30) at tpool.c:625 pool = (struct ldap_int_thread_pool_s *) 0x1bb50e30 task = (ldap_int_thread_task_t *) 0x1bb24400 ctx = {ltu_id = 477305760, ltu_key = {{ltk_key = 0x806b05d, ltk_data = 0x1bb778b0, ltk_free = 0x806aefe <conn_counter_destroy>}, { ltk_key = 0x80cb901, ltk_data = 0x1bb0c048, ltk_free = 0x80cb738 <slap_sl_mem_destroy>}, {ltk_key = 0x8082923, ltk_data = 0x0, ltk_free = 0x80828a0 <slap_op_q_destroy>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 29 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 426 hash = 5776810 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #14 0x00a633cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #15 0x008cb1ae in clone () from /lib/tls/libc.so.6 No symbol table info available.

1 0

Re: (ITS#5291) Client timeout dumps core
by hyc＠symas.com 06 Jan '08

06 Jan '08

daveh(a)coreng.com.au wrote: > FWIW, I back-ported the fix (1.81 in libraries/libldap/search.c) to 2.4.7, > and it works fine (both the test harness and my application). > > Many thanks. > Thanks for the followup. We'll make sure the fix is in 2.4.8. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs