- openldap-bugs - openldap.org

Re: (ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by michael＠stroeder.com 17 Oct '08

17 Oct '08

Frank.Swasey(a)uvm.edu wrote: > On 10/16/08 8:12 AM, ando(a)sys-net.it wrote: >> The ITS is polluted by issues opened, considered by developers, and pending >> feedback since ever. I suggest the ITS automatically closes issues not fed back >> after a reasonable amount of time. Closed issues can always be re-opened if >> issueers wake up and respond. > > As a user... I would completely agree with this and suggest that 30 days > is a "reasonable amount of time" Although I try to keep up with testing sometimes 30 days could be a little bit short. Anyway I wonder what the state "Feedback" really means. I've checked if there are still open issues in this state submitted by me. The only one seems to be ITS#5574, but I can't resolve this since assigning the official OID needed in this case is not something I can do. I could only test something and give feedback. Ciao, Michael.

1 0

Re: (ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by Frank.Swasey＠uvm.edu 16 Oct '08

16 Oct '08

On 10/16/08 8:12 AM, ando(a)sys-net.it wrote: > The ITS is polluted by issues opened, considered by developers, and pending > feedback since ever. I suggest the ITS automatically closes issues not fed back > after a reasonable amount of time. Closed issues can always be re-opened if > issueers wake up and respond. > > As a user... I would completely agree with this and suggest that 30 days is a "reasonable amount of time" -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

(ITS#5744) Automatically close issues when no feedback is received within a reasonable time
by ando＠sys-net.it 16 Oct '08

16 Oct '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) The ITS is polluted by issues opened, considered by developers, and pending feedback since ever. I suggest the ITS automatically closes issues not fed back after a reasonable amount of time. Closed issues can always be re-opened if issueers wake up and respond. p.

1 0

Re: (ITS#5740) slapd-tester fails on windows
by ando＠sys-net.it 16 Oct '08

16 Oct '08

----- quanah(a)zimbra.com wrote: > > Could it be because liblutil comes after liblber? > > Yep, putting liblber after liblutil, things finish. The error seems to be the dependence of liblutil on ber memory routines. What memory routines is liblutil supposed to use, then? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5740) slapd-tester fails on windows
by quanah＠zimbra.com 15 Oct '08

15 Oct '08

--On Wednesday, October 15, 2008 4:05 PM +0000 ando(a)sys-net.it wrote: > > ----- quanah(a)zimbra.com wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.12 >> OS: Windows XP >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> gcc -g -O2 -o .libs/slapd-tester slapd-tester.o slapd-common.o >> -L/opt/zimbra/bdb-4.6.21.3/lib -L/opt/zimbra/openssl-0.9.8h/lib >> ../../libraries/libldap/.libs/libldap.dll.a >> /home/quanah/openldap-2.4.12/libraries/liblber/.libs/liblber.dll.a >> ../../libraries/liblber/.libs/liblber.dll.a >> ../../libraries/liblutil/liblutil.a > > Could it be because liblutil comes after liblber? Yep, putting liblber after liblutil, things finish. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5740) slapd-tester fails on windows
by ando＠sys-net.it 15 Oct '08

15 Oct '08

----- quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.12 > OS: Windows XP > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > gcc -g -O2 -o .libs/slapd-tester slapd-tester.o slapd-common.o > -L/opt/zimbra/bdb-4.6.21.3/lib -L/opt/zimbra/openssl-0.9.8h/lib > ../../libraries/libldap/.libs/libldap.dll.a > /home/quanah/openldap-2.4.12/libraries/liblber/.libs/liblber.dll.a > ../../libraries/liblber/.libs/liblber.dll.a > ../../libraries/liblutil/liblutil.a Could it be because liblutil comes after liblber? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5743) SIGSEGV in ldapsearch
by ando＠sys-net.it 15 Oct '08

15 Oct '08

Full_Name: Pierangelo Masarati Version: re24 OS: CentOS 5.2 on i386 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.6) Submitted by: ando While chasing referrals (-C) to non-responding hosts (see also ITS#5742, unrelated but same scenario), I got the following: #0 0x0084b402 in __kernel_vsyscall () #1 0x00c9ad20 in raise () from /lib/libc.so.6 #2 0x00c9c631 in abort () from /lib/libc.so.6 #3 0x00c9416b in __assert_fail () from /lib/libc.so.6 #4 0x0807e58b in ber_sockbuf_ctrl (sb=0x0, opt=19658, arg=0x0) at sockbuf.c:88 #5 0x0805672a in try_read1msg (ld=0x90502a8, msgid=8, all=1, lcp=0xbf8957c8, result=0xbf895820) at result.c:1190 #6 0x08057952 in ldap_result (ld=0x90502a8, msgid=8, all=1, timeout=0xbf895810, result=0xbf895820) at result.c:402 #7 0x08064635 in ldap_new_connection (ld=0x90502a8, srvlist=0xbf895904, use_ldsb=0, connect=1, bind=0xbf8958f0) at request.c:501 #8 0x08064b2d in ldap_send_server_request (ld=0x90502a8, ber=0x905ab20, msgid=7, parentreq=0x90594d8, srvlist=0xbf895904, lc=0x0, bind=0xbf8958f0) at request.c:207 #9 0x08065acc in ldap_chase_v3referrals (ld=0x90502a8, lr=0x905a7c0, refs=0x905aa50, sref=1, errstrp=0x905a7e4, hadrefp=0xbf895a1c) at request.c:1139 #10 0x08056a6d in try_read1msg (ld=0x90502a8, msgid=6, all=1, lcp=0xbf895a88, result=0xbf895ae0) at result.c:729 #11 0x08057952 in ldap_result (ld=0x90502a8, msgid=6, all=1, timeout=0xbf895ad0, result=0xbf895ae0) at result.c:402 #12 0x08064635 in ldap_new_connection (ld=0x90502a8, srvlist=0xbf895bc4, use_ldsb=0, connect=1, bind=0xbf895bb0) at request.c:501 #13 0x08064b2d in ldap_send_server_request (ld=0x90502a8, ber=0x905b7f8, msgid=5, parentreq=0x90594d8, srvlist=0xbf895bc4, lc=0x0, bind=0xbf895bb0) at request.c:207 #14 0x08065acc in ldap_chase_v3referrals (ld=0x90502a8, lr=0x905a7c0, refs=0x905a8f0, sref=1, errstrp=0x905a7e4, hadrefp=0xbf895cdc) at request.c:1139 #15 0x08056a6d in try_read1msg (ld=0x90502a8, msgid=-1, all=0, lcp=0xbf895d48, result=0xbf895ff8) at result.c:729 #16 0x08057952 in ldap_result (ld=0x90502a8, msgid=-1, all=0, timeout=0x0, result=0xbf895ff8) at result.c:402 #17 0x0804b362 in dosearch (ld=0x90502a8, base=0x904f180 "dc=ericsson,dc=com", scope=2, filtpatt=0x0, value=0x10 <Address 0x10 out of bounds>, attrs=0x0, attrsonly=0, sctrls=0x0, cctrls=0x0, timeout=0x0, sizelimit=-1) at ldapsearch.c:1198 #18 0x0804d3ce in main (argc=Cannot access memory at address 0x4cca ) at ldapsearch.c:1031 Frame #4 clearly shows that ber_sockbuf_ctrl() is passed a null sb, which is lc->lconn_sb. I could not track, right now, where that pointer was zeroed out. I have binary and core available, if anything is needed. What I'm missing right now is time and connectivity (via ssh, and most of the time via http). p.

1 0

(ITS#5742) slapo-chain(5) causes sigsegv when unable to chase a search reference
by ando＠sys-net.it 15 Oct '08

15 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.6) Submitted by: ando In fact, it clears out sr_entry without honoring MUSTRELEASE. Note that slap_send_search_reference() does not check for non-NULL sr_entry all times it is used. A fix is coming... p.

1 0

(ITS#5741) Entry Read Control parsing broken
by ando＠sys-net.it 15 Oct '08

15 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.7) Submitted by: ando Parsing does not allow non-attribute AttributeSpecification ('*', '+', '1.1') in PreRead, while it's broken in PostRead- Does not allow '@<objectClass>' form (not allowed by RFC 4527, AFAIK, but could be an OpenLDAP extension?). A fix is coming... p.

1 0

(ITS#5740) slapd-tester fails on windows
by quanah＠zimbra.com 15 Oct '08

15 Oct '08

Full_Name: Quanah Gibson-Mount Version: 2.4.12 OS: Windows XP URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) gcc -g -O2 -o .libs/slapd-tester slapd-tester.o slapd-common.o -L/opt/zimbra/bdb-4.6.21.3/lib -L/opt/zimbra/openssl-0.9.8h/lib ../../libraries/libldap/.libs/libldap.dll.a /home/quanah/openldap-2.4.12/libraries/liblber/.libs/liblber.dll.a ../../libraries/liblber/.libs/liblber.dll.a ../../libraries/liblutil/liblutil.a -lssl -lcrypto -lregex -lws2_32 -L/opt/zimbra/openldap-2.4.12/lib ../../libraries/liblutil/liblutil.a(utils.o): In function `lutil_str2bin': C:/Local/msys/1.0/home/quanah/openldap-2.4.12/libraries/liblutil/utils.c:817: undefined reference to `_imp__ber_memfree_x' C:/Local/msys/1.0/home/quanah/openldap-2.4.12/libraries/liblutil/utils.c:770: undefined reference to `_imp__ber_memalloc_x'

1 0

Re: (ITS#5731) Don't rewrite filter when it is undefined
by ando＠sys-net.it 14 Oct '08

14 Oct '08

----- kouk(a)noc.uoa.gr wrote: > On Thu, 09 Oct 2008 23:45:42 +0300, <ando(a)sys-net.it> wrote: > > > The bug is confirmed; the proposed fix is incorrect, since it only > > addresses the case of a(n undefined) simple filter. A more complete > fix > > (see also ITS#5732) is in HEAD, please test. p. > > OK, I tested it and indeed it doesn't crash anymore. But I have a > question > regarding the fix in HEAD. When an undefined filter is supplied by the > > client, what is the intended behavior? From what I can tell the > current > (HEAD) behavior is that it is ignored (as false?). This is different > from > the previous behavior where, as I remember, an undefined filter error > was > reported to the client. AFAIK, the correct behavior is to ignore the filter if it is undefined. Nothing has to be reported to the client. If it occurred earlier, it was an error. > Also from my tests with HEAD it seems that when the rwm overlay is > present > the implemented fix's check for an undefined filter will produce a > filter > semantically equivalent to false, "(!(objectClass=*))", which slapd > will > then procede to match against every entry under the base DN. This is > > different than what happens in HEAD (and in 2.4.11) without the rwm > overlay, which is that the entries aren't even considered. When the filter is undefined, it is ignored. In fact, if a filter is "(|(cn=*)(foo=bar))" and attribute "foo" does not exist, the filter reduces to "(cn=*)". However, when the remapped filter needs to be passed to ldap_search() in string form, an undefined filter needs to be rewritten in LDAP form. I decided to rework it into "(!(objectClass=*))" just because it was easier. A better solution would probably have been to handle it along the above lines. Call it laziness, if you like. Feel free to propose a better solution. Better if you provide a patch, though :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5734) Serch limits by baseDN
by h.b.furuseth＠usit.uio.no 14 Oct '08

14 Oct '08

I wrote: > Here a suggested patch, currently a quick hack for inspection. I forgot slap.h. Added it now. And manpage while I'm at it. > This needs an API change: Currently slapd/limits.c:limits_gets() > takes the bound DN as an argument. The change needs a function > which fetches the bound or examined DN from the Operation structure. Typo, it's slapd/limits.c:limits_get() > Is it OK to just remove the DN argument and make the function > static, so any existing binaries that call it won't silently get > the changed API? Slapd doesn't call this function anywhere. ..it's not called anywhere _else_, that is. -- Hallvard

1 0

Re: (ITS#5731) Don't rewrite filter when it is undefined
by kouk＠noc.uoa.gr 13 Oct '08

13 Oct '08

On Thu, 09 Oct 2008 23:45:42 +0300, <ando(a)sys-net.it> wrote: > The bug is confirmed; the proposed fix is incorrect, since it only > addresses the case of a(n undefined) simple filter. A more complete fix > (see also ITS#5732) is in HEAD, please test. p. OK, I tested it and indeed it doesn't crash anymore. But I have a question regarding the fix in HEAD. When an undefined filter is supplied by the client, what is the intended behavior? From what I can tell the current (HEAD) behavior is that it is ignored (as false?). This is different from the previous behavior where, as I remember, an undefined filter error was reported to the client. Also from my tests with HEAD it seems that when the rwm overlay is present the implemented fix's check for an undefined filter will produce a filter semantically equivalent to false, "(!(objectClass=*))", which slapd will then procede to match against every entry under the base DN. This is different than what happens in HEAD (and in 2.4.11) without the rwm overlay, which is that the entries aren't even considered. From the debug log, when searching with (entryUUID=123) without the rwm overlay: search_candidates: base="ou=myunit,dc=mydomain,dc=gr" (0x00000001) scope=2 => bdb_dn2idl("ou=myunit,dc=mydomain,dc=gr") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_filter_candidates <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=0 last=0 <= bdb_filter_candidates: id=0 first=0 last=0 <= bdb_list_candidates: id=0 first=1 last=0 <= bdb_filter_candidates: id=0 first=1 last=0 bdb_search_candidates: id=0 first=1 last=0 bdb_search: no candidates From the debug log, when searching with (entryUUID=123) *with* the rwm overlay search_candidates: base="ou=myunit,dc=mydomain,dc=gr" (0x00000001) scope=2 => bdb_dn2idl("ou=myunit,dc=mydomain,dc=gr") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30989) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_filter_candidates NOT <= bdb_filter_candidates: id=-1 first=1 last=1911 <= bdb_list_candidates: id=-1 first=1 last=1911 <= bdb_filter_candidates: id=-1 first=1 last=1911 <= bdb_list_candidates: id=-1 first=1 last=1911 <= bdb_filter_candidates: id=-1 first=1 last=1911 bdb_search_candidates: id=-1 first=1 last=1911 => test_filter NOT => test_filter PRESENT => access_allowed: search access to "ou=myunit,dc=mydomain,dc=gr" "objectClass" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 <= test_filter 5 bdb_search: 1 does not match filter entry_decode: "uid=someone,ou=myunit,dc=mydomain,dc=gr" <= entry_decode(uid=someone,ou=myunit,dc=mydomain,dc=gr) => bdb_dn2id("uid=someone,ou=myunit,dc=mydomain,dc=gr") <= bdb_dn2id: got id=0x2 [... repeated for each entry under the base dn ...] So my question is, is this intended and/or reasonable? My uninformed opinion is that it would be better if an error is reported to the client when using an undefined filter (as in 2.4.11 without the rwm overlay) but that also slapd shouldn't try and match every entry with an undefined filter in the case the rwm overlay is applied.

1 0

Re: (ITS#5739) "host:port" does not work
by h.b.furuseth＠usit.uio.no 13 Oct '08

13 Oct '08

hyc(a)symas.com writes: > Why are you reporting this? "-h" has always been documented to only > accept a hostname, No. Look at man ldap_init: (...) each host may optionally by of the form host:port. If present, the :port overrides the port parameter (...) So sometimes this option is called hostport. It's been that way since umich ldap 3.2. -- Hallvard

1 0

Re: (ITS#5739) "host:port" does not work
by hyc＠symas.com 13 Oct '08

13 Oct '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: Linux x86_64 > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > $ clients/tools/ldapwhoami -x -h ldap:389 > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > $ clients/tools/ldapwhoami -x -h ldap > anonymous Why are you reporting this? "-h" has always been documented to only accept a hostname, you must use "-p" to set the port. -- -- 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#5739) "host:port" does not work
by h.b.furuseth＠usit.uio.no 13 Oct '08

13 Oct '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux x86_64 URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard $ clients/tools/ldapwhoami -x -h ldap:389 ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) $ clients/tools/ldapwhoami -x -h ldap anonymous

1 0

Re: (ITS#5705) [enhancement] slapo-constraint could honor "relax" by not checking for constraints
by michael＠stroeder.com 13 Oct '08

13 Oct '08

ando(a)sys-net.it wrote: > michael(a)stroeder.com wrote: > >> What's the use-case for this? I'm concerned about overloading the >> semantics of Relax Rules control far beyond what's written in >> draft-zeilenga-ldap-relax. > > Well, a user with "manage" privileges on related data could bypass > constraints enforced by slapo-constraint(5) by using the "relax" > control. This is a technical description. > The rationale is that a user with manage privileges could be > able to repair an entry that needs to violate a constraint for good > reasons. Currently I can't imagine a use-case for this particular violation of constraints. Do you have one? Just an example? > I decided to overload "relax" rather than defining a specific control > because I believe this fits into the spirit of "relax". I'm not sure. See, I try to support Relax Rules control in web2ldap. If the control is in effect the behaviour of the UI has to be heavily changed. I even considered proposing a that the Relax Rules control should have different values for specifying what particular constraint shall be relaxed. > In fact, the > resulting entry would violate a constraint, but would not violate the > protocol. Yes. I'm more concerned about complexity in a UI frontend. Ciao, Michael.

1 0

Re: (ITS#5705) [enhancement] slapo-constraint could honor "relax" by not checking for constraints
by ando＠sys-net.it 12 Oct '08

12 Oct '08

michael(a)stroeder.com wrote: > What's the use-case for this? I'm concerned about overloading the > semantics of Relax Rules control far beyond what's written in > draft-zeilenga-ldap-relax. Well, a user with "manage" privileges on related data could bypass constraints enforced by slapo-constraint(5) by using the "relax" control. The rationale is that a user with manage privileges could be able to repair an entry that needs to violate a constraint for good reasons. Note that the user: - must have enough privileges to do it (manage) - must inform the DSA that intends to violate the constraint (by using the control) I decided to overload "relax" rather than defining a specific control because I believe this fits into the spirit of "relax". In fact, the resulting entry would violate a constraint, but would not violate the protocol. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5705) [enhancement] slapo-constraint could honor "relax" by not checking for constraints
by michael＠stroeder.com 12 Oct '08

12 Oct '08

What's the use-case for this? I'm concerned about overloading the semantics of Relax Rules control far beyond what's written in draft-zeilenga-ldap-relax. Ciao, Michael.

1 0

Re: (ITS#5735) global overlays not handled correctly in back-config
by ando＠sys-net.it 12 Oct '08

12 Oct '08

ando(a)sys-net.it wrote: > When global overlays instantiate private databases, they are not correctly > handled by back-config. A fix is coming. The problem is essentially related to slapo-chain used as global overlay: after the configuration database is generated, slapd does not start correctly. To reproduce: - add "overlay chain" before any database in slapd.conf - run slapd -f slapd.conf -F slapd.d/ - stop slapd - run slapd -F slapd.d/ This should now be fixed in HEAD. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5738) back-monitor: registering a new backend (via moduleload) should add the corresponding entry in cn=monitor
by ando＠sys-net.it 12 Oct '08

12 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando p.

1 0

(ITS#5737) back-monitor: adding a database should add its entry in cn=monitor
by ando＠sys-net.it 12 Oct '08

12 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando p.

1 0

(ITS#5736) slapo-chain & slapo-translucent need work to interoperate with back-config
by ando＠sys-net.it 12 Oct '08

12 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.30.65.135) the *ldadd function of both overlays associated to private database instantiation does not intercept the olcDatabase attributeType. slapo-chain might also have an issue related to defferring *db_open(). A fix is coming. p.

1 0

(ITS#5735) global overlays not handled correctly in back-config
by ando＠sys-net.it 12 Oct '08

12 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.30.65.135) When global overlays instantiate private databases, they are not correctly handled by back-config. A fix is coming.

1 0

Re: ITS#5707
by hyc＠symas.com 11 Oct '08

11 Oct '08

ando(a)sys-net.it wrote: > Just to clarify: is the patch available from Oracle's web site > <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> > related? Is it alternative or complementary to<build/db.4.7.25.patch>? I suspect the contents of that URL will change over time. At the moment, that page has only one patch, and it only affects BerkeleyDB replication, which is a feature that we have never used. -- -- 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#5707
by ando＠sys-net.it 11 Oct '08

11 Oct '08

Just to clarify: is the patch available from Oracle's web site <http://www.oracle.com/technology/products/berkeley-db/db/update/4.7.25/patc…> related? Is it alternative or complementary to <build/db.4.7.25.patch>? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5734) Serch limits by baseDN
by h.b.furuseth＠usit.uio.no 10 Oct '08

10 Oct '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: http://folk.uio.no/hbf/OpenLDAP/limits.txt Submission from: (NULL) (129.240.6.233) Submitted by: hallvard I want to give part of a database different limits than the rest. Here a suggested patch, currently a quick hack for inspection. It gives ".this" and ".self" modifiers to "dn" in the "limits" keyword: limits dn[.this | .self][.exact | .base | ...] ... "Self" is default and matches the specified DN against the bound DN. "This" matches against the base DN of the search. (Keywords chosen from "this"/"self" in set ACLs, since names like "base" are taken.) This needs an API change: Currently slapd/limits.c:limits_gets() takes the bound DN as an argument. The change needs a function which fetches the bound or examined DN from the Operation structure. Is it OK to just remove the DN argument and make the function static, so any existing binaries that call it won't silently get the changed API? Slapd doesn't call this function anywhere.

1 0

Re: (ITS#5731) Don't rewrite filter when it is undefined
by ando＠sys-net.it 09 Oct '08

09 Oct '08

The bug is confirmed; the proposed fix is incorrect, since it only addresses the case of a(n undefined) simple filter. A more complete fix (see also ITS#5732) is in HEAD, please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5733) core dump in re24's slapd-ldap(5)
by ando＠sys-net.it 09 Oct '08

09 Oct '08

Full_Name: Pierangelo Masarati Version: re24 OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I had a strange core dump while testing re24 (test039). I'm reporting it in order to be able to investigate it further later. Backtrace follows: (gdb) bt #0 0x00800402 in __kernel_vsyscall () #1 0x00c9ad20 in raise () from /lib/libc.so.6 #2 0x00c9c631 in abort () from /lib/libc.so.6 #3 0x00c9416b in __assert_fail () from /lib/libc.so.6 #4 0x0817c7e5 in ldap_back_conn_delete (li=0x8a9ef30, lc=0x8b55df8) at bind.c:157 #5 0x0817d20a in ldap_back_freeconn (li=0x8a9ef30, lc=0x8b55df8, dolock=0) at bind.c:467 #6 0x0817e8cf in ldap_back_release_conn_lock (li=0x8a9ef30, lcp=0xb4376d10, dolock=1) at bind.c:1144 #7 0x0817cf12 in ldap_back_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:355 #8 0x080fac38 in overlay_op_walk (op=0x8b973e0, rs=0xb4377128, which=op_bind, oi=0x8a82d78, on=0x0) at backover.c:667 #9 0x080faded in over_op_func (op=0x8b973e0, rs=0xb4377128, which=op_bind) at backover.c:719 #10 0x080fae2d in over_op_bind (op=0x8b973e0, rs=0xb4377128) at backover.c:729 #11 0x080a8311 in fe_op_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:383 #12 0x080fac38 in overlay_op_walk (op=0x8b973e0, rs=0xb4377128, which=op_bind, oi=0x8a85090, on=0x0) at backover.c:667 #13 0x080faded in over_op_func (op=0x8b973e0, rs=0xb4377128, which=op_bind) at backover.c:719 #14 0x080fae2d in over_op_bind (op=0x8b973e0, rs=0xb4377128) at backover.c:729 #15 0x080a7aa7 in do_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:205 #16 0x08083c40 in connection_operation (ctx=0xb4377210, arg_v=0x8b973e0) at connection.c:1084 #17 0x0808411a in connection_read_thread (ctx=0xb4377210, argv=0x1f) at connection.c:1210 #18 0x08207d35 in ldap_int_thread_pool_wrapper (xpool=0x8a595b8) at tpool.c:663 #19 0x00deb46b in start_thread () from /lib/libpthread.so.0 #20 0x00d42dbe in clone () from /lib/libc.so.6 (gdb) f 4 #4 0x0817c7e5 in ldap_back_conn_delete (li=0x8a9ef30, lc=0x8b55df8) at bind.c:157 157 assert( !LDAP_BACK_CONN_TAINTED( lc ) ); (gdb) p *lc $1 = {lc_conn = 0xb7e91ba0, lc_ld = 0x8b79160, lc_cred = {bv_len = 0, bv_val = 0x0}, lc_bound_ndn = {bv_len = 68, bv_val = 0x8b2dce8 "cn=james a jones 1,ou=alumni association,ou=people,dc=example,dc=com"}, lc_local_ndn = {bv_len = 68, bv_val = 0x8b37e28 "cn=james a jones 1,ou=alumni association,ou=people,dc=example,dc=com"}, lc_lcflags = 289, lc_refcnt = 0, lc_flags = 4096, lc_create_time = 0, lc_time = 0, lc_q = {tqe_next = 0x0, tqe_prev = 0x0}} (gdb) p /x lc->lc_lcflags $2 = 0x121 The connection is simultaneously cached (0x100) and tainted (0x20); this triggers an assert. Note that (gdb) f 7 #7 0x0817cf12 in ldap_back_bind (op=0x8b973e0, rs=0xb4377128) at bind.c:355 355 ldap_back_release_conn( li, lc ); (gdb) p retrying $4 = LDAP_BACK_RETRYING so apparently no one had a chance to taint the connection (from within this thread). Probably, the assert is too tight. Either tainting and uncaching should occur simultaneously, or the assert should just be relaxed. p.

1 0

(ITS#5732) slapo-rwm can free and reuse a filter in case of error
by ando＠sys-net.it 09 Oct '08

09 Oct '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando A fix is coming, along with the right fix to ITS#5731 p.

1 0

Re: (ITS#5731) Don't rewrite filter when it is undefined
by kouk＠noc.uoa.gr 09 Oct '08

09 Oct '08

it turns out that the ftp client uploaded the patch here: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-0811009.patch.1

1 0

(ITS#5731) Don't rewrite filter when it is undefined
by kouk＠noc.uoa.gr 09 Oct '08

09 Oct '08

Full_Name: Kostantinos Koukopoulos Version: 2.4.11 OS: Solaris URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-0811009.patch Submission from: (NULL) (195.134.100.30) When a client provides a search filter which turns out to be undefined (for example if the assertion value doesn't conform to the syntax) then the rwm overlay will try to map the value without knowing if it's normalized or not. In one case this caused an assertion failure. The following is the backtrace when searching with '(entryUUID=123)': Assertion failed: val->bv_len == 16, file schema_init.c, line 2539 t@3 (l@3) signal ABRT (Abort) in _lwp_kill at 0xfe29fc54 0xfe29fc54: _lwp_kill+0x0008: bgeu,a _lwp_kill+0x1c Current function is map_attr_value 426 NULL, NULL, value, &vtmp, NULL ) ) /opt/OpenLdap>where current thread: t@3 [1] _lwp_kill(0x0, 0x6, 0x0, 0xfe2bc000, 0x0, 0x0), at 0xfe29fc54 [2] raise(0x6, 0x0, 0xfcfff168, 0x0, 0x0, 0x0), at 0xfe250c48 [3] abort(0x43, 0xfcfff1f8, 0x43, 0x7efefeff, 0x81010100, 0xff00), at 0xfe236d50 [4] __assert(0x258080, 0x258094, 0x9eb, 0x0, 0x0, 0x0), at 0xfe236ff0 [5] UUIDNormalize(0x4001, 0x0, 0x0, 0x700598, 0xfcfff504, 0x0), at 0xd3d8c =>[6] map_attr_value(dc = 0xfcfff6f8, adp = 0xfcfff5e0, mapped_attr = 0xfcfff5d8, value = 0x700598, mapped_value = 0xfcfff5d0, remap = 0), line 426 in "rwmmap.c" [7] rwm_int_filter_map_rewrite(op = 0x3885d8, dc = 0xfcfff6f8, f = 0x7005ac, fstr = 0xfcfff6f0), line 500 in "rwmmap.c" [8] rwm_filter_map_rewrite(op = 0x3885d8, dc = 0xfcfff6f8, f = 0x7005ac, fstr = 0xfcfff6f0), line 759 in "rwmmap.c" [9] rwm_op_search(op = 0x3885d8, rs = 0xfcfffcb0), line 765 in "rwm.c" [10] overlay_op_walk(0x3885d8, 0xfcfffcb0, 0x2, 0x33cea8, 0x33cfb0, 0xff00), at 0x121b70 [11] 0x121ecc(0x3885d8, 0xfcfffcb0, 0x2, 0xfcfff1e4, 0x2fc920, 0x2902d8), at 0x121ecb [12] 0x121ff8(0x3885d8, 0xfcfffcb0, 0x3886d8, 0x70052c, 0xfcfff9ec, 0x7005bc), at 0x121ff7 [13] do_search(0x388608, 0xfcfffcb0, 0xfcfffca0, 0x1, 0x0, 0x0), at 0x7791c [14] 0x73968(0xfcfffe0c, 0x3885d8, 0xfe2d0400, 0x0, 0x0, 0x0), at 0x73967 [15] 0x7406c(0xfcfffe0c, 0xd, 0x0, 0x0, 0x0, 0x0), at 0x7406b [16] ldap_int_thread_pool_wrapper(xpool = 0x3038f8), line 663 in "tpool.c" In this case the function 'map_attr_value' believes that the value is normalized and tries to de-normalize it. I have included a patch which skips rewriting of a filter when it is undefined.

1 0

Re: (ITS#5369) GSSAPI support for client library
by hyc＠symas.com 09 Oct '08

09 Oct '08

kurt(a)OpenLDAP.org wrote: > I note that the patch appears to be incomplete. No gssapi.c included. Sorry for the tardy review. The patch is also corrupted (both patches actually) and doesn't compile. Note this section of the patch to cyrus.c: +static ber_int_t +sb_sasl_cyrus_encode( + struct sb_sasl_generic_data *p, + unsigned char *buf, + ber_len_t len, + Sockbuf_Buf *dst) +{ + sasl_conn_t *sasl_context = (sasl_conn_t *)p->ops_private; + ber_int_t ret; + unsigned tmpsize = dst->buf_size; + + ret = sasl_encode( sasl_context, buf, len, + (SASL_CONST char **)&dst->buf_base, + &tmpsize ); - assert( sbiod != NULL ); + dst->buf_size = tmpsize; + dst->buf_end = dst->buf_ The last line appears to be truncated in both versions of the diff. > > -- Kurt > > On Feb 14, 2008, at 8:26 PM, kurt(a)openldap.org wrote: > >> You've only included one of the two required statements. You need >> also need to include either a copyright + license statement, or a >> public domain release statement. -- Kurt >> >> On Feb 14, 2008, at 9:12 AM, mimir(a)samba.org wrote: >> >>> --OgqxwSJOaUobr8KG >>> Content-Type: text/plain; charset=iso-8859-2 >>> Content-Disposition: inline >>> Content-Transfer-Encoding: quoted-printable >>> >>> Kurt, >>> >>> On Mon, Feb 11, 2008 at 09:06:19AM -0800, Kurt Zeilenga wrote: >>>>> Full_Name: Rafal Szczesniak >>>>> Version: HEAD >>>>> OS: GNU/Linux >>>>> URL: http://www.samba.org/~mimir/gssapi-head.diff >>>> The submitted patch file does not contain (at the top of the file, >>>> not = >>> =20 >>>> as part of the diffs) the required notices. Please review=20 >>>> http://www.openldap.org/devel/contributing.html and insert >>>> appropriate=20 >>>> notices. Also, please don't include in the diffs derived files >>>> (e.g.,=20 >>>> configure). >>> I've updated the patch file with necessary changes. Please take a >>> look >>> if it's fine now. >>> >>> >>> cheers, >>> --=20 >>> Rafal Szczesniak >>> Samba Team member http://www.samba.org >>> Likewise Software http://www.likewisesoftware.com >>> -- -- 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

SIZELIMIT 0 gives a zero limit
by Fabio Pedretti 08 Oct '08

08 Oct '08

The ldap.conf man page says this: SIZELIMIT <integer> Specifies a size limit to use when performing searches. The number should be a non-negative integer. SIZELIMIT of zero (0) specifies unlimited search size. However it appears that putting "SIZELIMIT 0" in my ldap.conf gives a: # search result search: 2 result: 4 Size limit exceeded To workaround this I put a very large value and it works. I am using openldap 2.4.11 compiled from source on a Slackware 10.0. Is it an openldap bug? Thanks, Fabio

3 3

(ITS#5730) Seg fault with referral entry and search filter (name=some name)
by michael＠stroeder.com 08 Oct '08

08 Oct '08

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.79.146) HI! if searching with (name=some name) slapd seg faults when processing a referral entry (referral chasing is off). If I delete the entry it works. FWIW: It's back-hdb. Ciao, Michael. ------------------- referral entry ------------------- dn: cn=Refers to ldap.openldap.org,ou=Testing,dc=stroeder,dc=de cn: Refers to ldap.openldap.org createTimestamp: 20050228152803Z creatorsName:: Y249TWljaGFlbCBTdHLDtmRlcixvdT1GcmllbmRzLGRjPXN0cm9lZGVyLGRjP WRl entryCSN: 20071213003755.763469Z#000000#000#000000 entryDN: cn=Refers to ldap.openldap.org,ou=Testing,dc=stroeder,dc=de entryUUID: 150b8f52-1de9-1029-9a2d-eaab50cd2b83 hasSubordinates: FALSE modifiersName:: Y249bWljaGFlbCBzdHLDtmRlcixvdT1mcmllbmRzLGRjPXN0cm9lZGVyLGRj PWRl modifyTimestamp: 20051021165032Z objectClass: extensibleObject objectClass: referral ref: ldap://ldap.openldap.org/dc=openldap,dc=org structuralObjectClass: referral subschemaSubentry: cn=Subschema ------------------- excerpt of syslog ------------------- Oct 8 15:44:05 nb2 slapd[10257]: conn=0 op=5 SRCH base="dc=stroeder,dc=de" scope=2 deref=0 filter="(|(name=*some name*))" Oct 8 15:44:05 nb2 slapd[10257]: conn=0 op=5 SRCH attr=telephonenumber countImmSubordinates labeledurl displayName cn subordinateCount objectClass description countTotSubordinates hasSubordinates msDS-Approx-Immed-Subordinates mobile structuralObjectClass subschemaSubentry mail numSubordinates numAllSubordinates homephone uid Oct 8 15:44:05 nb2 slapd[10257]: <= bdb_substring_candidates: (name) not indexed Oct 8 15:44:10 nb2 kernel: slapd[10260]: segfault at 29 ip 08091834 sp b37da2a0 error 4 in slapd[8048000+1e5000] ------------------- end of console debug output ------------------- ldap_url_parse_ext(ldap://ldap.openldap.org/dc=openldap,dc=org) >>> dnPretty: <dc=openldap,dc=org> => ldap_bv2dn(dc=openldap,dc=org,0) <= ldap_bv2dn(dc=openldap,dc=org)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=openldap,dc=org)=0 <<< dnPretty: <dc=openldap,dc=org> => send_search_reference: dn="(null)" => access_allowed: read access to "(null)" "entry" requested => dn: [5] dc=stroeder,dc=de Segmentation fault

1 0

Re: (ITS#5729) back-hdb segfaults
by quanah＠zimbra.com 07 Oct '08

07 Oct '08

--On Tuesday, October 07, 2008 7:22 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 10/7/2008 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I have a database using back-hdb, which segfaults while creating a domain > in the database (zimbra style). Works correctly with dn2id.c 1.158 -> 1.159 patch applied. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5729) back-hdb segfaults
by quanah＠zimbra.com 07 Oct '08

07 Oct '08

Full_Name: Quanah Gibson-Mount Version: RE24 10/7/2008 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I have a database using back-hdb, which segfaults while creating a domain in the database (zimbra style). It's clearly logged here: Tue Oct 7 12:16:26 2008 *** Running as zimbra user: /opt/zimbra/bin/zmprov -l cd freelancer.lab.zimbra.com ERROR: service.FAILURE (system failure: unable to create domain: freelancer.lab.zimbra.com) (cause: javax.naming.ServiceUnavailableException freelancer.lab.zimbra.com:389; socket closed) where the socket got closed during the operation (cd means create domain, and would add a dc=freelancer,dc=lab,dc=zimbra,dc=com object in the database). backtrace has: (gdb) bt #0 0x00002b41adac6839 in hdb_dn2id_add (op=0x1d11bc00, txn=0x1dc6ea20, eip=0x1b765080, e=0x1d01f828) at dn2id.c:617 #1 0x00002b41adab2029 in hdb_add (op=0x1d11bc00, rs=0x434aac70) at add.c:329 #2 0x000000000043cecd in fe_op_add (op=0x1d11bc00, rs=0x434aac70) at add.c:334 #3 0x000000000043c857 in do_add (op=0x1d11bc00, rs=0x434aac70) at add.c:194 #4 0x0000000000433d59 in connection_operation (ctx=0x434aadc0, arg_v=0x1d11bc00) at connection.c:1084 #5 0x0000000000434274 in connection_read_thread (ctx=0x434aadc0, argv=0xc) at connection.c:1210 #6 0x00002b41aa6c3a27 in ldap_int_thread_pool_wrapper (xpool=0x1b75fe00) at tpool.c:663 #7 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #8 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? () (gdb) print *eip $2 = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0, bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0}, bei_rdn = {bv_len = 0, bv_val = 0x0}, bei_modrdns = 0, bei_ckids = 1, bei_dkids = 0, bei_e = 0x1d01f008, bei_kids = 0x1da3c080, bei_kids_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}, bei_lrunext = 0x0, bei_lruprev = 0x0} (gdb) print *eip->bei_e $3 = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x1d13e9d8 ""}, e_nname = {bv_len = 0, bv_val = 0x1d13e9d0 ""}, e_attrs = 0x0, e_ocflags = 288, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x1b765080} --Quanah

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 07 Oct '08

07 Oct '08

On 10/7/08, Sylvain THOMAS <sylvain.thomas(a)gmail.com> wrote: > On 10/3/08, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: >> >> Can you: >> >> (a) reproduce with the current RE24 source? >> (b) Can you provide your slapd.conf files? >> >> Thanks, >> Quanah >> > > Yes. I confirm that I reproduce the problem with the HEAD extracted on > monday 6 october (yesterday). > The configuration and environment are the same as ITS 5661 (see > followup 3 of that ITS), but here I do not use the mirrormode. > Thanks and best regards > Sylvain Thomas > I would like to add that if you modify the script test018-syncreplication-persist in order to import two different ldif files in parallel the same problem occurs from time to time. The error message is : Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... test failed - producer and consumer databases differ I think this is a serious data integrity problem in the replication process. The weakness of the test018 is that it does not test simultaneous import of data. Best Regards Sylvain Thomas

1 0

Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 07 Oct '08

07 Oct '08

On 10/3/08, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > Can you: > > (a) reproduce with the current RE24 source? > (b) Can you provide your slapd.conf files? > > Thanks, > Quanah > Yes. I confirm that I reproduce the problem with the HEAD extracted on monday 6 october (yesterday). The configuration and environment are the same as ITS 5661 (see followup 3 of that ITS), but here I do not use the mirrormode. Thanks and best regards Sylvain Thomas

1 0

Re: (ITS#5728) back-bdb should release entries before writing to network
by h.b.furuseth＠usit.uio.no 07 Oct '08

07 Oct '08

For reference: There's more about this in ITS#5340. Somewhat confused discussion, unfortunately. -- Hallvard

1 0

Re: (ITS#5340) REP_ENTRY_MODIFIABLE bug in dynlist
by h.b.furuseth＠usit.uio.no 07 Oct '08

07 Oct '08

Belatead followup: This description of REP_ENTRY_MUSTRELEASE was still wrong. See ITS#5728: BDB didn't set the flag, ITS#3671 just gave the impression it would. Also code much take care to call overlay_entry_release_ov() instead of be_entry_release_r() when appropriate, as in ITS#5451. -- Hallvard

1 0

Re: Bug- Enforcing validation when validator is NULL
by Prashant kulkarni 07 Oct '08

07 Oct '08

Thanks Pierangelo And Harpreet for your reply As you suggested as per latest RFC specification , it is good idea for those attributes who don't have validators or where validator are all NULL to remove those attributes from *.schema files and those syntaxes from hardcoded code files. so any idea in which openLDAP release those attributes will be removed from schema and hardcoded code. ? But currently since these attributes are defined and hard coded in openldap code , the problem is I can't re-define in custom schema exactly with same name as "protocol information" as the openldap service will not start I have to define it as protocol informationXXX or something different to make it work but it then it will breaks the schema for our product which we use for other LDAP server also also I am thinking there is another solution to this bug . in openLDAP code in files /servers/slapd/modify.c and entry.C if all the validator are NULL then it should skip the checking for validation and throwing the error "no validator for syntax". in that way openldap will allow to modify/add values for those attributes having all NULL validator without enforcing. if ( ATLEAST ONE VALIDATOR PRESENT) //pseudo codeIS { if( !pretty && !validate ) { *text = "no validator for syntax"; snprintf( textbuf, textlen, "%s: no validator for syntax %s", ml->sml_type.bv_val, ad->ad_type->sat_syntax->ssyn_oid ); *text = textbuf; return LDAP_INVALID_SYNTAX; } Thanks and Regards Prashant Message: 19 Date: Mon, 29 Sep 2008 20:25:14 +0200 From: Pierangelo Masarati <ando(a)sys-net.it<http://mail.google.com/mail/h/xw1gbla4xfz4/?v=b&cs=wh&to=ando@sys-net.it> > Subject: Re: Bug- Enforcing validation when validator is NULL To: Prashant kulkarni <prashantk100(a)gmail.com<http://mail.google.com/mail/h/xw1gbla4xfz4/?v=b&cs=wh&to=prashantk100@gmail…> > Cc: openldap-bugs(a)openldap.org<http://mail.google.com/mail/h/xw1gbla4xfz4/?v=b&cs=wh&to=openldap-bugs@open…> Message-ID: <48E11D8A.7090706(a)sys-net.it<http://mail.google.com/mail/h/xw1gbla4xfz4/?v=b&cs=wh&to=48E11D8A.7090706@s…> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed Prashant kulkarni wrote: > When I am trying to add/edit the value to the attribute "protocol > information" which is required in our schema I am getting the error > > Invalid syntax :protocol information: no validator for syntax > 1.3.6.1.4.1.1466.115.121.1.42 > > from the earlier mailing list I have found The problem seems to be lack of > validations in the schema_init.c source code for attribure 'Protocol > Information' > > this attribute protocolInformation is defined in core.schema > > {"( 1.3.6.1.4.1.1466.115.121.1.42 DESC 'Protocol Information' )", > 0, NULL, NULL, NULL}, This syntax has been removed from RFC 2252 when revised in RFC 4517, as explicitly indicated in notes 21 and 28 to Appendix B of the latter. This because although mentioned in RFC 2252, those syntaxes were not defined and thus posing interoperability problems. I believe OpenLDAP should move one step forward toward RFC 451* compliance by removing (actually, marking as OBSOLETE) those attributes from *.schema files and those syntaxes from hardcoded ones. > including values like dnPretty ,UTF8StringValidate..etc in the code instead > of NULL values will resolve my problem, but then that require the custom > build and I have to do for all the attributes where validation is defined as > NULL. Not entirely true: you could implement a run-time module that looks up those syntaxes and modifies the appropriate pointers right after initialization. Unless significant changes in the related slapd structures or API, your module would seamlessly breeze through minor and even major releases. Furthermore, if those syntaxes are removed from the hardcoded ones, you could define them via a custom schema file using the X-SUBST feature (ITS#5663) recently introduced in HEAD code. It allows to provide a substitute syntax for unimplemented ones. > I personally feel that for those attributes where validation are NULL in > schema_init.c and other schema files, the openLDAP should not force the > validation and give this error message, as all these attributes in which > validation are not defined becomes unusable . > > In Tivoli/Sun and Microsoft Active directory LDAP validation is not enforced > where validation is defined as NULL hence I am not getting these kind of > error in Tivoli/Sun and Microsoft Active directory for editing of this > attribute . > > So any idea how to resolve this ? there is any way to modify any of the > config file in openldap to disable this validation for protocol information > ? > do I have to raise bug request for the same and is this going to be fixed in > next openLDAP release. ? > > Any help and suggestions in this direction is highly appreciated. I personally believe the absence of a validator for those syntaxes is the safest thing OpenLDAP can do to prevent further interoperability issues. The workaround illustrated above should allow you to circumvent your problem without too much harm. Of course, that's my personal opinion, which might differ from that of the OpenLDAP project. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it<http://mail.google.com/mail/h/xw1gbla4xfz4/?v=b&cs=wh&to=ando@sys-net.it> -----------------------------------

1 0

Re: (ITS#5728) back-bdb should release entries before writing to network
by hyc＠symas.com 07 Oct '08

07 Oct '08

Quanah Gibson-Mount wrote: > --On Monday, October 06, 2008 10:22 PM +0000 hyc(a)OpenLDAP.org wrote: >> back-bdb/hdb should set the REP_ENTRY_MUSTRELEASE flag when calling >> slap_send_search_entry() to prevent this situation. > > This fix breaks back-relay? slapo-rwm was using the wrong entry_release() function... Fixed in HEAD. > > Core was generated by > `/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd -s0 -f > /home/quanah'. > Program terminated with signal 6, Aborted. > #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 > #1 0x00000038dc031980 in abort () from /lib64/libc.so.6 > #2 0x00000038dc029726 in __assert_fail () from /lib64/libc.so.6 > #3 0x0000000000441be3 in entry_clean (e=0x1924ce18) at entry.c:483 > #4 0x0000000000441ccd in entry_free (e=0x1924ce18) at entry.c:514 > #5 0x00000000004458a4 in be_entry_release_rw (op=0x19440d80, e=0x1924ce18, > rw=0) at backend.c:869 > #6 0x00002b0efc860e42 in rwm_send_entry (op=0x19440d80, rs=0x41cf7c80) at > rwm.c:1370 -- -- 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#5728) back-bdb should release entries before writing to network
by quanah＠zimbra.com 07 Oct '08

07 Oct '08

--On Monday, October 06, 2008 10:22 PM +0000 hyc(a)OpenLDAP.org wrote: > back-bdb/hdb should set the REP_ENTRY_MUSTRELEASE flag when calling > slap_send_search_entry() to prevent this situation. This fix breaks back-relay? Core was generated by `/home/quanah/q/openldap-2.4.12/servers/slapd/.libs/lt-slapd -s0 -f /home/quanah'. Program terminated with signal 6, Aborted. #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00000038dc030015 in raise () from /lib64/libc.so.6 #1 0x00000038dc031980 in abort () from /lib64/libc.so.6 #2 0x00000038dc029726 in __assert_fail () from /lib64/libc.so.6 #3 0x0000000000441be3 in entry_clean (e=0x1924ce18) at entry.c:483 #4 0x0000000000441ccd in entry_free (e=0x1924ce18) at entry.c:514 #5 0x00000000004458a4 in be_entry_release_rw (op=0x19440d80, e=0x1924ce18, rw=0) at backend.c:869 #6 0x00002b0efc860e42 in rwm_send_entry (op=0x19440d80, rs=0x41cf7c80) at rwm.c:1370 #7 0x00002b0efc8612c9 in rwm_response (op=0x19440d80, rs=0x41cf7c80) at rwm.c:1562 #8 0x00000000004b7751 in over_back_response (op=0x19440d80, rs=0x41cf7c80) at backover.c:235 #9 0x0000000000448aee in slap_response_play (op=0x19440d80, rs=0x41cf7c80) at result.c:307 #10 0x000000000044a6aa in slap_send_search_entry (op=0x19440d80, rs=0x41cf7c80) at result.c:792 #11 0x00002b0efbdb8a9f in bdb_search (op=0x19440d80, rs=0x41cf7c80) at search.c:927 #12 0x00002b0efbfed03c in relay_back_op (op=0x19440d80, rs=0x41cf7c80, bd=0x191ce440, func=0x2b0efbdb6ab6 <bdb_search>, fail_mode=2952790069) at op.c:148 #13 0x00002b0efbfed216 in relay_back_op_search (op=0x19440d80, rs=0x41cf7c80) at op.c:218 #14 0x00000000004b8666 in overlay_op_walk (op=0x19440d80, rs=0x41cf7c80, which=op_search, oi=0x191d0100, on=0x0) at backover.c:667 #15 0x00000000004b8869 in over_op_func (op=0x19440d80, rs=0x41cf7c80, which=op_search) at backover.c:719 #16 0x00000000004b88ff in over_op_search (op=0x19440d80, rs=0x41cf7c80) at backover.c:741 #17 0x0000000000437568 in fe_op_search (op=0x19440d80, rs=0x41cf7c80) at search.c:366 #18 0x0000000000436ea7 in do_search (op=0x19440d80, rs=0x41cf7c80) at search.c:217 #19 0x0000000000433c6b in connection_operation (ctx=0x41cf7dd0, arg_v=0x19440d80) at connection.c:1084 #20 0x0000000000434186 in connection_read_thread (ctx=0x41cf7dd0, argv=0xc) at connection.c:1210 #21 0x00002b0ef9dcb9d7 in ldap_int_thread_pool_wrapper (xpool=0x19172610) at tpool.c:663 #22 0x00000038dcc061b5 in start_thread () from /lib64/libpthread.so.0 #23 0x00000038dc0cd36d in clone () from /lib64/libc.so.6 #24 0x0000000000000000 in ?? () --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5728) back-bdb should release entries before writing to network
by hyc＠OpenLDAP.org 07 Oct '08

07 Oct '08

Full_Name: Howard Chu Version: 2.3/2.4/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Currently we provide SlapReply flag REP_ENTRY_MUSTRELEASE which tells slap_send_search_entry() to release the current entry before writing to the network. syncprov uses it, but not much else does. If a client issues a search request that produces a large result set, and the client doesn't read the results quickly enough, eventually the socket buffers on client and server will fill up, and the slapd thread writing to the connection will block. If it blocks while writing an entry that is still readlocked, then attempts to modify that entry will hang. Subsequent attempts to read that entry will also hang after a write has hung. back-bdb/hdb should set the REP_ENTRY_MUSTRELEASE flag when calling slap_send_search_entry() to prevent this situation.

1 0

Re: (ITS#5526) Another segmentation fault
by h.b.furuseth＠usit.uio.no 06 Oct '08

06 Oct '08

This fix introduced some garbage in debugging output. It's cleaned up in cvs HEAD and the upcoming OpenLDAP 2.4.12. -- Regards, Hallvard

1 0

ITS#5727
by ando＠sys-net.it 06 Oct '08

06 Oct '08

[reposted; wrong sender] Cannot reproduce: a SIZELIMIT of 0 in ldaprc results in sending 0 on the wire, which causes the server to ignore it (and apply server-side limitations, eventually). HEAD, same with re24. Please check what file the sizelimit is actually read from by the client; also, check what size limit is actually received and subsequently enforced by the server. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

ITS#5727
by masarati＠aero.polimi.it 06 Oct '08

06 Oct '08

Cannot reproduce: a SIZELIMIT of 0 in ldaprc results in sending 0 on the wire, which causes the server to ignore it (and apply server-side limitations, eventually). HEAD, same with re24. Please check what file the sizelimit is actually read from by the client; also, check what size limit is actually received and subsequently enforced by the server. p.

1 0

Re: ITS#5724 (Re: commit: ldap/servers/slapd backover.c)
by ando＠sys-net.it 06 Oct '08

06 Oct '08

ando(a)sys-net.it wrote: > Sharing the pointer to the supported controls would allow to use the > actual set. Something along the line > > struct BackendDB { > char be_ctrlsbuf[SLAP_MAX_CIDS + 1]; > char *be_ctrls; > }; > > All backends would have be_ctrls = be_ctrlsbuf, but back-relay would set > it to NULL, and temporarily set it to the relayed database's be_ctrlsbuf > for the duration of an operation. Modules wouldn't be able to register > new controls because the pointer is null otherwise. Of course, this wouldn't work since it implies modifying the BackendDB structure, which is read-only :( p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5727) SIZELIMIT 0 gives a zero limit
by fabio.pedretti＠ing.unibs.it 06 Oct '08

06 Oct '08

Full_Name: Fabio Pedretti Version: 2.4.11 OS: Slackware 10.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.167.17.10) The ldap.conf man page says this: SIZELIMIT <integer> Specifies a size limit to use when performing searches. The number should be a non-negative integer. SIZELIMIT of zero (0) specifies unlimited search size. However it appears that putting "SIZELIMIT 0" in my ldap.conf gives a: # search result search: 2 result: 4 Size limit exceeded To workaround this I put a very large value and it works. I am using openldap 2.4.11 compiled from source on a Slackware 10.0. Is it an openldap bug? Thanks, Fabio

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs