- openldap-bugs - openldap.org

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by hyc＠symas.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Let's assume the policy for a deployment is that password changes MUST be >>> applied by using password modify ext. op. (e.g. because smbk5pwd is >>> used or >>> similar) and you want to use object class 'account' for user entries. How >>> could the attribute 'userPassword' be added to the user entry then? >>> It's kind >>> of a dead-lock situation. >> >> Then you made a mistake in your data design. > > Nope. Since with a modify request I can achieve the goal by adding object > class 'simpleSecurityObject'. IMO password modify ext.op. should result in > userPassword being added. One could view it as a hen-and-egg problem because > 'simpleSecurityObject' is mandating 'userPassword'. Since the ppolicy overlay already provides the facility for hashing plaintext passwords on Add and Modify, there's no reason you couldn't have just created the objects correctly in the first place. >> You should have chosen an >> objectclass (or set of objectclasses) that supports authentication from >> the outset. To me this is analogous to the usual prohibition against >> changing an object's structural class - you cannot change a car into a >> pencil. You cannot change a non-user into a user. > > Please don't compare apples with pies. It was an analogy, not a literal comparison. Don't lose the main point, which is that changing a non-user into a user is a significant change in the purpose of an object. -- -- 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#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Let's assume the policy for a deployment is that password changes MUST be >>> applied by using password modify ext. op. (e.g. because smbk5pwd is >>> used or >>> similar) and you want to use object class 'account' for user entries. How >>> could the attribute 'userPassword' be added to the user entry then? >>> It's kind >>> of a dead-lock situation. >> Then you made a mistake in your data design. > > Nope. Since with a modify request I can achieve the goal by adding object > class 'simpleSecurityObject'. IMO password modify ext.op. should result in > userPassword being added. One could view it as a hen-and-egg problem because > 'simpleSecurityObject' is mandating 'userPassword'. I agree with Hallvard that this should be made configurable. So the admin could specify whether and which AUXILIARY object class is added. Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Howard Chu wrote: > Michael Ströder wrote: >> Let's assume the policy for a deployment is that password changes MUST be >> applied by using password modify ext. op. (e.g. because smbk5pwd is >> used or >> similar) and you want to use object class 'account' for user entries. How >> could the attribute 'userPassword' be added to the user entry then? >> It's kind >> of a dead-lock situation. > > Then you made a mistake in your data design. Nope. Since with a modify request I can achieve the goal by adding object class 'simpleSecurityObject'. IMO password modify ext.op. should result in userPassword being added. One could view it as a hen-and-egg problem because 'simpleSecurityObject' is mandating 'userPassword'. > You should have chosen an > objectclass (or set of objectclasses) that supports authentication from > the outset. To me this is analogous to the usual prohibition against > changing an object's structural class - you cannot change a car into a > pencil. You cannot change a non-user into a user. Please don't compare apples with pies. 'account' is STRUCTURAL so the user entry represents already a user. 'simpleSecurityObject' is AUXILIARY (not STRUCTURAL) which adds another attribute. The STRUCTURAL object class of the entry is not altered, so no magic change from a car into a pencil here. Ciao, Michael.

1 0

Re: (ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by michael＠stroeder.com 11 Aug '09

11 Aug '09

hyc(a)symas.com wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Ströder >>>> Version: HEAD >>>> OS: >>>> URL: >>>> Submission from: (NULL) (84.163.50.194) >>>> >>>> I'd like to request that a Password Modify ext. op. request should succeed on a >>>> LDAP connection as anonymous if the LDAP client provides the correct old >>>> password. >>>> >>>> E.g. OpenDS implements it like this and it makes sense to me regarding a user >>>> setting a new password in case of an expired password. >>> Adding this feature would open up the pwdModify exop as a mechanism for >>> password guessing attacks. >> There could be still the bad password counter in effect just like when >> processing bind requests. > > But there is no corresponding lockout action to take when a maxfailure limit > is reached. I.e., it is impossible to lockout "anonymous". You thus open a > security hole that cannot be closed. The password modify ext.op. request contains the DN (or username) of the entry to which the old password belongs. Since the old password is really checked you could apply the lockout to the entry for which the password is going to be changed. (It fails with Server is "unwilling to perform: unwilling to verify old password." even if the user is bound on that connection.) Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by hyc＠symas.com 11 Aug '09

11 Aug '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: openSUSE Linux 11.1 >>> URL: >>> Submission from: (NULL) (84.163.50.194) >>> >>> >>> If one trys to set the userPassword with a Password Modify ext. op. request but >>> the object classes of the entry does not allow userPassword slapd could add >>> automagically AUXILIARY object class simpleSecurityObject to the entry. >>> >>> (I'm doing this in web2ldap since years when changing the userPassword with a >>> normal modify operation which client-side hashing.) >> >> This request sounds like a mistake to me. The DSA is supposed to enforce the >> data model, not automagically enable you to bypass the model. What clients do >> is a completely separate matter... > > Let's assume the policy for a deployment is that password changes MUST be > applied by using password modify ext. op. (e.g. because smbk5pwd is used or > similar) and you want to use object class 'account' for user entries. How > could the attribute 'userPassword' be added to the user entry then? It's kind > of a dead-lock situation. Then you made a mistake in your data design. You should have chosen an objectclass (or set of objectclasses) that supports authentication from the outset. To me this is analogous to the usual prohibition against changing an object's structural class - you cannot change a car into a pencil. You cannot change a non-user into a user. -- -- 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#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by hyc＠symas.com 11 Aug '09

11 Aug '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: >>> URL: >>> Submission from: (NULL) (84.163.50.194) >>> >>> I'd like to request that a Password Modify ext. op. request should succeed on a >>> LDAP connection as anonymous if the LDAP client provides the correct old >>> password. >>> >>> E.g. OpenDS implements it like this and it makes sense to me regarding a user >>> setting a new password in case of an expired password. >> >> Adding this feature would open up the pwdModify exop as a mechanism for >> password guessing attacks. > > There could be still the bad password counter in effect just like when > processing bind requests. But there is no corresponding lockout action to take when a maxfailure limit is reached. I.e., it is impossible to lockout "anonymous". You thus open a security hole that cannot be closed. Again - No. -- -- 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#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: openSUSE Linux 11.1 >> URL: >> Submission from: (NULL) (84.163.50.194) >> >> >> If one trys to set the userPassword with a Password Modify ext. op. request but >> the object classes of the entry does not allow userPassword slapd could add >> automagically AUXILIARY object class simpleSecurityObject to the entry. >> >> (I'm doing this in web2ldap since years when changing the userPassword with a >> normal modify operation which client-side hashing.) > > This request sounds like a mistake to me. The DSA is supposed to enforce the > data model, not automagically enable you to bypass the model. What clients do > is a completely separate matter... Let's assume the policy for a deployment is that password changes MUST be applied by using password modify ext. op. (e.g. because smbk5pwd is used or similar) and you want to use object class 'account' for user entries. How could the attribute 'userPassword' be added to the user entry then? It's kind of a dead-lock situation. Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by h.b.furuseth＠usit.uio.no 11 Aug '09

11 Aug '09

Sorry, sent too early. > It makes sense if you add a config parameter with an LDAP URL or > something describing entries which can be so modified (subject to > ordinary access controls). I imagine one would typically filter for objectClass, e.g. ldap:///???(objectClass=person)

1 0

Re: (ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by michael＠stroeder.com 11 Aug '09

11 Aug '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: >> URL: >> Submission from: (NULL) (84.163.50.194) >> >> I'd like to request that a Password Modify ext. op. request should succeed on a >> LDAP connection as anonymous if the LDAP client provides the correct old >> password. >> >> E.g. OpenDS implements it like this and it makes sense to me regarding a user >> setting a new password in case of an expired password. > > Adding this feature would open up the pwdModify exop as a mechanism for > password guessing attacks. There could be still the bad password counter in effect just like when processing bind requests. Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by h.b.furuseth＠usit.uio.no 11 Aug '09

11 Aug '09

hyc(a)symas.com writes: > This request sounds like a mistake to me. The DSA is supposed to > enforce the data model, not automagically enable you to bypass the > model. What clients do is a completely separate matter... It makes sense if you add a config parameter with an LDAP URL or something describing entries which can be so modified (subject to ordinary access controls). -- Hallvard

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by hyc＠symas.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.50.194) > > > If one trys to set the userPassword with a Password Modify ext. op. request but > the object classes of the entry does not allow userPassword slapd could add > automagically AUXILIARY object class simpleSecurityObject to the entry. > > (I'm doing this in web2ldap since years when changing the userPassword with a > normal modify operation which client-side hashing.) This request sounds like a mistake to me. The DSA is supposed to enforce the data model, not automagically enable you to bypass the model. What clients do is a completely separate matter... -- -- 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#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by hyc＠symas.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: > URL: > Submission from: (NULL) (84.163.50.194) > > > I'd like to request that a Password Modify ext. op. request should succeed on a > LDAP connection as anonymous if the LDAP client provides the correct old > password. > > E.g. OpenDS implements it like this and it makes sense to me regarding a user > setting a new password in case of an expired password. Adding this feature would open up the pwdModify exop as a mechanism for password guessing attacks. In fact, in the next draft of the ppolicy spec I was intending to explicitly forbid this type of usage, to prevent such attacks. http://www.openldap.org/lists/ietf-ldapext/200908/msg00006.html The ppolicy spec provides for grace logins after a password is expired, to give users a few last opportunities to change their password. If they don't take advantage of those grace logins, then they are out of luck and must get help from a password administrator. I'm going to reject 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

(ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.50.194) If one trys to set the userPassword with a Password Modify ext. op. request but the object classes of the entry does not allow userPassword slapd could add automagically AUXILIARY object class simpleSecurityObject to the entry. (I'm doing this in web2ldap since years when changing the userPassword with a normal modify operation which client-side hashing.)

1 0

(ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.50.194) I'd like to request that a Password Modify ext. op. request should succeed on a LDAP connection as anonymous if the LDAP client provides the correct old password. E.g. OpenDS implements it like this and it makes sense to me regarding a user setting a new password in case of an expired password.

1 0

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2
by Ed＠vanGasteren.net 11 Aug '09

11 Aug '09

On 08/11/2009 04:44 AM, Howard Chu wrote: > Ed(a)vanGasteren.net wrote: >> Full_Name: Ed van Gasteren >> Version: 2.4.12 and 2.4.15 >> OS: linux (Fedora 10, 11) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (85.223.76.221) >> >> >> On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server >> and clients. >> The configuration is such that things work as expected even with security >> tightened up to "TLSVerifyClient demand". ldapsearch (either to -H >> ldaps or with >> -ZZ), nss and gq with TLS work like a charm. >> >> On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), >> gq and >> Thunderbird connecting to the server on lt2. TLS/SSL only works if I >> run slapd >> with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS >> trace: >> SSL_connect:SSLv3 read server certificate A". >> >> Seems as if the normal code path has a flaw which gets >> corrected/bypassed by the >> debugging code. > > Doesn't sound familiar, I've never had this problem. However, the TLS > code was refactored in rev 2.4.14, and it's always possible we missed > something in the churn. How does openssl s_client react under the same > conditions? If it hangs the same way, then that points to a bug on the Should have mentioned that. It indeed hangs the same way, in the middle of getting over the "Acceptable client certificate CA names". The last debug info from s_client suggests it is getting less of the list then in expects: read from 0x8c13300 [0x8c19915] (16384 bytes => 10395 The last one coming across correctly is: /C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network The one not coming is: /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 1 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com > server, and the answer is just to upgrade since .12 is rather out of Hm! I'll see if I can get the 2.4.15 openldap stuff from Fedora 11 repo's running on lt2 first. > date now. If s_client works, then we probably have to look at our client > code. >

1 0

(ITS#6248) Support multiple CA Cert directories
by quanah＠zimbra.com 10 Aug '09

10 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.x OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Both openssl and gnutls support loading CA certs from multiple directories. It would be handy to be able to do this for slapd and the ldap clients. For example, zimbra puts its CA certs in /opt/zimbra/conf/ca, but the system it is installed upon is going to have a different default destination for where its ldap clients look for CA certs. By having support for the multiple paths, the configuration can be adjusted to look in both the system location, and any number of specialized ones.

1 0

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2
by hyc＠symas.com 10 Aug '09

10 Aug '09

Ed(a)vanGasteren.net wrote: > Full_Name: Ed van Gasteren > Version: 2.4.12 and 2.4.15 > OS: linux (Fedora 10, 11) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.223.76.221) > > > On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server and clients. > The configuration is such that things work as expected even with security > tightened up to "TLSVerifyClient demand". ldapsearch (either to -H ldaps or with > -ZZ), nss and gq with TLS work like a charm. > > On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), gq and > Thunderbird connecting to the server on lt2. TLS/SSL only works if I run slapd > with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS trace: > SSL_connect:SSLv3 read server certificate A". > > Seems as if the normal code path has a flaw which gets corrected/bypassed by the > debugging code. Doesn't sound familiar, I've never had this problem. However, the TLS code was refactored in rev 2.4.14, and it's always possible we missed something in the churn. How does openssl s_client react under the same conditions? If it hangs the same way, then that points to a bug on the server, and the answer is just to upgrade since .12 is rather out of date now. If s_client works, then we probably have to look at our client code. -- -- 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#6247) slapd-modules/now: New matching rules that enable comparisone slapd's current server time against timestamp attributes
by daniel＠pluta.biz 10 Aug '09

10 Aug '09

Full_Name: Daniel Pluta Version: CVS OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-now-090810.tgz Submission from: (NULL) (91.12.197.171) Please see the README for details. Currently only a DUMMY_OID is assigned to the matching rules and the limited internal attribute and objectclass definitions. I would appreciate your feedback. Thanks!

1 0

(ITS#6246) SSL fails over a network unless slapd runs with -d 2
by Ed＠vanGasteren.net 10 Aug '09

10 Aug '09

Full_Name: Ed van Gasteren Version: 2.4.12 and 2.4.15 OS: linux (Fedora 10, 11) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.223.76.221) On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server and clients. The configuration is such that things work as expected even with security tightened up to "TLSVerifyClient demand". ldapsearch (either to -H ldaps or with -ZZ), nss and gq with TLS work like a charm. On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), gq and Thunderbird connecting to the server on lt2. TLS/SSL only works if I run slapd with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS trace: SSL_connect:SSLv3 read server certificate A". Seems as if the normal code path has a flaw which gets corrected/bypassed by the debugging code. What puzzels me is that I find few references (google) to these kind of problems as if nobody uses it this way. - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412706 There they blame it on GnuTLS. Here the symptoms are similar but GnuTLS is not in the picture. - I have searched the openldap Mailing Lists archives for "ssl;client;server;-d 2". That gives a few hits with very similar problems but the threads provide no solution. I can provide loads of additional detail about my configuration and debug output of the server and the ldapsearch client but I prefer to get some pointers about what to test, look for or provide.

1 0

RE: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by evaristo-jose.camarero＠ericsson.com 10 Aug '09

10 Aug '09

=20 It looks that I sent an email that was unreadable. Sorry for that. I recap the content: The traffic model we are testing contains search and modify operations. = The search response contains usually a single entry about 3KB in LDIF = format. There is only a reduce number of LDAP clients (usually one or = two), that are using async LDAP API and sending a lot of operations per = second (> 1000 TPS per client). The client side is an OS Delta box. Under these conditions we have tested that increasing the sending buffer = of the server has improved the performance. That's the reason I am = proposing this feature request. Pierangelo's proposal allowing hard-set the buffer sizes looks ok. Regards, Evaristo ----- Mensaje reenviado ---- De: Pierangelo Masarati <masarati(a)aero.polimi.it> Para: evaristojosec(a)yahoo.es CC: openldap-its(a)openldap.org Enviado: martes, 4 de agosto, 2009 9:54:19 Asunto: Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST Your message was unreadable, you should use text form for messages sent = to the ITS. In any case, according to many sources, the default values for TCP = buffers can be pretty small. Usually, they can be configured = system-wide at the OS level (see tcp(7)), or even auto-tuned. Personally, I have no objections in optionally allowing to hard-set the = buffer sizes to values one considers appropriate for the intended use of = slapd. Since the optimal size roughly depends on latency and bandwidth, = this may probably need to be configured on a per-listener basis, = actually. However, in deployments where this problem becomes critical, usually = hardware dedicated to slapd is used, so system-wide tuning (and = auto-tuning) would be the preferred option anyway. Manual setting = should be used only when system-wide or auto-tuning is not available or = accessible for some reason. p. =20

1 0

Re: (ITS#6245) back-config allows empty add operation
by quanah＠zimbra.com 08 Aug '09

08 Aug '09

--On Saturday, August 08, 2009 10:07 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) I guess they may be liberally legal.. It also updates the contextCSN and the accesslog database. dn: reqStart=20090808223406.000005Z,cn=accesslog objectClass: auditModify reqStart: 20090808223406.000005Z reqEnd: 20090808223409.000000Z reqType: modify reqSession: 214 reqAuthzID: cn=config reqDN: cn=zimbra reqResult: 0 reqMod: entryCSN:= 20090808223406.630393Z#000000#000#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20090808223406Z Seems janky to me. :P --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6245) back-config allows empty add operation
by quanah＠zimbra.com 08 Aug '09

08 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) [zimbra@freelancer ~]$ ldapmodify -x -H ldapi:/// -D cn=config -W Enter LDAP Password: dn: olcDatabase={2}hdb,cn=config changetype:modify add: modifying entry "olcDatabase={2}hdb,cn=config" dn: olcDatabase={2}hdb,cn=config changetype:modify add: modifying entry "olcDatabase={2}hdb,cn=config" Log shows it happening, too: Aug 8 15:08:50 freelancer slapd[1937]: conn=16 fd=23 ACCEPT from PATH=/opt/zimbra/openldap-2.4.17.8z/var/run/ldapi (PATH=/opt/zimbra/openldap-2.4.17.8z/var/run/ldapi) Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 BIND dn="cn=config" method=128 Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 RESULT tag=97 err=0 text= Aug 8 15:08:52 freelancer slapd[1937]: conn=16 op=1 MOD dn="olcDatabase={2}hdb,cn=config" Aug 8 15:08:52 freelancer slapd[1937]: conn=16 op=1 RESULT tag=103 err=0 text= Aug 8 15:08:56 freelancer slapd[1937]: conn=16 op=2 MOD dn="olcDatabase={2}hdb,cn=config" Aug 8 15:08:56 freelancer slapd[1937]: conn=16 op=2 RESULT tag=103 err=0 text= Aug 8 15:09:33 freelancer slapd[1937]: conn=16 fd=23 closed (connection lost)

1 0

Re: (ITS#6215) liblber problems
by Kurt＠OpenLDAP.org 07 Aug '09

07 Aug '09

On Aug 7, 2009, at 11:16 AM, h.b.furuseth(a)usit.uio.no wrote: >> - decode.c is quite lax about what it accepts. Should we tighten >> that when feasible, or remain "liberal in what we accept"? Decoding needs to be liberal here. Otherwise interoperability will suffer as it is well established that there exists many implementations which are not strict in what they send. -- Kurt

1 0

Re: (ITS#6215) liblber problems
by h.b.furuseth＠usit.uio.no 07 Aug '09

07 Aug '09

Fixed the above, including malformed bitstrings and set/sequences. Except: Need decision on decode(bad INTEGER/BOOLEAN) and encode(bad tag): > - decode.c is quite lax about what it accepts. Should we tighten > that when feasible, or remain "liberal in what we accept"? > > E.g. it accepts BER INTEGER length 0 and BOOLEAN length != 1, and > wrong CONSTRUCTED/PRIMITIVE encoding bit. > > - encode.c willingly stores broken identifier octets if passed an > invalid tag, e.g. a single octet with low bits 0x1F implying long tag > format. I'm inclined to leave that alone, caller's responsibility. API matters: I'll export the new function ber_peek_element(). And if nobody disagrees, the matching function ber_skip_element() even though that is nearly a duplicate of ber_get_stringbv(,, LBER_BV_NOTERM). -- Hallvard

1 0

Re: (ITS#6227) autogroup overlay breaks all searches
by ryans＠aweber.com 07 Aug '09

07 Aug '09

I can confirm that the segfault on slapadd, slapcat, and friends were in fact a result of this bug. I don't have the strace handy which confirmed it, but after applying Howard's patch and repackaging the .deb (Ubuntu Jaunty), I see none of the aforementioned segfaults. Regards, Ryan -- Ryan Steele ryans-at-aweber-dot-com Systems Administrator +1 215-825-2196 x758 AWeber Communications http://www.aweber.com

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs