- openldap-bugs - openldap.org

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

15 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 14 Oct '08

14 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 09 Oct '08

09 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs