openldap-bugs June 2011

openldap-bugs@openldap.org

35 participants
131 discussions

Re: (ITS#6892) Segfault in Syncprov overlay
by ghola＠rebelbase.com 10 Jun '11

10 Jun '11

> A patch to avoid this particular crash is now in git master. However, it's still not clear to me why it occurred. Can you get this info from gdb: > frame 1 > print *ss Thanks Howard, here is the info you requested: (gdb) bt #0 test_filter (op=0x40fff7f0, e=0x2aab116ab068, f=0x0) at filterentry.c:69 #1 0x00000000004db315 in syncprov_matchops (op=0x410001b0, opc=0xb096e0, saveit=1) at syncprov.c:1314 #2 0x00000000004db6b5 in syncprov_op_mod (op=0x410001b0, rs=<value optimized out>) at syncprov.c:2124 #3 0x000000000047e62a in overlay_op_walk (op=0x410001b0, rs=0x40ffffc0, which=op_modify, oi=0x8d7ab0, on=0x8dc4f0) at backover.c:659 #4 0x000000000047ec07 in over_op_func (op=0x410001b0, rs=0x40ffffc0, which=op_modify) at backover.c:721 #5 0x000000000047404d in syncrepl_updateCookie (si=0x8d74d0, op=0x410001b0, syncCookie=0x41000b20) at syncrepl.c:3292 #6 0x0000000000478462 in do_syncrep2 (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1097 #7 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at syncrepl.c:1455 #8 0x00000000004ec5ec in ldap_int_thread_pool_wrapper (xpool=0x84daf0) at tpool.c:685 #9 0x000000301b20673d in start_thread (arg=<value optimized out>) at pthread_create.c:301 #10 0x000000301aad44bd in clone () from /lib64/libc.so.6 (gdb) frame 1 #1 0x00000000004db315 in syncprov_matchops (op=0x410001b0, opc=0xb096e0, saveit=1) at syncprov.c:1314 1314 rc = test_filter( &op2, e, op2.ors_filter ); (gdb) print *ss $1 = {s_next = 0x2aab502177f0, s_base = {bv_len = 16, bv_val = 0x2aab730920e0 "dc=test12,dc=net"}, s_eid = 1, s_op = 0x230ea90, s_rid = 1, s_sid = -1, s_filterstr = {bv_len = 15, bv_val = 0x230f7d0 "(objectClass=*)"}, s_flags = 1, s_inuse = 1, s_res = 0x2aababca90f0, s_restail = 0x2aabc320d920, s_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}}

1 0

(ITS#6969) Need option to show which TLS library is in use
by hyc＠OpenLDAP.org 10 Jun '11

10 Jun '11

Full_Name: Howard Chu Version: 2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc Now that OpenSSL is not the only TLS library that we support, app developers need a way to check which library is in use. libldap has the info, but due to an oversight it was not exposed. The LDAP_OPT_X_TLS_PACKAGE option has been added to retrieve the TLS implementation name. Currently it may be "OpenSSL", "GnuTLS", or "MozNSS".

1 0

Re: (ITS#6968) Glue objectclass created during Grouper provisioning
by hyc＠symas.com 10 Jun '11

10 Jun '11

Mark.Cairney(a)ed.ac.uk wrote: > Full_Name: Mark Cairney > Version: 2.4.25 > OS: RHEL 5.5 x64 > URL: ftp://ftp.ed.ac.uk/incoming/Mark-Cairney-110610.zip > Submission from: (NULL) (129.215.200.77) > > > During provisioning using Grouper (http://www.internet2.edu/grouper) to populate > a tree of ou and posixGroup objects it looks like the request to create a child > OU is being issued and granted. > This results in the creation of a "ghost" parent OU with the glue objectClass as > documented but syncrepl then constantly tries and fails to provision the ghost > OU to the other servers (as shown in alderlog.txt). Your ftp server is demanding authentication, can't download your file. > My cn=config is listed in cnconfig.txt for reference > > The issue can be reproduced by running Grouper's LDAP provisioner with Grouper > configured to produce a "bushy" structure and it may also be reproduceable if > provisioning via a suitable large LDIF file (grouper.ldif). Sorry, I'm not going to install grouper to test this bug. Please provide scripts to generate data that will reproduce the bug, and please do not use any 3rd party schemas in the data, that just makes it harder to setup a test environment. -- -- 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#6968) Glue objectclass created during Grouper provisioning
by Mark.Cairney＠ed.ac.uk 10 Jun '11

10 Jun '11

Full_Name: Mark Cairney Version: 2.4.25 OS: RHEL 5.5 x64 URL: ftp://ftp.ed.ac.uk/incoming/Mark-Cairney-110610.zip Submission from: (NULL) (129.215.200.77) During provisioning using Grouper (http://www.internet2.edu/grouper) to populate a tree of ou and posixGroup objects it looks like the request to create a child OU is being issued and granted. This results in the creation of a "ghost" parent OU with the glue objectClass as documented but syncrepl then constantly tries and fails to provision the ghost OU to the other servers (as shown in alderlog.txt). My cn=config is listed in cnconfig.txt for reference The issue can be reproduced by running Grouper's LDAP provisioner with Grouper configured to produce a "bushy" structure and it may also be reproduceable if provisioning via a suitable large LDIF file (grouper.ldif).

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by hyc＠symas.com 10 Jun '11

10 Jun '11

Daniel Pluta wrote: > Howard Chu wrote: >> daniel at pluta.biz wrote: >>> Please also have a look into the might be related patch, submitted in >>> ITS#6912 which addresses normalization of auth(c|z)Id of the form >>> "u:xxx" in general. Thank you very much. >> >> I see no bug here. The backslash was properly escaped, using the normal >> escaping rules for LDAP DNs. >> > > Yeah, you are right, but ... ;-) > ... I'm perhaps too. So please let me try to explain: > > The backslash is syntactically correct escaped (under the assumtion that > the string is indeed a "LDAP DN"). > > In my opinion authz-regexp (a slapd-config-statement string) completely > or partly does not always represent a "LDAP DN". It's quite often more > or less a combination of > > LDAP URI + optional regex + its optional expansions > > which probably should not be treated in general (especially in regard to > normalization) like a LDAP DN. > > This has led me to the submitted patch in ITS#6912 where I assume that > in contrast to authDN-normalization, the normalization of authIDs > (u:xxxx) in general is probably quite problematic, too... > > I'm aware that LDAP DNs need to be normalized in general, but I do not > understand why authcIDs or authz-regexp-expansions should need to be > normalized in general, too. > The authz-regexp expansion does not "need" to be normalized. But it is fed a DN, and that DN is normalized before any further processing, so if you want to match it, you must use the proper normalized string in your regexp: use "\\5C" instead of "\\". Next time send your usage questions to the -technical mailing list. This ITS is closed. -- -- 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#6887) authz-regexp: backslash escaping/normalization
by daniel＠pluta.biz 10 Jun '11

10 Jun '11

Howard Chu wrote: > daniel at pluta.biz wrote: >> Please also have a look into the might be related patch, submitted in >> ITS#6912 which addresses normalization of auth(c|z)Id of the form >> "u:xxx" in general. Thank you very much. > > I see no bug here. The backslash was properly escaped, using the normal > escaping rules for LDAP DNs. > Yeah, you are right, but ... ;-) ... I'm perhaps too. So please let me try to explain: The backslash is syntactically correct escaped (under the assumtion that the string is indeed a "LDAP DN"). In my opinion authz-regexp (a slapd-config-statement string) completely or partly does not always represent a "LDAP DN". It's quite often more or less a combination of LDAP URI + optional regex + its optional expansions which probably should not be treated in general (especially in regard to normalization) like a LDAP DN. This has led me to the submitted patch in ITS#6912 where I assume that in contrast to authDN-normalization, the normalization of authIDs (u:xxxx) in general is probably quite problematic, too... I'm aware that LDAP DNs need to be normalized in general, but I do not understand why authcIDs or authz-regexp-expansions should need to be normalized in general, too.

1 0

Re: (ITS#6892) Segfault in Syncprov overlay
by hyc＠symas.com 10 Jun '11

10 Jun '11

ghola(a)rebelbase.com wrote: > Full_Name: Duncan Idaho > Version: 2.4.25 > OS: RHEL 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (204.10.36.147) > > > In my configuration slapd segfaults within a few hours repeatably when a NULL > value is somehow passed as a filter to test_filter in the syncprov overlay. > > I'm running "threads 64" as I have 62 consumers connecting and this was required > to prevent unrelated searches from timing out when all the consumers connect at > once. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x59832940 (LWP 2042)] > test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69 > 69 if ( f->f_choice& SLAPD_FILTER_UNDEFINED ) { > (gdb) bt > #0 test_filter (op=0x59830770, e=0x2aab11861068, f=0x0) at filterentry.c:69 > #1 0x00000000004db315 in syncprov_matchops (op=0x59831130, opc=0xbc91750, > saveit=1) at syncprov.c:1314 > #2 0x00000000004db6b5 in syncprov_op_mod (op=0x59831130, rs=<value optimized > out>) at syncprov.c:2124 > #3 0x000000000047e62a in overlay_op_walk (op=0x59831130, rs=0x59830f40, > which=op_modify, oi=0x8d7b50, on=0x8dc540) at backover.c:659 > #4 0x000000000047ec07 in over_op_func (op=0x59831130, rs=0x59830f40, > which=op_modify) at backover.c:721 > #5 0x000000000047404d in syncrepl_updateCookie (si=0x8d74e0, op=0x59831130, > syncCookie=0x59831aa0) at syncrepl.c:3292 > #6 0x0000000000479d0d in do_syncrep2 (ctx=<value optimized out>, arg=<value > optimized out>) at syncrepl.c:959 > #7 do_syncrepl (ctx=<value optimized out>, arg=<value optimized out>) at > syncrepl.c:1455 > #8 0x000000000041f7aa in connection_read_thread (ctx=0x59831d70, argv=<value > optimized out>) at connection.c:1251 > #9 0x00000000004ec5ec in ldap_int_thread_pool_wrapper (xpool=0x84de50) at > tpool.c:685 > #10 0x000000301b20673d in start_thread (arg=<value optimized out>) at > pthread_create.c:301 > #11 0x000000301aad44bd in clone () from /lib64/libc.so.6 > > Let me know if I can provide more info. A patch to avoid this particular crash is now in git master. However, it's still not clear to me why it occurred. Can you get this info from gdb: frame 1 print *ss -- -- 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#6967) bug when migrating to cn=config with mixed-case schema names
by hyc＠symas.com 10 Jun '11

10 Jun '11

seth(a)energysec.org wrote: > Full_Name: Seth B. > Version: 2.4.25 > OS: Ubuntu > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.37.253.46) > > > I moved from slapd.conf to cn=config using options -F and -f (forgot the exact > command but I think it was slapadd). I had a schema called EnergySec.ldif that > was migrated. It showed up as > /usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}EnergySec.ldif > following the conversion. > > However, when I tried modifying the schema using ADS and then ldapmodify, I > would get a error 32: No such object. With slapd in foreground mode, I found > that it was trying to access the lower-case version of the file: > > ldif_read_file: no entry file > "/usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}energysec.ldif" > > Since UNIX is case-sensitive, this obviously failed (the import kept the case as > EnergySec.ldif). > > I fixed it by manually renaming the ldif file to lower case and changing the dn > and cn inside the file. That was pretty hairy and I hope I didn't break anything > else but it semes to work. Thanks for the report, this is now fixed in git master. -- -- 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#6967) bug when migrating to cn=config with mixed-case schema names
by seth＠energysec.org 09 Jun '11

09 Jun '11

Full_Name: Seth B. Version: 2.4.25 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.37.253.46) I moved from slapd.conf to cn=config using options -F and -f (forgot the exact command but I think it was slapadd). I had a schema called EnergySec.ldif that was migrated. It showed up as /usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}EnergySec.ldif following the conversion. However, when I tried modifying the schema using ADS and then ldapmodify, I would get a error 32: No such object. With slapd in foreground mode, I found that it was trying to access the lower-case version of the file: ldif_read_file: no entry file "/usr/local/etc/openldap/slapd.d/cn=config/cn=schema/cn={5}energysec.ldif" Since UNIX is case-sensitive, this obviously failed (the import kept the case as EnergySec.ldif). I fixed it by manually renaming the ldif file to lower case and changing the dn and cn inside the file. That was pretty hairy and I hope I didn't break anything else but it semes to work.

1 0

Re: (ITS#6887) authz-regexp: backslash escaping/normalization
by hyc＠symas.com 09 Jun '11

09 Jun '11

daniel(a)pluta.biz wrote: > Please also have a look into the might be related patch, submitted in > ITS#6912 which addresses normalization of auth(c|z)Id of the form > "u:xxx" in general. Thank you very much. I see no bug here. The backslash was properly escaped, using the normal escaping rules for LDAP DNs. -- -- 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

← Newer
1
...
4
5
6
7
8
9
10
...
14
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2011