- openldap-bugs - openldap.org

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by hyc＠symas.com 24 Dec '13

24 Dec '13

h.b.furuseth(a)usit.uio.no wrote: > This was fixed in LMDB 0.9.9, except: If both O_DIRECT and > F_NOCACHE are #defined, both are used. Looks a bit strange. > Maybe just one should be used in that case. (Which?) Also I'm > still wondering if env_open needs to fail if F_NOCACHE fails. > > Anyway, maybe it should be something like this. The "else {}" > is in case O_DIRECT is an unsupported dummy definiton: Isn't that in the wrong order then? What you suggest here will use O_DIRECT even if it's a dummy. I don't see any reason to fail the operation. They just want to make a copy/backup; even if the optimization of avoiding pollution of the buffer cache can't be done, they still want the copy to happen. > #ifdef O_DIRECT > if ((rc = fcntl(newfd, F_GETFL)) != -1) > (void) fcntl(newfd, F_SETFL, rc | O_DIRECT); > else > #endif > { > #ifdef F_NOCACHE /* __APPLE__ */ > (void) fcntl(newfd, F_NOCACHE, 1); > #endif > } > -- -- 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#7772) liblmdb sub-page growth when adding existing data
by h.b.furuseth＠usit.uio.no 23 Dec '13

23 Dec '13

Full_Name: Hallvard B Furuseth Version: mdb.master, 4c8f57615c5ca7b014c038e59c1045182e74f5ad OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-growth-131223.c Submission from: (NULL) (81.191.45.35) Submitted by: hallvard A non-LEAF2 sub-page grows if you put() a data item which already exists. The space remains unused while the sub-page exists. (A LEAF2 page grows reusable space, and only if it is full.) Demo program enclosed. Edit mdb.c to set mdb_debug=1 and build with -DMDB_DEBUG. Watch the 1st DPRINTF() in mdb_node_add(): bash$ ./a.out 2>&1 | perl -lne '/add to (.*) key size/ && print $1' leaf page 2 index 0, data size 404 # node with 1st item leaf page 2 index 0, data size 840 # convert to sub-page for 2nd item leaf sub-page 2 index 0, data size 0 leaf sub-page 2 index 1, data size 0 leaf page 2 index 0, data size 1250 # space for re-adding 2nd item leaf page 2 index 0, data size 1660 # space for re-adding 2nd item leaf page 2 index 0, data size 48 # ...too big, moved to sub-DB. Fix: lmdb could position cursor+xcursor fully before spill/touch, with an MDB_GET_BOTH variant which returns different codes for "no such key" and "no such data". And position it before MDB_MULTIPLE loops up. The current comparisons to see if the data item exists, go away. Maybe mdb_cursor_put() gets split in several functions, since much of the work in the recursive put()s will be unneeded.

1 0

(ITS#7771) liblmdb cursor issues
by h.b.furuseth＠usit.uio.no 22 Dec '13

22 Dec '13

Full_Name: Hallvard B Furuseth Version: mdb.master, 4c8f57615c5ca7b014c038e59c1045182e74f5ad OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-131222.c Submission from: (NULL) (2001:700:100:556::233) Submitted by: hallvard mdb_cursor_put() doc bug in lmdb.h: "If the function fails for any reason, the state of the cursor will be unchanged." That's quite untrue. To do that, the function must backup the cursor before moving it. (What is a "failure" anyway - are MDB_KEYEXIST and MDB_NOTFOUND failures?) Cursor tracking issues with MDB_DUPSORT: Cursor tracking sometimes ignores xcursors referring to sub-pages, yet code which uses an xcursor does not always fix that first. The enclosed program has several crashes. I.e. lots more code needs something like if ((leaf->mn_flags & (F_DUPDATA|F_SUBDATA)) == F_DUPDATA) m2->mc_xcursor->mx_cursor.mc_pg[0] = NODEDATA(leaf); before using an xcursor. I tried that everywhere before using xcursors: That helped, but it was not enough. E.g. after mdb_cursor_del() calls mdb_node_shrink(), it tracks cursors in the same sub-page but not nearby sub-pages. Also the fix suggested above means readers do more work that writers did not. Maybe instead all code which modified a database, should fix or invalidate that DB's cursors before returning (even at failure).

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 21 Dec '13

21 Dec '13

I wrote: > still wondering if env_open needs to fail if F_NOCACHE fails. Oops - env_copy, not env_open. -- Hallvard

1 0

Re: (ITS#7682) LMDB: [PATCH] mdb_env_copy should retry open() if O_DIRECT fails
by h.b.furuseth＠usit.uio.no 21 Dec '13

21 Dec '13

This was fixed in LMDB 0.9.9, except: If both O_DIRECT and F_NOCACHE are #defined, both are used. Looks a bit strange. Maybe just one should be used in that case. (Which?) Also I'm still wondering if env_open needs to fail if F_NOCACHE fails. Anyway, maybe it should be something like this. The "else {}" is in case O_DIRECT is an unsupported dummy definiton: #ifdef O_DIRECT if ((rc = fcntl(newfd, F_GETFL)) != -1) (void) fcntl(newfd, F_SETFL, rc | O_DIRECT); else #endif { #ifdef F_NOCACHE /* __APPLE__ */ (void) fcntl(newfd, F_NOCACHE, 1); #endif } -- Hallvard

1 0

Re: (ITS#7515) Nested liblmdb transaction bugs
by h.b.furuseth＠usit.uio.no 21 Dec '13

21 Dec '13

The remaining issues were fixed in LMDB 0.9.9. Closing this ITS. -- Hallvard

1 0

(ITS#7770) mdb_stat in cn=monitor
by michael＠stroeder.com 19 Dec '13

19 Dec '13

Full_Name: Version: OS: URL: Submission from: (NULL) (212.227.35.93) Feature request: It would be handy to have output of mdb_stat in cn=monitor.

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by clem.oudot＠gmail.com 19 Dec '13

19 Dec '13

--001a11c36ad2fcb4a204ede39c11 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2013/12/19 Christian Kratzer <ck(a)cksoft.de> > Hi, > > On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote: > <snipp/> > >> I sent it by mail but I think it is too big and queued. So here is all >> >> configuration and test result: >> >> http://pastebin.com/earKiHnH >> > > I have not worked trhough all your examples and configs yet as I am > travelling at the moment but things seem quite clear to me. > > > The password lock from you slaves never arrives on your master as you > have not configured referrals or any other kind of replication of state > from your slave to your master. > > That means the data on the masters and the slaves is inconsistent. > > As syncrepl as you use it always replaces the entire entry any changes > from the master will complelete overrite anything on the slaves. > > There is no merging of data in syncrepl. > If you take time to read all I sent, you will see that a first modification on the master DO NOT modifiy ppolicy attributes on the slave, the second modification do. Whatever you think, there is a bug here. If you read with caution the ppolicy draft, you will see that pwdAccountLockedTime and some other attributes SHOULD NOT be replicated on read-only replicas. > > This is working as designed and is not a bug by my understanding. > > We disagree a lot on this point. > You have at least following two options from what I see: > > 1. configure referrals and chaining so password locks etc... on the slav= e > get forwarded to the masters and replicated back to the slave. > > This means that you need to configure lcPPolicyForwardUpdates: TRUE > and chaining on your slave. > I tested it with success (almost, see ITS#7767 and ITS#7768) > > 2. configure multimaster replication so password locks get replicated > to your master. > > I did not test if the bug occurs in multimaster, but I think not. > You should close this ITS and we can discuss anything further on the > regular mailing lists. > > As said above, I am pretty sure there is a bug. Maybe an OpenLDAP developer should give its opinion on this ITS. Cl=E9ment. --001a11c36ad2fcb4a204ede39c11 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">2013/12/19 Christian Kratzer <span dir=3D"ltr"><<a href=3D"mailt= o:ck@cksoft.de" target=3D"_blank">ck(a)cksoft.de</a>></span><br><blockquot= e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol= id;padding-left:1ex"> <div class=3D"im">Hi,<br> <br> On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote:<br> <snipp/><br> </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"> I sent it by mail but I think it is too big and queued. So here is all<div = class=3D"im"><br> configuration and test result:<br> <br> <a href=3D"http://pastebin.com/earKiHnH" target=3D"_blank">http://pastebin.= com/earKiHnH</a><br> </div></blockquote> <br> I have not worked trhough all your examples and configs yet as I am<br> travelling at the moment but things seem quite clear to me.<br></blockquote= ><div>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> The password lock from you slaves never arrives on your master as you<br> have not configured referrals or any other kind of replication of state<br> from your slave to your master.<br> <br> That means the data on the masters and the slaves is inconsistent.<br> <br> As syncrepl as you use it always replaces the entire entry any changes<br> from the master will complelete overrite anything on the slaves.<br> <br> There is no merging of data in syncrepl.<br></blockquote><div><br><br><br><= /div><div>If you take time to read all I sent, you will see that a first mo= dification on the master DO NOT modifiy ppolicy attributes on the slave, th= e second modification do. Whatever you think, there is a bug here.<br> </div><div><br><br><br></div><div>If you read with caution the ppolicy draf= t, you will see that pwdAccountLockedTime and some other attributes SHOULD = NOT be replicated on read-only replicas.<br></div><div><br>=A0</div><blockq= uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc = solid;padding-left:1ex"> <br> This is working as designed and is not a bug by my understanding.<br> <br></blockquote><div><br><br></div><div>We disagree a lot on this point.<b= r><br><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> You have at least following two options from what I see:<br> <br> 1. =A0configure referrals and chaining so password locks etc... on the slav= e<br> =A0 =A0 get forwarded to the masters and replicated back to the slave.<br> <br> =A0 =A0 This means that you need to configure lcPPolicyForwardUpdates: TRUE= <br> =A0 =A0 and chaining on your slave.<br></blockquote><div><br><br></div><div= >I tested it with success (almost, see ITS#7767 and ITS#7768)<br></div><div= >=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"> <br> 2. =A0configure multimaster replication so password locks get replicated<br= > =A0 =A0 to your master.<br> <br></blockquote><div><br><br></div><div>I did not test if the bug occurs i= n multimaster, but I think not.<br><br>=A0<br></div><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> You should close this ITS and we can discuss anything further on the<br> regular mailing lists.<div class=3D"HOEnZb"><div class=3D"h5"><br></div></d= iv></blockquote><div><br><br><br><br></div><div>As said above, I am pretty = sure there is a bug. Maybe an OpenLDAP developer should give its opinion on= this ITS.<br> <br><br>Cl=E9ment.<br></div></div></div></div> --001a11c36ad2fcb4a204ede39c11--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by ck＠cksoft.de 19 Dec '13

19 Dec '13

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --4178219828-1095844242-1387443188=:27797 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi, On Wed, 18 Dec 2013, Clément OUDOT wrote: <snipp/> > I sent it by mail but I think it is too big and queued. So here is all > configuration and test result: > > http://pastebin.com/earKiHnH I have not worked trhough all your examples and configs yet as I am travelling at the moment but things seem quite clear to me. The password lock from you slaves never arrives on your master as you have not configured referrals or any other kind of replication of state from your slave to your master. That means the data on the masters and the slaves is inconsistent. As syncrepl as you use it always replaces the entire entry any changes from the master will complelete overrite anything on the slaves. There is no merging of data in syncrepl. This is working as designed and is not a bug by my understanding. You have at least following two options from what I see: 1. configure referrals and chaining so password locks etc... on the slave get forwarded to the masters and replicated back to the slave. This means that you need to configure lcPPolicyForwardUpdates: TRUE and chaining on your slave. 2. configure multimaster replication so password locks get replicated to your master. You should close this ITS and we can discuss anything further on the regular mailing lists. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer --4178219828-1095844242-1387443188=:27797--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by clem.oudot＠gmail.com 18 Dec '13

18 Dec '13

--089e0160b79ae9bb0c04edcfeff1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2013/12/18 <ck(a)cksoft.de> > This message is in MIME format. The first part should be readable text= , > while the remaining parts are likely unreadable without MIME-aware tool= s. > > --4178219828-444410844-1387368134=3D:27797 > Content-Type: TEXT/PLAIN; charset=3DUTF-8; format=3Dflowed > Content-Transfer-Encoding: 8BIT > > Hi, > > On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote: > <snipp/> > > Well, I checked that the pwdLockoutDuration was correctly set (The valu= e > > in my case is 1200, so 20 minutes, much more than my tests). Other > > proof, the values of pwdFailureTime are not erased, but replaced by > > those of the master. > > > > > >> It is of course also quite possible that you have hit a special corner > >> case that nobody else has yet found. > > > > > > I think so. I have to say that I use standard syncrepl, not > delta-syncrepl. > > > > > >> > >> The best thing you could do would be to setup a small self contained > >> test case to illustrate the problem. > >> > > > > I will try to, but seems really easy to reproduce : configure master an= d > > slave with ppolicy, lock an account in slave, update same account on > > master (change description) a first time and a second time. > > are you sure the account lock actually arrives on the master ? > > Are you using olcPPolicyForwardUpdates to actually get the account > locked on the master and not only on the slaves ? > > If you do not have all the lock attributes on the master and you modify > the entry it will get replaced on the slaves. > > Can you post your master and slave configs somewhere ? > > I sent it by mail but I think it is too big and queued. So here is all configuration and test result: http://pastebin.com/earKiHnH Cl=E9ment. --089e0160b79ae9bb0c04edcfeff1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail= _quote">2013/12/18 <span dir=3D"ltr"><<a href=3D"mailto:ck@cksoft.de" t= arget=3D"_blank">ck(a)cksoft.de</a>></span><br><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"> =A0 This message is in MIME format. =A0The first part should be readable te= xt,<br> =A0 while the remaining parts are likely unreadable without MIME-aware tool= s.<br> <br> --4178219828-444410844-1387368134=3D:27797<br> Content-Type: TEXT/PLAIN; charset=3DUTF-8; format=3Dflowed<br> Content-Transfer-Encoding: 8BIT<br> <br> Hi,<br> <br> On Wed, 18 Dec 2013, Cl=E9ment OUDOT wrote:<br> <snipp/><br> <div class=3D"im">> Well, I checked that the pwdLockoutDuration was corr= ectly set (The value<br> > in my case is 1200, so 20 minutes, much more than my tests). Other<br> > proof, the values of pwdFailureTime are not erased, but replaced by<br= > > those of the master.<br> ><br> ><br> >> It is of course also quite possible that you have hit a special co= rner<br> >> case that nobody else has yet found.<br> ><br> ><br> > I think so. I have to say that I use standard syncrepl, not delta-sync= repl.<br> ><br> ><br> >><br> >> The best thing you could do would be to setup a small self contain= ed<br> >> test case to illustrate the problem.<br> >><br> ><br> > I will try to, but seems really easy to reproduce : configure master a= nd<br> > slave with ppolicy, lock an account in slave, update same account on<b= r> > master (change description) a first time and a second time.<br> <br> </div>are you sure the account lock actually arrives on the master ?<br> <br> Are you using olcPPolicyForwardUpdates to actually get the account<br> locked on the master and not only on the slaves ?<br> <br> If you do not have all the lock attributes on the master and you modify<br> the entry it will get replaced on the slaves.<br> <br> Can you post your master and slave configs somewhere ?<br> <div class=3D"im"><br></div></blockquote><div><br><br></div><div>I sent it = by mail but I think it is too big and queued. So here is all configuration = and test result:<br><br><a href=3D"http://pastebin.com/earKiHnH">http://pas= tebin.com/earKiHnH</a><br> <br></div><div>Cl=E9ment.<br></div></div></div></div> --089e0160b79ae9bb0c04edcfeff1--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by ck＠cksoft.de 18 Dec '13

18 Dec '13

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --4178219828-444410844-1387368134=:27797 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Hi, On Wed, 18 Dec 2013, Clément OUDOT wrote: <snipp/> > Well, I checked that the pwdLockoutDuration was correctly set (The value > in my case is 1200, so 20 minutes, much more than my tests). Other > proof, the values of pwdFailureTime are not erased, but replaced by > those of the master. > > >> It is of course also quite possible that you have hit a special corner >> case that nobody else has yet found. > > > I think so. I have to say that I use standard syncrepl, not delta-syncrepl. > > >> >> The best thing you could do would be to setup a small self contained >> test case to illustrate the problem. >> > > I will try to, but seems really easy to reproduce : configure master and > slave with ppolicy, lock an account in slave, update same account on > master (change description) a first time and a second time. are you sure the account lock actually arrives on the master ? Are you using olcPPolicyForwardUpdates to actually get the account locked on the master and not only on the slaves ? If you do not have all the lock attributes on the master and you modify the entry it will get replaced on the slaves. Can you post your master and slave configs somewhere ? Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer --4178219828-444410844-1387368134=:27797--

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by coudot＠linagora.com 18 Dec '13

18 Dec '13

On 16/12/2013 22:10, Christian Kratzer wrote: > Hi, > > On Mon, 16 Dec 2013, coudot(a)linagora.com wrote: >> Full_Name: Cl?ment OUDOT >> Version: 2.4.38 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.173.78.196) >> >> >> I have a simple setup with a master (overlay syncprov + overlay >> ppolicy) and a >> slave (syncrepl client, overlay ppolicy). >> >> 1. I lock my account in the slave >> 2. I change the description attribute of my account a first time in >> the master >> 3. My account is still locked in the slave >> 4. I change the description attribute of my account a second time in >> the master >> 5. My account is no more locked in the slave: the password policy >> operational >> attributes pwdFailureTime and pwdAccountUnlockTime were erased by the >> one of the >> master >> >> Seems like a control is done the first time that syncrepl update the >> entry (the >> first time, pwdAccountLockTime and pwdFailureTime are not erased), >> but the >> second time the control is not done. > > I have had a very similar setup for some time now and have never > observed this kind of behaviour from the ppolicy overlay. I am quite > confident it should work correctly in the situation you describe. > > There might be a valid reason for pwdAccountLockedtime and > pwdFailureTime attributes disappearing like perhaps expiry of > pwdLockoutDuration. Please see the account_locked() function in > servers/slapd/overlay/ppolicy.c for this. > Well, I checked that the pwdLockoutDuration was correctly set (The value in my case is 1200, so 20 minutes, much more than my tests). Other proof, the values of pwdFailureTime are not erased, but replaced by those of the master. > It is of course also quite possible that you have hit a special corner > case that nobody else has yet found. I think so. I have to say that I use standard syncrepl, not delta-syncrepl. > > The best thing you could do would be to setup a small self contained > test case to illustrate the problem. > I will try to, but seems really easy to reproduce : configure master and slave with ppolicy, lock an account in slave, update same account on master (change description) a first time and a second time. This behavior was detected by one of my customer, and I was able to reproduce it on my own computer. Clément.

1 0

(ITS#7769) [PATCH] Fix typo in slapd-meta manpage.
by jsynacek＠redhat.com 17 Dec '13

17 Dec '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 19 URL: http://jsynacek.fedorapeople.org/openldap/jsynacek-20131217-0001-Fix-typo-i… Submission from: (NULL) (209.132.186.34) Fix for a typo in slapd-meta.5

1 0

Re: (ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by ck＠cksoft.de 16 Dec '13

16 Dec '13

Hi, On Mon, 16 Dec 2013, coudot(a)linagora.com wrote: > Full_Name: Cl?ment OUDOT > Version: 2.4.38 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > I have a simple setup with a master (overlay syncprov + overlay ppolicy) and a > slave (syncrepl client, overlay ppolicy). > > 1. I lock my account in the slave > 2. I change the description attribute of my account a first time in the master > 3. My account is still locked in the slave > 4. I change the description attribute of my account a second time in the master > 5. My account is no more locked in the slave: the password policy operational > attributes pwdFailureTime and pwdAccountUnlockTime were erased by the one of the > master > > Seems like a control is done the first time that syncrepl update the entry (the > first time, pwdAccountLockTime and pwdFailureTime are not erased), but the > second time the control is not done. I have had a very similar setup for some time now and have never observed this kind of behaviour from the ppolicy overlay. I am quite confident it should work correctly in the situation you describe. There might be a valid reason for pwdAccountLockedtime and pwdFailureTime attributes disappearing like perhaps expiry of pwdLockoutDuration. Please see the account_locked() function in servers/slapd/overlay/ppolicy.c for this. It is of course also quite possible that you have hit a special corner case that nobody else has yet found. The best thing you could do would be to setup a small self contained test case to illustrate the problem. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer

1 0

Re: (ITS#7764) RFE: library lber method which returns the ber size even if the ber is overflown
by nhosoi＠gmail.com 16 Dec '13

16 Dec '13

--001a11c1a2f087afb804edaadb8d Content-Type: text/plain; charset=ISO-8859-1 Thank you, Howard! You are right. We are not getting LBER_OVERFLOW, but having the return code LBER_DEFAULT and "errno == ERANGE". Also, indeed there is no particular size limits in openldap lber library unless setting the max incoming ber size with this API: ber_sockbuf_ctrl(sockbuf, LBER_SB_OPT_SET_MAX_INCOMING, &maxsize); We'd like to avoid receiving, e.g., 100MB ber's, but we'd like to also have a method to log the rejected incoming ber size just in case the administrator may want to allow to receive it. Best regards, --Noriko Hosoi On Sun, Dec 15, 2013 at 3:58 AM, Howard Chu <hyc(a)symas.com> wrote: > nhosoi(a)gmail.com wrote: > >> Full_Name: Noriko Hosoi >> Version: 2.4.35-4 >> OS: Fedora 18 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.132.181.86) >> >> >> We use the OpenLdap library in our software. LDAP clients could send too >> large >> ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. We'd >> like to >> learn how large the ber size we should prepare from the error. When we >> look >> into the BerElement ber using gdb, ber->ber_len stores the value. But the >> value >> is not returned to the caller when the API fails, e.g., by the overflow. >> Could >> it be possible to have a way to retrieve the ber size under any condition? >> > > That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. Nor > do we have any particular size limits on a BerElement, other than fitting > into a long. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a11c1a2f087afb804edaadb8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><div><div>Thank you, Howard!=A0 <br><br>You are right= .=A0 We are not getting LBER_OVERFLOW, but having the return code LBER_DEFA= ULT and "errno =3D=3D ERANGE".=A0 Also, indeed there is no partic= ular size limits in openldap lber library unless setting the max incoming b= er size with this API:<br> =A0=A0=A0 ber_sockbuf_ctrl(sockbuf, LBER_SB_OPT_SET_MAX_INCOMING, &maxs= ize);<br><br></div>We'd like to avoid receiving, e.g., 100MB ber's,= but we'd like to also have a method to log the rejected incoming ber s= ize just in case the administrator may want to allow to receive it.<br> <br></div>Best regards,<br></div>--Noriko Hosoi<br></div><div class=3D"gmai= l_extra"><br><br><div class=3D"gmail_quote">On Sun, Dec 15, 2013 at 3:58 AM= , Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com" target= =3D"_blank">hyc(a)symas.com</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><a href=3D"mailto:nhosoi@gmail.com" target= =3D"_blank">nhosoi(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Noriko Hosoi<br> Version: 2.4.35-4<br> OS: Fedora 18<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/<u></u>incoming/</a><br> Submission from: (NULL) (209.132.181.86)<br> <br> <br> We use the OpenLdap library in our software. =A0LDAP clients could send too= large<br> ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. =A0We'd= like to<br> learn how large the ber size we should prepare from the error. =A0When we l= ook<br> into the BerElement ber using gdb, ber->ber_len stores the value. But th= e value<br> is not returned to the caller when the API fails, e.g., by the overflow. = =A0Could<br> it be possible to have a way to retrieve the ber size under any condition?<= br> </blockquote> <br> That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. = Nor do we have any particular size limits on a BerElement, other than fitti= ng into a long.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -- <br> =A0 -- Howard Chu<br> =A0 CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a><br> =A0 Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a><br> =A0 Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/<u></u>project/</a><br> </font></span></blockquote></div><br></div> --001a11c1a2f087afb804edaadb8d--

1 0

(ITS#7768) Use of olcDbUri in LDAP/Chain configuration for ppolicy_forward_updates
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I set up a slave configuration with ppolicy_forward_updates feature. In my data backend config, I have: olcUpdateRef: ldap://localhost:389 And I created the chain overlay and a sub ldap backend like this: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: top objectClass: olcConfig objectClass: olcChainConfig objectClass: olcOverlayConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: bindmethod="simple" binddn="cn=admin,dc=example,dc=com" credentials="secret" mode="none" This configuration do not work: the BIND on the master server is done anonymously, despite the olcDbIDAssertBind value. To work, I need to add: olcDbUri: ldap://localhost:389 Seems the problem exist in OpenLDAP unit test 32, see tests/data/slapd-chain1.conf : # uses the chain overlay as global; # no chain-URI is configured, so the URI is parsed out of the referral overlay chain chain-uri @URI2@ chain-idassert-bind bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=secret mode=self flags=non-prescriptive The comment say "no chain-URI is configured', but the chain-uri is configured. Where is the truth?

1 0

(ITS#7767) Connection not reset when olcDbUri value changed in cn=config (ldap backend)
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I configure the LDAP backend under a chain overlay to manage ppolicy-forward-updates configuration, the configuration is: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: top objectClass: olcConfig objectClass: olcChainConfig objectClass: olcOverlayConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbIDAssertBind: bindmethod="simple" binddn="cn=admin,dc=example,dc=com" crede ntials="secret" mode="none" olcDbUri: ldap://localhost:389 When changing the value of olcDbUri trough an LDAP client, the connection to the server is not reset, so the configuration is not taken dynamically. All is ok if I restart OpenLDAP.

1 0

(ITS#7766) Account unlocked in slave after two modifications on a master (overlay ppolicy)
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I have a simple setup with a master (overlay syncprov + overlay ppolicy) and a slave (syncrepl client, overlay ppolicy). 1. I lock my account in the slave 2. I change the description attribute of my account a first time in the master 3. My account is still locked in the slave 4. I change the description attribute of my account a second time in the master 5. My account is no more locked in the slave: the password policy operational attributes pwdFailureTime and pwdAccountUnlockTime were erased by the one of the master Seems like a control is done the first time that syncrepl update the entry (the first time, pwdAccountLockTime and pwdFailureTime are not erased), but the second time the control is not done.

1 0

(ITS#7765) Crash when adding syncrepl configuration in cn=config without search base
by coudot＠linagora.com 16 Dec '13

16 Dec '13

Full_Name: Clément OUDOT Version: 2.4.38 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) When adding an olcSyncrepl attribute in my cn=config, OpenLDAP crashed. The syslog output is: Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 BIND dn="cn=config" method=128 Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=0 RESULT tag=97 err=0 text= Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=1 MOD dn="olcDatabase={2}mdb,cn=config" Dec 16 11:56:42 ader slapd[8707]: conn=1096 op=1 MOD attr=olcaccess olcdbindex olcsyncrepl Dec 16 11:56:42 ader slapd[8707]: olcSyncrepl: value #0: Error: Malformed "syncrepl" line in slapd config file, missing searchbase. Dec 16 11:56:42 ader slapd[8707]: failed to add syncinfo Dec 16 11:56:42 ader slapd[8707]: ch_calloc of 1 elems of 0 bytes failed I have no gdb trace to give for now, if you think it is required, I will try to find time to do it. But it should be easy to reproduce the issue on your side.

1 0

Re: (ITS#7764) RFE: library lber method which returns the ber size even if the ber is overflown
by hyc＠symas.com 15 Dec '13

15 Dec '13

nhosoi(a)gmail.com wrote: > Full_Name: Noriko Hosoi > Version: 2.4.35-4 > OS: Fedora 18 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.132.181.86) > > > We use the OpenLdap library in our software. LDAP clients could send too large > ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. We'd like to > learn how large the ber size we should prepare from the error. When we look > into the BerElement ber using gdb, ber->ber_len stores the value. But the value > is not returned to the caller when the API fails, e.g., by the overflow. Could > it be possible to have a way to retrieve the ber size under any condition? That doesn't sound like OpenLDAP, we have no LBER_OVERFLOW error code. Nor do we have any particular size limits on a BerElement, other than fitting into a long. -- -- 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#7763) undefined references during LTO enabled build
by nheghathivhistha＠gmail.com 14 Dec '13

14 Dec '13

Hello, Thank you. Markus Trippelsdorf told me in my bug report (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59505) what is the problem cause and how to solve it - it is not existing support for slim-LTO-model in binutils. AS=gcc-as AR=gcc-ar NM=gcc-nm RANLIB=gcc-ranlib did it for me for Openldap package in Gentoo too . Best regards, David. 2013/12/13 Howard Chu <hyc(a)symas.com>: > nheghathivhistha(a)gmail.com wrote: >> >> Full_Name: David Kredba >> Version: 2.4.38 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.101.228.82) >> >> >> I am trying to rebuild my system with LTO enabled gcc. >> >> Compilation of Gentoo package /net-nds/openldap-2.4.38-r1 ended with: > > > You cut off the trace just at the crucial line. It should say, e.g.: > > ar ru librewrite.a config.o context.o info.o ldapmap.o map.o params.o rule.o > session.o subst.o var.o xmap.o version.o > ar: creating librewrite.a > > Anyway, I see no build errors here. Closing this ITS. Ask for help on the > -technical mailing list. > >> x86_64-pc-linux-gnu-ar: creating librewrite.a >> /bin/bash ../../libtool --mode=link x86_64-pc-linux-gnu-gcc -O2 -ggdb >> -pipe >> -march=native -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE >> -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb >> -pipe >> -march=native -mtune=native -flto=4 -fuse-linker-plugin -o rewrite >> rewrite.o >> parse.o librewrite.a ../../libraries/liblutil/liblutil.a >> ../../libraries/libldap_r/libldap_r.la ../../libraries/liblber/liblber.la >> -lssl -lcrypto -lcrypt -lresolv -pthread >> libtool: link: x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe -march=native >> -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE -Wl,-O1 >> -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native >> -mtune=native -flto=4 -fuse-linker-plugin -o .libs/rewrite rewrite.o >> parse.o >> -pthread -Wl,--as-needed librewrite.a ../../libraries/liblutil/liblutil.a >> ../../libraries/libldap_r/.libs/libldap_r.so >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/liblber/.libs/liblber.so >> ../../libraries/liblber/.libs/liblber.so -lssl -lcrypto -lcrypt -lresolv >> -pthread >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: >> In >> function `rewrite_read': >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/parse.c:112: >> undefined reference to `rewrite_parse' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: >> In >> function `main': >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:141: >> undefined reference to `lutil_atoix' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: >> In >> function `apply': >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:52: >> undefined reference to `rewrite_info_init' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:58: >> undefined reference to `rewrite_param_set' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:60: >> undefined reference to `rewrite_session_init' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:75: >> undefined reference to `rewrite_session' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:120: >> undefined reference to `rewrite_session_delete' >> >> /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:122: >> undefined reference to `rewrite_info_delete' >> collect2: error: ld returned 1 exit status >> Makefile:290: recipe for target 'rewrite' failed >> make[2]: *** [rewrite] Error 1 >> make[2]: Leaving directory >> >> '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite' >> Makefile:296: recipe for target 'all-common' failed >> make[1]: *** [all-common] Error 1 >> make[1]: Leaving directory >> >> '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries' >> Makefile:312: recipe for target 'all-common' failed >> >> Coul you kindly please look into it? I think that header(s) can be missing >> in >> source files and library(ies) at link time. >> >> I uploaded david-kredba-20131213-build.log and >> david-kredba-20131213-config.log >> to your ftp server. >> >> Thank you in advance. >> >> > > > -- > -- 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#7764) RFE: library lber method which returns the ber size even if the ber is overflown
by nhosoi＠gmail.com 13 Dec '13

13 Dec '13

Full_Name: Noriko Hosoi Version: 2.4.35-4 OS: Fedora 18 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.181.86) We use the OpenLdap library in our software. LDAP clients could send too large ber and cause LBER_OVERFLOW (or LBER_DEFAULT) to the lber APIs. We'd like to learn how large the ber size we should prepare from the error. When we look into the BerElement ber using gdb, ber->ber_len stores the value. But the value is not returned to the caller when the API fails, e.g., by the overflow. Could it be possible to have a way to retrieve the ber size under any condition?

1 0

Re: (ITS#7763) undefined references during LTO enabled build
by hyc＠symas.com 13 Dec '13

13 Dec '13

nheghathivhistha(a)gmail.com wrote: > Full_Name: David Kredba > Version: 2.4.38 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.101.228.82) > > > I am trying to rebuild my system with LTO enabled gcc. > > Compilation of Gentoo package /net-nds/openldap-2.4.38-r1 ended with: You cut off the trace just at the crucial line. It should say, e.g.: ar ru librewrite.a config.o context.o info.o ldapmap.o map.o params.o rule.o session.o subst.o var.o xmap.o version.o ar: creating librewrite.a Anyway, I see no build errors here. Closing this ITS. Ask for help on the -technical mailing list. > x86_64-pc-linux-gnu-ar: creating librewrite.a > /bin/bash ../../libtool --mode=link x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe > -march=native -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE > -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe > -march=native -mtune=native -flto=4 -fuse-linker-plugin -o rewrite rewrite.o > parse.o librewrite.a ../../libraries/liblutil/liblutil.a > ../../libraries/libldap_r/libldap_r.la ../../libraries/liblber/liblber.la > -lssl -lcrypto -lcrypt -lresolv -pthread > libtool: link: x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe -march=native > -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE -Wl,-O1 > -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native > -mtune=native -flto=4 -fuse-linker-plugin -o .libs/rewrite rewrite.o parse.o > -pthread -Wl,--as-needed librewrite.a ../../libraries/liblutil/liblutil.a > ../../libraries/libldap_r/.libs/libldap_r.so > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/liblber/.libs/liblber.so > ../../libraries/liblber/.libs/liblber.so -lssl -lcrypto -lcrypt -lresolv > -pthread > /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In > function `rewrite_read': > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/parse.c:112: > undefined reference to `rewrite_parse' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In > function `main': > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:141: > undefined reference to `lutil_atoix' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In > function `apply': > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:52: > undefined reference to `rewrite_info_init' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:58: > undefined reference to `rewrite_param_set' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:60: > undefined reference to `rewrite_session_init' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:75: > undefined reference to `rewrite_session' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:120: > undefined reference to `rewrite_session_delete' > /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:122: > undefined reference to `rewrite_info_delete' > collect2: error: ld returned 1 exit status > Makefile:290: recipe for target 'rewrite' failed > make[2]: *** [rewrite] Error 1 > make[2]: Leaving directory > '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite' > Makefile:296: recipe for target 'all-common' failed > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory > '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries' > Makefile:312: recipe for target 'all-common' failed > > Coul you kindly please look into it? I think that header(s) can be missing in > source files and library(ies) at link time. > > I uploaded david-kredba-20131213-build.log and david-kredba-20131213-config.log > to your ftp server. > > Thank you in advance. > > -- -- 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#7763) undefined references during LTO enabled build
by nheghathivhistha＠gmail.com 13 Dec '13

13 Dec '13

Full_Name: David Kredba Version: 2.4.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.101.228.82) I am trying to rebuild my system with LTO enabled gcc. Compilation of Gentoo package /net-nds/openldap-2.4.38-r1 ended with: x86_64-pc-linux-gnu-ar: creating librewrite.a /bin/bash ../../libtool --mode=link x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -o rewrite rewrite.o parse.o librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/libldap_r.la ../../libraries/liblber/liblber.la -lssl -lcrypto -lcrypt -lresolv -pthread libtool: link: x86_64-pc-linux-gnu-gcc -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -D_GNU_SOURCE -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -O2 -ggdb -pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin -o .libs/rewrite rewrite.o parse.o -pthread -Wl,--as-needed librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/.libs/libldap_r.so /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so -lssl -lcrypto -lcrypt -lresolv -pthread /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In function `rewrite_read': /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/parse.c:112: undefined reference to `rewrite_parse' /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In function `main': /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:141: undefined reference to `lutil_atoix' /var/tmp/portage/net-nds/openldap-2.4.38-r1/temp/ccTxyjV6.ltrans0.ltrans.o: In function `apply': /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:52: undefined reference to `rewrite_info_init' /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:58: undefined reference to `rewrite_param_set' /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:60: undefined reference to `rewrite_session_init' /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:75: undefined reference to `rewrite_session' /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:120: undefined reference to `rewrite_session_delete' /var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite/rewrite.c:122: undefined reference to `rewrite_info_delete' collect2: error: ld returned 1 exit status Makefile:290: recipe for target 'rewrite' failed make[2]: *** [rewrite] Error 1 make[2]: Leaving directory '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries/librewrite' Makefile:296: recipe for target 'all-common' failed make[1]: *** [all-common] Error 1 make[1]: Leaving directory '/var/tmp/portage/net-nds/openldap-2.4.38-r1/work/openldap-2.4.38/libraries' Makefile:312: recipe for target 'all-common' failed Coul you kindly please look into it? I think that header(s) can be missing in source files and library(ies) at link time. I uploaded david-kredba-20131213-build.log and david-kredba-20131213-config.log to your ftp server. Thank you in advance.

1 0

Re: (ITS#7762) ldap_dn2bv_x misbehaves for "empty" dn
by hyc＠symas.com 11 Dec '13

11 Dec '13

marc.schmitzer(a)richard-wolf.com wrote: > Full_Name: Marc Schmitzer > Version: 2.4.28 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.229.211) > > > The ldap_dn2bv_x function misbehaves for the LDAPV2 and LDAPV3 formats when it > is passed an "empty" DN in the form of an LDAPRDN-array whose first element is > NULL. The "len" variable remains zero throughout the function, as no RDNS are > processed. Finally, the bv_len member of the output struct berval is set to > len-1. The result is a berval with bv_len = UINT_MAX. > > Tested with 2.4.28, but the problem appears to present in the current git master > as well. Thanks for the report, fixed now in git master. > > The following code snippet demonstrates the problem: > > #include <stdio.h> > #include <ldap.h> > > int main(int argc, char** argv) > { > LDAPRDN dn[1] = { NULL }; > struct berval bv = { 0, NULL }; > int res = ldap_dn2bv(dn, &bv, LDAP_DN_FORMAT_LDAPV3); > > printf("res: %d\n", res); > printf("len: %u\n", (unsigned int) bv.bv_len); > > return 0; > } > > > Output: > res: 0 > len: 4294967295 > > -- -- 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#7762) ldap_dn2bv_x misbehaves for "empty" dn
by marc.schmitzer＠richard-wolf.com 11 Dec '13

11 Dec '13

Full_Name: Marc Schmitzer Version: 2.4.28 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.6.229.211) The ldap_dn2bv_x function misbehaves for the LDAPV2 and LDAPV3 formats when it is passed an "empty" DN in the form of an LDAPRDN-array whose first element is NULL. The "len" variable remains zero throughout the function, as no RDNS are processed. Finally, the bv_len member of the output struct berval is set to len-1. The result is a berval with bv_len = UINT_MAX. Tested with 2.4.28, but the problem appears to present in the current git master as well. The following code snippet demonstrates the problem: #include <stdio.h> #include <ldap.h> int main(int argc, char** argv) { LDAPRDN dn[1] = { NULL }; struct berval bv = { 0, NULL }; int res = ldap_dn2bv(dn, &bv, LDAP_DN_FORMAT_LDAPV3); printf("res: %d\n", res); printf("len: %u\n", (unsigned int) bv.bv_len); return 0; } Output: res: 0 len: 4294967295

1 0

(ITS#7761) Issue with modifying loglevel during long search operation
by mwarren＠symas.com 10 Dec '13

10 Dec '13

Full_Name: Mark Warren Version: 2.4.38 OS: RHEL 5 x86-64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (199.190.53.83) There is an issue where OpenLDAP will stop sending search results and fail to update a dynamic config when the loglevel is modified during a long search operation. Symptoms: * No further search results sent to client although internally the operation continues. * Log level change does not take effect Cause(Via Howard): * send_search_entry() correctly returns an error because back-config wants a pause * back-bdb/back-hdb ignores this error * The entry it tried to send doesn't get sent, and it just loops back to fetch the next entry instead of quitting Steps to reproduce: 1. Create large sample database. 2 million entries was more than sufficient locally. 2. Issue a search request for all entries. 3. Submit a modify request on olcLogLevel within cn=config while the above search is still in progress. Notes(Also via Howard): * This is not a total hang as everything should resume after the internal search operation finishes. Regards, Mark Warren

1 0

Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com 09 Dec '13

09 Dec '13

This is a multi-part message in MIME format. --------------050905040301060400050300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Lukas Slebodnik wrote: > On (09/12/13 04:01), Howard Chu wrote: >>>> Meanwhile you can refer to draft-behera-ldap-password-policy for the >>>> specification of the response control. The control value is mandatory >>>> for this control. >>> If I read draft "6.2. Response Control" correctly, >>> http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2 >>> response can be sequence of "PasswordPolicyResponseValue". >>> I think that sequence means "0 or more values" >> >> The sequence is required to begin with a Sequence marker. >> >>> In theory, there needn't be any password policy response value after control >>> type. In this case, either my patch or your patch are wrong. >>> Did I miss something? >>> >>> The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is >>> the BER encoding of the following type: >> >> "the controlValue is the BER encoding of a Sequence." - even if the >> sequence has zero members, it cannot be omitted. >> > Thank you for your explanation. > > I am attaching output from ldapwhoami with enabled ppolicy, > but I am sure that problem is in the server apacheds, because there is nothing > after controlType 1.3.6.1.4.1.42.2.27.8.5.1 > (at least Sequence marker should be after controlType) Agreed, that looks like an ApacheDS bug. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------050905040301060400050300 Content-Type: text/plain; charset=UTF-8; name="ldapwhoami.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ldapwhoami.log" W3Jvb3RAdm0tMjE5IH5dIyBsZGFwd2hvYW1pIC1kNyAtRCAiY249V2lsbGlhbSBCdXNoLG91 PXBlb3BsZSxkYz1leGFtcGxlLGRjPXNrIiAtdyBqYWhvZGEuMTIzIC1IIGxkYXA6Ly92bS0x MzcuaWRtLmxhYi5sb2NhbCAtZSBwcG9saWN5CmxkYXBfdXJsX3BhcnNlX2V4dChsZGFwOi8v dm0tMTM3LmlkbS5sYWIubG9jYWwpCmxkYXBfY3JlYXRlCmxkYXBfdXJsX3BhcnNlX2V4dChs ZGFwOi8vdm0tMTM3LmlkbS5sYWIubG9jYWw6Mzg5Lz8/YmFzZSkKbGRhcF9zYXNsX2JpbmQK bGRhcF9zZW5kX2luaXRpYWxfcmVxdWVzdApsZGFwX25ld19jb25uZWN0aW9uIDEgMSAwCmxk YXBfaW50X29wZW5fY29ubmVjdGlvbgpsZGFwX2Nvbm5lY3RfdG9faG9zdDogVENQIHZtLTEz Ny5pZG0ubGFiLmxvY2FsOjM4OQpsZGFwX25ld19zb2NrZXQ6IDMKbGRhcF9wcmVwYXJlX3Nv Y2tldDogMwpsZGFwX2Nvbm5lY3RfdG9faG9zdDogVHJ5aW5nIDEwLjM0LjQ3LjEzNzozODkK bGRhcF9wdnRfY29ubmVjdDogZmQ6IDMgdG06IC0xIGFzeW5jOiAwCmF0dGVtcHRpbmcgdG8g Y29ubmVjdDogCmNvbm5lY3Qgc3VjY2VzcwpsZGFwX29wZW5fZGVmY29ubjogc3VjY2Vzc2Z1 bApsZGFwX3NlbmRfc2VydmVyX3JlcXVlc3QKYmVyX3NjYW5mIGZtdCAoe2l0KSBiZXI6CmJl cl9zY2FuZiBmbXQgKHtpKSBiZXI6CmJlcl9mbHVzaDI6IDk3IGJ5dGVzIHRvIHNkIDMKbGRh cF93cml0ZTogd2FudD05Nywgd3JpdHRlbj05NwogIDAwMDA6ICAzMCA1ZiAwMiAwMSAwMSA2 MCAzYiAwMiAgMDEgMDMgMDQgMmEgNjMgNmUgM2QgNTcgICAwXy4uLmA7Li4uLipjbj1XICAK ICAwMDEwOiAgNjkgNmMgNmMgNjkgNjEgNmQgMjAgNDIgIDc1IDczIDY4IDJjIDZmIDc1IDNk IDcwICAgaWxsaWFtIEJ1c2gsb3U9cCAgCiAgMDAyMDogIDY1IDZmIDcwIDZjIDY1IDJjIDY0 IDYzICAzZCA2NSA3OCA2MSA2ZCA3MCA2YyA2NSAgIGVvcGxlLGRjPWV4YW1wbGUgIAogIDAw MzA6ICAyYyA2NCA2MyAzZCA3MyA2YiA4MCAwYSAgNmEgNjEgNjggNmYgNjQgNjEgMmUgMzEg ICAsZGM9c2suLmphaG9kYS4xICAKICAwMDQwOiAgMzIgMzMgYTAgMWQgMzAgMWIgMDQgMTkg IDMxIDJlIDMzIDJlIDM2IDJlIDMxIDJlICAgMjMuLjAuLi4xLjMuNi4xLiAgCiAgMDA1MDog IDM0IDJlIDMxIDJlIDM0IDMyIDJlIDMyICAyZSAzMiAzNyAyZSAzOCAyZSAzNSAyZSAgIDQu MS40Mi4yLjI3LjguNS4gIAogIDAwNjA6ICAzMSAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAKbGRhcF9yZXN1bHQg bGQgMHg3ZmMwZTg1N2JkNTAgbXNnaWQgMQp3YWl0NG1zZyBsZCAweDdmYzBlODU3YmQ1MCBt c2dpZCAxIChpbmZpbml0ZSB0aW1lb3V0KQp3YWl0NG1zZyBjb250aW51ZSBsZCAweDdmYzBl ODU3YmQ1MCBtc2dpZCAxIGFsbCAxCioqIGxkIDB4N2ZjMGU4NTdiZDUwIENvbm5lY3Rpb25z OgoqIGhvc3Q6IHZtLTEzNy5pZG0ubGFiLmxvY2FsICBwb3J0OiAzODkgIChkZWZhdWx0KQog IHJlZmNudDogMiAgc3RhdHVzOiBDb25uZWN0ZWQKICBsYXN0IHVzZWQ6IE1vbiBEZWMgIDkg MTM6MTU6MTQgMjAxMwoKCioqIGxkIDB4N2ZjMGU4NTdiZDUwIE91dHN0YW5kaW5nIFJlcXVl c3RzOgogKiBtc2dpZCAxLCAgb3JpZ2lkIDEsIHN0YXR1cyBJblByb2dyZXNzCiAgIG91dHN0 YW5kaW5nIHJlZmVycmFscyAwLCBwYXJlbnQgY291bnQgMAogIGxkIDB4N2ZjMGU4NTdiZDUw IHJlcXVlc3QgY291bnQgMSAoYWJhbmRvbmVkIDApCioqIGxkIDB4N2ZjMGU4NTdiZDUwIFJl c3BvbnNlIFF1ZXVlOgogICBFbXB0eQogIGxkIDB4N2ZjMGU4NTdiZDUwIHJlc3BvbnNlIGNv dW50IDAKbGRhcF9jaGtSZXNwb25zZUxpc3QgbGQgMHg3ZmMwZTg1N2JkNTAgbXNnaWQgMSBh bGwgMQpsZGFwX2Noa1Jlc3BvbnNlTGlzdCByZXR1cm5zIGxkIDB4N2ZjMGU4NTdiZDUwIE5V TEwKbGRhcF9pbnRfc2VsZWN0CnJlYWQxbXNnOiBsZCAweDdmYzBlODU3YmQ1MCBtc2dpZCAx IGFsbCAxCmJlcl9nZXRfbmV4dApsZGFwX3JlYWQ6IHdhbnQ9OCwgZ290PTgKICAwMDAwOiAg MzAgMmIgMDIgMDEgMDEgNjEgMDcgMGEgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCsu Li5hLi4gICAgICAgICAgCmxkYXBfcmVhZDogd2FudD0zNywgZ290PTM3CiAgMDAwMDogIDAx IDAwIDA0IDAwIDA0IDAwIGEwIDFkICAzMCAxYiAwNCAxOSAzMSAyZSAzMyAyZSAgIC4uLi4u Li4uMC4uLjEuMy4gIAogIDAwMTA6ICAzNiAyZSAzMSAyZSAzNCAyZSAzMSAyZSAgMzQgMzIg MmUgMzIgMmUgMzIgMzcgMmUgICA2LjEuNC4xLjQyLjIuMjcuICAKICAwMDIwOiAgMzggMmUg MzUgMmUgMzEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOC41LjEgICAg ICAgICAgICAgCmJlcl9nZXRfbmV4dDogdGFnIDB4MzAgbGVuIDQzIGNvbnRlbnRzOgpyZWFk MW1zZzogbGQgMHg3ZmMwZTg1N2JkNTAgbXNnaWQgMSBtZXNzYWdlIHR5cGUgYmluZApiZXJf c2NhbmYgZm10ICh7ZUFBKSBiZXI6CnJlYWQxbXNnOiBsZCAweDdmYzBlODU3YmQ1MCAwIG5l dyByZWZlcnJhbHMKcmVhZDFtc2c6ICBtYXJrIHJlcXVlc3QgY29tcGxldGVkLCBsZCAweDdm YzBlODU3YmQ1MCBtc2dpZCAxCnJlcXVlc3QgZG9uZTogbGQgMHg3ZmMwZTg1N2JkNTAgbXNn aWQgMQpyZXNfZXJybm86IDAsIHJlc19lcnJvcjogPD4sIHJlc19tYXRjaGVkOiA8PgpsZGFw X2ZyZWVfcmVxdWVzdCAob3JpZ2lkIDEsIG1zZ2lkIDEpCmxkYXBfcGFyc2VfcmVzdWx0CmJl cl9zY2FuZiBmbXQgKHtpQUEpIGJlcjoKYmVyX3NjYW5mIGZtdCAoe2EpIGJlcjoKYmVyX3Nj YW5mIGZtdCAofSkgYmVyOgpsZGFwX21zZ2ZyZWUKbGRhcHdob2FtaTogaW8uYzoxMDg6IGJl cl93cml0ZTogQXNzZXJ0aW9uIGBidWYgIT0gKCh2b2lkICopMCknIGZhaWxlZC4KQWJvcnRl ZCAoY29yZSBkdW1wZWQpCltyb290QHZtLTIxOSB+XSMK --------------050905040301060400050300--

1 0

Re: (ITS#7754) Unaligned MDB_DUPSORT sub-pages
by hyc＠symas.com 09 Dec '13

09 Dec '13

h.b.furuseth(a)usit.uio.no wrote: > I wrote: >> (...) >> A fix with a format change would be to put the padding byte in front >> of the sub-page instead of at the end. Sounds fine to me. back-mdb only uses even-sized keys with DUPSORT, so this change has no impact on OpenLDAP. And most likely no one else has hit this situation yet otherwise they'd be crashing. > Ignore next paragraph: >> One fix with a format change could be that the data item gets uneven >> size too, with a padding byte in front of the sub-page. > > Because that's repeated as the 2nd alternative after this one: > >> The most general way would be to do that in all nodes with uneven- >> sized key and even-sized data: > -- -- 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#7759) Wrong parsing of LDAP message
by hyc＠symas.com 09 Dec '13

09 Dec '13

Lukas Slebodnik wrote: > On (09/12/13 00:59), Howard Chu wrote: >> Lukas Slebodnik wrote: >>> On (07/12/13 08:37), Howard Chu wrote: >>>> lslebodn(a)redhat.com wrote: >>>>> Full_Name: Lukas Slebodnik >>>>> Version: 2.4.38 >>>>> OS: Fedora >>>>> URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz >>>>> Submission from: (NULL) (209.132.186.34) >>>> >>>> Fixed now in git master. >>> >>> Thank you. >>> >>> According commit 80e6316d37dd024bf32ed6db024f195c1b51ef7f, it seems to me >>> I was right that ApacheDS send wrong response. >>> Could you confirm this statement? because I am not expert in ldap protocol >>> and I would like to file a bug to ApacheDS upstream. >> >> The hex dumps you included were a bit difficult to read. I couldn't >> tell what was sent from the server vs the client and what the message >> boundaries were. > It is output directly from wireshark. Indented lines represent response > from server. > > ldap_communication_without_PP.hexdump > ---------------------------------------------------------------------------- > 00000000 30 5f 02 01 01 60 3b 02 01 03 04 2a 63 6e 3d 57 0_...`;. ...*cn=W > 00000010 69 6c 6c 69 61 6d 20 42 75 73 68 2c 6f 75 3d 70 illiam B ush,ou=p > 00000020 65 6f 70 6c 65 2c 64 63 3d 65 78 61 6d 70 6c 65 eople,dc =example > 00000030 2c 64 63 3d 73 6b 80 0a 6a 61 68 6f 64 61 2e 31 ,dc=sk.. jahoda.1 > 00000040 32 33 a0 1d 30 1b 04 19 31 2e 33 2e 36 2e 31 2e 23..0... 1.3.6.1. > 00000050 34 2e 31 2e 34 32 2e 32 2e 32 37 2e 38 2e 35 2e 4.1.42.2 .27.8.5. > 00000060 31 1 > ^^^^^^^^ > client > > 00000000 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a.. ...... > ^^^^^^^^ > server > > 00000061 30 05 02 01 02 42 00 0....B. > ^^^^^^^^ > client > ---------------------------------------------------------------------------- > >> If you can reproduce the behavior using e.g. >> ldapwhoami -d7 that would be more legible. > output from command ldapwhoami is in the attached file screenlog.2 > but it loks like ApacheDS does not support LDAP_EXOP_WHO_AM_I. The point was to show a Bind request using the ppolicy control. The actual WhoAmI operation was irrelevant. But you didn't specify ppolicy in your invocation. Please read the ldapwhoami manpage. Use -E ppolicy to use the ppolicy control, the screenlog you attached has nothing interesting without the ppolicy traffic. >> Meanwhile you can refer to draft-behera-ldap-password-policy for the >> specification of the response control. The control value is mandatory >> for this control. > If I read draft "6.2. Response Control" correctly, > http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2 > response can be sequence of "PasswordPolicyResponseValue". > I think that sequence means "0 or more values" The sequence is required to begin with a Sequence marker. > In theory, there needn't be any password policy response value after control > type. In this case, either my patch or your patch are wrong. > Did I miss something? > > The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is > the BER encoding of the following type: "the controlValue is the BER encoding of a Sequence." - even if the sequence has zero members, it cannot be omitted. > PasswordPolicyResponseValue ::= SEQUENCE { > warning [0] CHOICE { > ...snip... } OPTIONAL, > error [1] ENUMERATED { > ...snip... } OPTIONAL > } > > Thank you very much for response. > > LS > -- -- 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#7753) "make" should not be hardcoded
by hyc＠symas.com 09 Dec '13

09 Dec '13

dam(a)opencsw.org wrote: > Full_Name: Dagobert Michelsen > Version: 2.4.38 > OS: Solaris > URL: http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/fi… > Submission from: (NULL) (86.103.212.188) > > > In Makefile.in the tests are invoked with "make test" which breaks if make has a > different name (e.g. gmake) and should better be invoked with "$(MAKE) test". > > This tiny patch also fixes the issue: > http://sourceforge.net/apps/trac/gar/browser/csw/mgar/pkg/openldap/trunk/fi… > > Thanks, fixed now 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

Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com 09 Dec '13

09 Dec '13

Lukas Slebodnik wrote: > On (07/12/13 08:37), Howard Chu wrote: >> lslebodn(a)redhat.com wrote: >>> Full_Name: Lukas Slebodnik >>> Version: 2.4.38 >>> OS: Fedora >>> URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz >>> Submission from: (NULL) (209.132.186.34) >> >> Fixed now in git master. > > Thank you. > > According commit 80e6316d37dd024bf32ed6db024f195c1b51ef7f, it seems to me > I was right that ApacheDS send wrong response. > Could you confirm this statement? because I am not expert in ldap protocol > and I would like to file a bug to ApacheDS upstream. The hex dumps you included were a bit difficult to read. I couldn't tell what was sent from the server vs the client and what the message boundaries were. If you can reproduce the behavior using e.g. ldapwhoami -d7 that would be more legible. Meanwhile you can refer to draft-behera-ldap-password-policy for the specification of the response control. The control value is mandatory for this control. -- -- 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#7760) query of a field with alias returns a different attribute name from requested
by hyc＠symas.com 07 Dec '13

07 Dec '13

mvohlken(a)us.ibm.com wrote: > --0__=0ABBF6ABDFEF16E28f9e8a93df938690918c0ABBF6ABDFEF16E2 > Content-type: text/plain; charset=US-ASCII > Content-transfer-encoding: quoted-printable > > > > Do you understand my point? I make an api call to retrieve the attribut= > e > 'countryName'. The call returns. I then go to get the value I requested= > . So > I look for 'countryName' in the response. But it is not there. This see= > ms > broken to me. > > To find the old ITSes that you mention what do you suggest I search on?= > I > tried 'alias' but there weren't any matches.= I searched for "attribute name alias" and got ITS#2439. http://www.openldap.org/lists/openldap-bugs/200304/msg00063.html Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7759) Wrong parsing of LDAP message
by hyc＠symas.com 07 Dec '13

07 Dec '13

lslebodn(a)redhat.com wrote: > Full_Name: Lukas Slebodnik > Version: 2.4.38 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz > Submission from: (NULL) (209.132.186.34) Fixed now in git master. > > We(sssd) have an upstream ticket with crash. > https://fedorahosted.org/sssd/ticket/2134 > But after investigation, it was not problem in sssd, but in ldap library. > > sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf != > ((void *)0)' failed. > > I think that problem is partially in user LDAP server, because server send wrong > response for user binding with password policy. But on the other hand > ldap_parse_result should not return LDAP_SUCCESS if incoming message is > malformed, because it was a reason why 2nd ldap function > ldap_parse_passwordpolicy_control crashed with abort. > > Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with > libraries from the latest version from git repo(master branch) > > I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with > client-server communication (hexdump from wireshark). 1st with enabled password > policy on server and 2nd with disabled PP. Problem occurs only with enabled > password policy. > > > > > -- -- 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#7759) Wrong parsing of LDAP message
by hyc＠symas.com 07 Dec '13

07 Dec '13

lslebodn(a)redhat.com wrote: > Full_Name: Lukas Slebodnik > Version: 2.4.38 > OS: Fedora > URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz > Submission from: (NULL) (209.132.186.34) > > > We(sssd) have an upstream ticket with crash. > https://fedorahosted.org/sssd/ticket/2134 > But after investigation, it was not problem in sssd, but in ldap library. > > sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf != > ((void *)0)' failed. > > I think that problem is partially in user LDAP server, because server send wrong > response for user binding with password policy. But on the other hand > ldap_parse_result should not return LDAP_SUCCESS if incoming message is > malformed, because it was a reason why 2nd ldap function > ldap_parse_passwordpolicy_control crashed with abort. Thanks for the report, but your patch is wrong, it rejects any control with a NULL value. Not all controls are required to have a value, so your patch would reject otherwise valid controls. > Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with > libraries from the latest version from git repo(master branch) > > I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with > client-server communication (hexdump from wireshark). 1st with enabled password > policy on server and 2nd with disabled PP. Problem occurs only with enabled > password policy. > > > > > -- -- 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#7760) query of a field with alias returns a different attribute name from requested
by michael＠stroeder.com 05 Dec '13

05 Dec '13

This is a cryptographically signed message in MIME format. --------------ms050205040707060002030305 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable mvohlken(a)us.ibm.com wrote: > Do you understand my point? I make an api call to retrieve the attribut= e > 'countryName'. The call returns. I then go to get the value I requested= =2E > So I look for 'countryName' in the response. But it is not there. This > seems broken to me. There's nothing in LDAPv3 saying that the server has to return the same attribute type NAME the client requested. Like it or not - the client has= to deal with it. Ciao, Michael. --------------ms050205040707060002030305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMjA1MjMyOTE5WjAj BgkqhkiG9w0BCQQxFgQUmu7U4IX5djLe1NVraSERo/ZQqcMwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAx+QmKY74wIjiSHgNUfK3vjuJ7okThwZU L6nW+tPmk3fmAQeQ4Xuu55vZZwHTYB+BDThQx1UH5P50OM22esujOF507qW54WWQ5YOlIuni +yE8NithSi66Q4xe3peWFRSY+5Ovv1aaeBkfvNoXR5ktKA+O8TZE9hg/NGTtQ2Dgn2YIsetC /yoOCnjMk3QYhpjE7dOsRL+RNSuhF0Dk/suZXOxd7YhsSEtU6lHZTZVpl/5gcamDdPuXKlPS J2GANImEIbCmAUpkzs3XP8LNCZygd3xNhT5BiJnOCKg68uakbWrkdR0r802BgVN5z5/UhdZF A3jNquiFHIVp4ia4p4cPwgAAAAAAAA== --------------ms050205040707060002030305--

1 0

Re: (ITS#7760) query of a field with alias returns a different attribute name from requested
by mvohlken＠us.ibm.com 05 Dec '13

05 Dec '13

--0__=0ABBF6ABDFEF16E28f9e8a93df938690918c0ABBF6ABDFEF16E2 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Do you understand my point? I make an api call to retrieve the attribut= e 'countryName'. The call returns. I then go to get the value I requested= . So I look for 'countryName' in the response. But it is not there. This see= ms broken to me. To find the old ITSes that you mention what do you suggest I search on?= I tried 'alias' but there weren't any matches.= --0__=0ABBF6ABDFEF16E28f9e8a93df938690918c0ABBF6ABDFEF16E2 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> <p><font size=3D"2" face=3D"sans-serif">Do you understand my point? I m= ake an api call to retrieve the attribute 'countryName'. The call retur= ns. I then go to get the value I requested. So I look for 'countryName'= in the response. But it is not there. This seems broken to me. </font>= <br> <br> <font size=3D"2" face=3D"sans-serif">To find the old ITSes that you men= tion what do you suggest I search on? I tried 'alias' but there weren't= any matches.</font></body></html>= --0__=0ABBF6ABDFEF16E28f9e8a93df938690918c0ABBF6ABDFEF16E2--

1 0

Re: (ITS#7760) query of a field with alias returns a different attribute name from requested
by quanah＠zimbra.com 05 Dec '13

05 Dec '13

--On December 5, 2013 at 10:08:30 PM +0000 mvohlken(a)us.ibm.com wrote: > Full_Name: Max Vohlken > Version: 2.4.23 > OS: Linux RHEL 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.20.180.201) > > > Queries against the countryName attribute always return an attribute that > has the name 'c'. 'c' and 'countryName' are aliases for the same > attribute. This should be corrected so that the response uses the name > that was requested instead of the name that is listed first in the schema > definition. The current behavior is correct, your request is incorrect. There's some ancient ITSes about this same issue, I suggest digging them out. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7760) query of a field with alias returns a different attribute name from requested
by quanah＠zimbra.com 05 Dec '13

05 Dec '13

--On December 5, 2013 at 10:08:30 PM +0000 mvohlken(a)us.ibm.com wrote: > Full_Name: Max Vohlken > Version: 2.4.23 > OS: Linux RHEL 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.20.180.201) > > > Queries against the countryName attribute always return an attribute that > has the name 'c'. 'c' and 'countryName' are aliases for the same > attribute. This should be corrected so that the response uses the name > that was requested instead of the name that is listed first in the schema > definition. The current behavior is correct, your request is incorrect. There's some ancient ITSes about this same issue, I suggest digging them out. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7760) query of a field with alias returns a different attribute name from requested
by mvohlken＠us.ibm.com 05 Dec '13

05 Dec '13

Full_Name: Max Vohlken Version: 2.4.23 OS: Linux RHEL 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.20.180.201) Queries against the countryName attribute always return an attribute that has the name 'c'. 'c' and 'countryName' are aliases for the same attribute. This should be corrected so that the response uses the name that was requested instead of the name that is listed first in the schema definition. For example: ldapsearch -x -b ou=people,dc=my-domain,dc=com -h server countryName Returns: # freds, people, my-domain.com dn: uid=freds,ou=people,dc=my-domain,dc=com c: United States I tested this against a Tivoli LDAP server and it always responds with the name of the attribute requested. The schema entry looks like this: {3}( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC4519: two-letter ISO-3166 country code' SUP name SINGLE-VALUE ) If I change it to swap the names like: {3}( 2.5.4.6 NAME ( 'countryName' 'c' ) DESC 'RFC4519: two-letter ISO-3166 country code' SUP name SINGLE-VALUE ) Then countryName is returned as the name of the attribute instead.

1 0

(ITS#7759) Wrong parsing of LDAP message
by lslebodn＠redhat.com 05 Dec '13

05 Dec '13

Full_Name: Lukas Slebodnik Version: 2.4.38 OS: Fedora URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz Submission from: (NULL) (209.132.186.34) We(sssd) have an upstream ticket with crash. https://fedorahosted.org/sssd/ticket/2134 But after investigation, it was not problem in sssd, but in ldap library. sssd_be: ../../../libraries/liblber/io.c:108: ber_write: Assertion `buf != ((void *)0)' failed. I think that problem is partially in user LDAP server, because server send wrong response for user binding with password policy. But on the other hand ldap_parse_result should not return LDAP_SUCCESS if incoming message is malformed, because it was a reason why 2nd ldap function ldap_parse_passwordpolicy_control crashed with abort. Reporter uses old ldap library on Centos 6.4, but I was able to reproduce with libraries from the latest version from git repo(master branch) I uploaded tarball Lukas-Slebodnik-131205.tar.gz with patch and two files with client-server communication (hexdump from wireshark). 1st with enabled password policy on server and 2nd with disabled PP. Problem occurs only with enabled password policy.

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by quanah＠zimbra.com 05 Dec '13

05 Dec '13

--On Thursday, December 05, 2013 8:22 AM -0500 Francis Swasey <Frank.Swasey(a)uvm.edu> wrote: > Well, but -b is working as documented. Sadly, the -s parameter is > deprecated - so, that really shouldn't be used either. Therefore, since > -b simply grabs the -n that would contain the suffix specified (doesn't > do an exact suffix match and fail if not found as you wanted, Quanah) and > -s is deprecated - how is one to accomplish this in the future? >From slapd.conf: suffix <dn suffix> Specify the DN suffix of queries that will be passed to this backend database. Multiple suffix lines can be given and at least one is required for each database definition. >From slapcat: -b suffix Use the specified suffix to determine which database to generate output for. Suffix has as specific meaning. Since there is no database configured with a suffix of cn=accesslog or anything else but "", it should not match. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by Frank.Swasey＠uvm.edu 05 Dec '13

05 Dec '13

On Dec 5, 2013, at 8:37 AM, Pierangelo Masarati <pierangelo.masarati(a)polimi.it> wrote: >> and -s is deprecated - how is one to accomplish this in the future? > > -H, as the man page suggests; -s is deprecated because -H does that and more. Doh! Saw "deprecated" and stopped reading. Too much blood in my caffeine stream, today. Frank

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by pierangelo.masarati＠polimi.it 05 Dec '13

05 Dec '13

On 12/05/2013 02:22 PM, Frank.Swasey(a)uvm.edu wrote: > > --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=us-ascii > > On Dec 4, 2013, at 9:58 PM, quanah(a)zimbra.com wrote: > >> --On Wednesday, December 04, 2013 6:52 PM -0800 Howard Chu = > <hyc(a)symas.com>=20 >> wrote: >> =20 >>> quanah(a)OpenLDAP.org wrote: >>>> Full_Name: Quanah Gibson-Mount >>>> Version: 2.4.35 >>>> OS: Linux 2.6 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (75.111.58.125) >>>> =20 >>>> =20 >>>> If the root of the primary database is "", and you try and export a = > base >>>> that doesn't exist via slapcat, the entire database is exported = > (i.e., >>>> it acts like you specified "" as the base): >>> =20 >>> Works as designed. -b selects the backend that matches the DN you >>> provided. A backend with suffix "" matches anything that nothing more >>> specific matched. If you wanted to filter down to a specific branch, = > you >>> should have used -s. Closing this ITS. >> =20 >> There is no backend matching cn=3Daccesslog. There is only "" and=20 >> "cn=3Dmonitor" on this particular server. The goal here was not to = > export a=20 >> subtree, it was something trying to export the delta-syncrepl = > accesslog on=20 >> a server that didn't have one. That should result in an error, not = > match=20 >> the primary db rooted at "". I certainly wouldn't expect -n 3 to = > default=20 >> to -n 1 if -n 3 doesn't exist. Neither should -b "cn=3Daccesslog" = > default to=20 >> -b "". Those clearly do not match. > > > Well, but -b is working as documented. Sadly, the -s parameter is = > deprecated - so, that really shouldn't be used either. Therefore, since = > -b simply grabs the -n that would contain the suffix specified (doesn't = > do an exact suffix match and fail if not found as you wanted, Quanah) = > and -s is deprecated - how is one to accomplish this in the future? -H, as the man page suggests; -s is deprecated because -H does that and more. p. > > Frank > > --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062 > Content-Transfer-Encoding: 7bit > Content-Disposition: attachment; > filename=signature.asc > Content-Type: application/pgp-signature; > name=signature.asc > Content-Description: Message signed with OpenPGP using GPGMail > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBAgAGBQJSoH4GAAoJEMOj4l6rFnCNMy0QAIpAf0e2XJ5T6/sX2lnaP+ms > DCXvsxIRjy5F/vBKT1VLt0Z9pj6N1fSpnwYg66rViyaN2A3I/2BJfhz2u3V6ita7 > /NeGgt2wEuS1OoVtULlapz1OAf91KuEASw7QLff2QmB3yS2Y3YGVom4Yu/h4EC0h > aEBVKL088gbytJ19mPbRYN+7HYdcbO+QWiMvZER53wSvTV96vkOHFcUcXQf5fj6z > 7QSMLzA9JUFFjYbYpvdjqtE9UqpPgLRLwIihbzN0DTX6HNavYGWPEzQGrMvvoUoN > EP4uWNEGzfeV++yE0PiChGHtyqS/Q94nIQ6P815jBxN583oAtxTfIz6nFOyk4hV4 > RhkdpH36z77S1k/KgWbATt5bUvF/wRzIb3pXY0968gC2XHVfh/KzQtLYcOUNCSBG > yFGbUz9MyBNlicfjlKaDtetHkXUTvS5u8hlx9jO/Ik9L0ZBSzUuWSTQpwt8FXY6T > WTFjeugu/vqxOrRS2/0yrrrT65Z9MbGt32aKk4QwaZOXDJVAoE5o1WScfQsCeX1G > 6DBEC/Y1LXgMcOMCs8aKnzQolnMXAiNz1wuMAMDC8ffSYgA34VR4keCKXcmzonKT > kkiuLCJG2s28vQQrtpwlbnd+OYtAmtBBHcafHZvvYUreap3DlOhbuhbC19QvqCSh > 9WzShIf7BJeIQW/5xeGk > =2cju > -----END PGP SIGNATURE----- > > --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062-- > > > > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by Frank.Swasey＠uvm.edu 05 Dec '13

05 Dec '13

--Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 4, 2013, at 9:58 PM, quanah(a)zimbra.com wrote: > --On Wednesday, December 04, 2013 6:52 PM -0800 Howard Chu = <hyc(a)symas.com>=20 > wrote: >=20 >> quanah(a)OpenLDAP.org wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.35 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.58.125) >>>=20 >>>=20 >>> If the root of the primary database is "", and you try and export a = base >>> that doesn't exist via slapcat, the entire database is exported = (i.e., >>> it acts like you specified "" as the base): >>=20 >> Works as designed. -b selects the backend that matches the DN you >> provided. A backend with suffix "" matches anything that nothing more >> specific matched. If you wanted to filter down to a specific branch, = you >> should have used -s. Closing this ITS. >=20 > There is no backend matching cn=3Daccesslog. There is only "" and=20 > "cn=3Dmonitor" on this particular server. The goal here was not to = export a=20 > subtree, it was something trying to export the delta-syncrepl = accesslog on=20 > a server that didn't have one. That should result in an error, not = match=20 > the primary db rooted at "". I certainly wouldn't expect -n 3 to = default=20 > to -n 1 if -n 3 doesn't exist. Neither should -b "cn=3Daccesslog" = default to=20 > -b "". Those clearly do not match. Well, but -b is working as documented. Sadly, the -s parameter is = deprecated - so, that really shouldn't be used either. Therefore, since = -b simply grabs the -n that would contain the suffix specified (doesn't = do an exact suffix match and fail if not found as you wanted, Quanah) = and -s is deprecated - how is one to accomplish this in the future? Frank --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSoH4GAAoJEMOj4l6rFnCNMy0QAIpAf0e2XJ5T6/sX2lnaP+ms DCXvsxIRjy5F/vBKT1VLt0Z9pj6N1fSpnwYg66rViyaN2A3I/2BJfhz2u3V6ita7 /NeGgt2wEuS1OoVtULlapz1OAf91KuEASw7QLff2QmB3yS2Y3YGVom4Yu/h4EC0h aEBVKL088gbytJ19mPbRYN+7HYdcbO+QWiMvZER53wSvTV96vkOHFcUcXQf5fj6z 7QSMLzA9JUFFjYbYpvdjqtE9UqpPgLRLwIihbzN0DTX6HNavYGWPEzQGrMvvoUoN EP4uWNEGzfeV++yE0PiChGHtyqS/Q94nIQ6P815jBxN583oAtxTfIz6nFOyk4hV4 RhkdpH36z77S1k/KgWbATt5bUvF/wRzIb3pXY0968gC2XHVfh/KzQtLYcOUNCSBG yFGbUz9MyBNlicfjlKaDtetHkXUTvS5u8hlx9jO/Ik9L0ZBSzUuWSTQpwt8FXY6T WTFjeugu/vqxOrRS2/0yrrrT65Z9MbGt32aKk4QwaZOXDJVAoE5o1WScfQsCeX1G 6DBEC/Y1LXgMcOMCs8aKnzQolnMXAiNz1wuMAMDC8ffSYgA34VR4keCKXcmzonKT kkiuLCJG2s28vQQrtpwlbnd+OYtAmtBBHcafHZvvYUreap3DlOhbuhbC19QvqCSh 9WzShIf7BJeIQW/5xeGk =2cju -----END PGP SIGNATURE----- --Apple-Mail=_21ABCED4-5B52-47DB-9CA2-DFB23439A062--

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by quanah＠zimbra.com 04 Dec '13

04 Dec '13

--On Wednesday, December 04, 2013 6:52 PM -0800 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.35 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.58.125) >> >> >> If the root of the primary database is "", and you try and export a base >> that doesn't exist via slapcat, the entire database is exported (i.e., >> it acts like you specified "" as the base): > > Works as designed. -b selects the backend that matches the DN you > provided. A backend with suffix "" matches anything that nothing more > specific matched. If you wanted to filter down to a specific branch, you > should have used -s. Closing this ITS. There is no backend matching cn=accesslog. There is only "" and "cn=monitor" on this particular server. The goal here was not to export a subtree, it was something trying to export the delta-syncrepl accesslog on a server that didn't have one. That should result in an error, not match the primary db rooted at "". I certainly wouldn't expect -n 3 to default to -n 1 if -n 3 doesn't exist. Neither should -b "cn=accesslog" default to -b "". Those clearly do not match. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7758) slapcat exports entire databases when given a non-existent base
by hyc＠symas.com 04 Dec '13

04 Dec '13

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.35 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) > > > If the root of the primary database is "", and you try and export a base that > doesn't exist via slapcat, the entire database is exported (i.e., it acts like > you specified "" as the base): Works as designed. -b selects the backend that matches the DN you provided. A backend with suffix "" matches anything that nothing more specific matched. If you wanted to filter down to a specific branch, you should have used -s. Closing this ITS. > > [root@zcs724 ldap]# /opt/zimbra/openldap/sbin/slapcat -b cn=ThisDoesntExist -F > /opt/zimbra/data/ldap/config -l /tmp/q.test > > dn: cn=zimbra > objectClass: organizationalRole > description: Zimbra Systems Application Data > cn: zimbra > structuralObjectClass: organizationalRole > entryUUID: 1f75edee-6b87-1032-961f-b17f0b52f5bc > creatorsName: cn=config > createTimestamp: 20130617104800Z > entryCSN: 20130617104800.311168Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20130617104800Z > > dn: cn=admins,cn=zimbra > objectClass: organizationalRole > description: admin accounts > cn: admins > structuralObjectClass: organizationalRole > entryUUID: 1f7d451c-6b87-1032-9620-b17f0b52f5bc > creatorsName: cn=config > createTimestamp: 20130617104800Z > entryCSN: 20130617104800.359221Z#000000#000#000000 > modifiersName: cn=config > modifyTimestamp: 20130617104800Z > > dn: uid=zimbra,cn=admins,cn=zimbra > uid: zimbra > objectClass: zimbraAccount > objectClass: organizationalPerson > cn: zimbra > sn: zimbra > zimbraAccountStatus: active > zimbraIsAdminAccount: TRUE > zimbraIsSystemResource: TRUE > zimbraId: e0fafd89-1360-11d9-8661-000a95d98ef2 > description: The master zimbra admin account > userPassword:: text= > structuralObjectClass: organizationalPerson > entryUUID: 1f7e29e6-6b87-1032-9621-b17f0b52f5bc > creatorsName: cn=config > createTimestamp: 20130617104800Z > zimbraLastLogonTimestamp: 20131202121011Z > entryCSN: 20131202121011.054477Z#000000#000#000000 > modifiersName: uid=zimbra,cn=admins,cn=zimbra > modifyTimestamp: 20131202121011Z > > > (etc) > > -- -- 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#7758) slapcat exports entire databases when given a non-existent base
by quanah＠OpenLDAP.org 04 Dec '13

04 Dec '13

Full_Name: Quanah Gibson-Mount Version: 2.4.35 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) If the root of the primary database is "", and you try and export a base that doesn't exist via slapcat, the entire database is exported (i.e., it acts like you specified "" as the base): [root@zcs724 ldap]# /opt/zimbra/openldap/sbin/slapcat -b cn=ThisDoesntExist -F /opt/zimbra/data/ldap/config -l /tmp/q.test dn: cn=zimbra objectClass: organizationalRole description: Zimbra Systems Application Data cn: zimbra structuralObjectClass: organizationalRole entryUUID: 1f75edee-6b87-1032-961f-b17f0b52f5bc creatorsName: cn=config createTimestamp: 20130617104800Z entryCSN: 20130617104800.311168Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130617104800Z dn: cn=admins,cn=zimbra objectClass: organizationalRole description: admin accounts cn: admins structuralObjectClass: organizationalRole entryUUID: 1f7d451c-6b87-1032-9620-b17f0b52f5bc creatorsName: cn=config createTimestamp: 20130617104800Z entryCSN: 20130617104800.359221Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130617104800Z dn: uid=zimbra,cn=admins,cn=zimbra uid: zimbra objectClass: zimbraAccount objectClass: organizationalPerson cn: zimbra sn: zimbra zimbraAccountStatus: active zimbraIsAdminAccount: TRUE zimbraIsSystemResource: TRUE zimbraId: e0fafd89-1360-11d9-8661-000a95d98ef2 description: The master zimbra admin account userPassword:: text= structuralObjectClass: organizationalPerson entryUUID: 1f7e29e6-6b87-1032-9621-b17f0b52f5bc creatorsName: cn=config createTimestamp: 20130617104800Z zimbraLastLogonTimestamp: 20131202121011Z entryCSN: 20131202121011.054477Z#000000#000#000000 modifiersName: uid=zimbra,cn=admins,cn=zimbra modifyTimestamp: 20131202121011Z (etc)

1 0

Re: (ITS#7757) Memory leak
by huaraz＠moeller.plus.com 03 Dec '13

03 Dec '13

That was quick ! And my leak is gone. Thank you Markus -----Original Message----- From: Howard Chu Sent: Tuesday, December 03, 2013 10:17 PM To: huaraz(a)moeller.plus.com ; openldap-its(a)openldap.org Subject: Re: (ITS#7757) Memory leak huaraz(a)moeller.plus.com wrote: > Full_Name: > Version: 2.4.33 > OS: OpenSuSe 12.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:348:1f9::11) > > > I identified a memory leak when using sasl > > ==14039== 34 (32 direct, 2 indirect) bytes in 2 blocks are definitely lost > in > loss record 561 of 666 > ==14039== at 0x4C2C27B: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==14039== by 0x558E764: ber_memalloc_x (memory.c:228) > ==14039== by 0x558A8B7: ber_get_stringal (decode.c:582) > ==14039== by 0x558AFF5: ber_scanf (decode.c:806) > ==14039== by 0x535535D: ldap_parse_sasl_bind_result (sasl.c:327) > ==14039== by 0x5351FE1: ldap_int_sasl_bind (cyrus.c:551) > ==14039== by 0x5355810: ldap_sasl_interactive_bind (sasl.c:474) > ==14039== by 0x5355A0C: ldap_sasl_interactive_bind_s (sasl.c:511) > ==14039== by 0x44DDC9: tool_sasl_bind (ldap.c:2338) A fix for this is now in git master (rev f8efeb42783f958dd0dc997f8084e6b3b4502830 ) Please test and report your results, thanks. -- -- 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#7757) Memory leak
by hyc＠symas.com 03 Dec '13

03 Dec '13

huaraz(a)moeller.plus.com wrote: > Full_Name: > Version: 2.4.33 > OS: OpenSuSe 12.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:348:1f9::11) > > > I identified a memory leak when using sasl > > ==14039== 34 (32 direct, 2 indirect) bytes in 2 blocks are definitely lost in > loss record 561 of 666 > ==14039== at 0x4C2C27B: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==14039== by 0x558E764: ber_memalloc_x (memory.c:228) > ==14039== by 0x558A8B7: ber_get_stringal (decode.c:582) > ==14039== by 0x558AFF5: ber_scanf (decode.c:806) > ==14039== by 0x535535D: ldap_parse_sasl_bind_result (sasl.c:327) > ==14039== by 0x5351FE1: ldap_int_sasl_bind (cyrus.c:551) > ==14039== by 0x5355810: ldap_sasl_interactive_bind (sasl.c:474) > ==14039== by 0x5355A0C: ldap_sasl_interactive_bind_s (sasl.c:511) > ==14039== by 0x44DDC9: tool_sasl_bind (ldap.c:2338) A fix for this is now in git master (rev f8efeb42783f958dd0dc997f8084e6b3b4502830 ) Please test and report your results, thanks. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs