- openldap-bugs - openldap.org

Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com 30 Oct '07

30 Oct '07

--On Monday, October 29, 2007 11:45 PM +0000 russell-openldap(a)stuart.id.au wrote: > On Mon, 2007-10-29 at 18:07 +0100, Hallvard B Furuseth wrote: >> No, you've forced users who authenticate against userPassword >> to be encrypted. Not all SASL methods, nor auth with rootpw. > > Thats a worry. Rootpw aside, the intended objective of > the ACL was to ensure passwords were never sent in the > clear. Either a protocol like CRAM-MD5 was used, or the > entire link is encrypted. Does it not do that? (Actually > it doesn't. It should have been sasl_ssf=71. But bugs > aside ...) > > Secondly, just out of curiosity, are there SASL methods > that check a shared secret of some kind and don't use > userPassword? What are they? GSSAPI -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 30 Oct '07

30 Oct '07

On Mon, 2007-10-29 at 18:07 +0100, Hallvard B Furuseth wrote: > No, you've forced users who authenticate against userPassword > to be encrypted. Not all SASL methods, nor auth with rootpw. Thats a worry. Rootpw aside, the intended objective of the ACL was to ensure passwords were never sent in the clear. Either a protocol like CRAM-MD5 was used, or the entire link is encrypted. Does it not do that? (Actually it doesn't. It should have been sasl_ssf=71. But bugs aside ...) Secondly, just out of curiosity, are there SASL methods that check a shared secret of some kind and don't use userPassword? What are they? The "security" option may produce better error messages by it appears to apply to all connections, including lookups done by SASL to dn="" to discover what mechanisms are allowed. It wasn't at all obvious to a newbie like me that this sentence from "man 1 ldapsearch" only applies if you don't use the "security" option: "-Y mech .... If it's not specified, the program will choose the best mechanism the server knows."

1 0

Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com 30 Oct '07

30 Oct '07

--On Monday, October 29, 2007 11:15 PM +0000 hyc(a)symas.com wrote: > Stay focused on the original ITS topic. Discussing further with Howard offline, he notes that ssf=<n> is the minimum, not the requirement, so in the case I was thinking of: security ssf=56 would be sufficient in that specific case, although all connections are forced to be encrypted at that point. I'm not sure the security directive then satisfies allowing anonymous binds to be unencrypted, which is why then using ACL statements is a better route for that data you specifically want to ensure is protected. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 30 Oct '07

30 Oct '07

Quanah Gibson-Mount wrote: > --On Monday, October 29, 2007 10:57 PM +0000 hyc(a)symas.com wrote: >> You don't. That would open you up to a downgrade attack. > So I think the point of the ITS remains. It's difficult to do what they > wanted to do. And really, sometimes all you care is that the connection is > encrypted at a particular base level based on the type of encryption being > done. Which is how it was at Stanford. Which apparently we don't support > using the security directive. Which is why my acl's had sasl_ssf=56 all > over them. Your point and the original ITS are quite different. In your case, you want to require a different SSF based on the underlying mechanism. That is foolish as far as security policy goes; any attacker will simply ignore the stronger defense and focus on breaking the weaker one. As the original poster stated, security is only as strong as the weakest link. Stay focused on the original ITS topic. -- -- Howard Chu Chief Architect, 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#5195) ssf not available during sasl bind
by quanah＠zimbra.com 30 Oct '07

30 Oct '07

--On Monday, October 29, 2007 10:57 PM +0000 hyc(a)symas.com wrote: > You don't. That would open you up to a downgrade attack. So I think the point of the ITS remains. It's difficult to do what they wanted to do. And really, sometimes all you care is that the connection is encrypted at a particular base level based on the type of encryption being done. Which is how it was at Stanford. Which apparently we don't support using the security directive. Which is why my acl's had sasl_ssf=56 all over them. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 29 Oct '07

29 Oct '07

quanah(a)zimbra.com wrote: > --On Monday, October 29, 2007 8:13 PM +0000 hyc(a)symas.com wrote: >> You really need to read more carefully. If you only care about the >> overall SSF, regardless of whether it's from TLS or SASL, then just use >> the "ssf" factor. -- > > Nice, in theory, but I think my example was bad. So let's rehash. > > When I was at Stanford, the SASL SSF max was 56, because of the DES keys. > The TLS SSF was 128. So how would I indicate that I want EITHER a SASL SSF > of 56 or a TLS SSF of 128 using the security directive? You don't. That would open you up to a downgrade attack. -- -- Howard Chu Chief Architect, 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#5195) ssf not available during sasl bind
by quanah＠zimbra.com 29 Oct '07

29 Oct '07

--On Monday, October 29, 2007 8:13 PM +0000 hyc(a)symas.com wrote: > You really need to read more carefully. If you only care about the > overall SSF, regardless of whether it's from TLS or SASL, then just use > the "ssf" factor. -- Nice, in theory, but I think my example was bad. So let's rehash. When I was at Stanford, the SASL SSF max was 56, because of the DES keys. The TLS SSF was 128. So how would I indicate that I want EITHER a SASL SSF of 56 or a TLS SSF of 128 using the security directive? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 29 Oct '07

29 Oct '07

quanah(a)zimbra.com wrote: > --On Monday, October 29, 2007 5:08 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > > >> Also, repeating an old point, remember that the "security" keyword >> produces better error messages ("Confidentiality required") than >> "access ... ssf=..." ("Insufficient access" for updates, "Invalid >> credentials" for Bind). With the latter, the user likely thinks >> he mistyped the password and sends it again unencrypted. > The problem with the security directive that the user ran into, however, I > don't see a way to get around. Which is there is no "OR" support. I.e., > you can't say, I want the user to have a TLS of 128 OR SASL SSF of 128. If > you specify both, both are required. You really need to read more carefully. If you only care about the overall SSF, regardless of whether it's from TLS or SASL, then just use the "ssf" factor. -- -- Howard Chu Chief Architect, 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#5195) ssf not available during sasl bind
by quanah＠zimbra.com 29 Oct '07

29 Oct '07

--On Monday, October 29, 2007 5:08 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > Also, repeating an old point, remember that the "security" keyword > produces better error messages ("Confidentiality required") than > "access ... ssf=..." ("Insufficient access" for updates, "Invalid > credentials" for Bind). With the latter, the user likely thinks > he mistyped the password and sends it again unencrypted. The problem with the security directive that the user ran into, however, I don't see a way to get around. Which is there is no "OR" support. I.e., you can't say, I want the user to have a TLS of 128 OR SASL SSF of 128. If you specify both, both are required. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5195) ssf not available during sasl bind
by h.b.furuseth＠usit.uio.no 29 Oct '07

29 Oct '07

quanah(a)zimbra.com writes: > access to userPassword > by anonymous auth sasl_ssf=128 break > by anonymous auth tls=128 > by self read > > (At this point, you've forced any user to be encrypted, No, you've forced users who authenticate against userPassword to be encrypted. Not all SASL methods, nor auth with rootpw. Also, repeating an old point, remember that the "security" keyword produces better error messages ("Confidentiality required") than "access ... ssf=..." ("Insufficient access" for updates, "Invalid credentials" for Bind). With the latter, the user likely thinks he mistyped the password and sends it again unencrypted. Come to think of it, I guess I should insert that in the slapd.access(5) manpage. > so no need to duplicate the requirements on the read access). -- Regards, Hallvard

1 0

Re: (ITS#5206) Admin guide: Berkeley DB version
by ghenry＠suretecsystems.com 29 Oct '07

29 Oct '07

> The admin guide says > "Generally, the most recent release [of Berkeley DB] > (with published patches) is recommended." > in CVS openldap-guide/admin/install.sdf and > <http://www.openldap.org/doc/admin23/install.html>. > > Not true with 4.6, and the advise on -software is still 4.2.52+patches: > http://www.openldap.org/lists/openldap-software/200710/msg00321.html > We have a versions table in the 2.4 guide and a link to it from the install section in the 2.4 version as well (below is not the latest version): http://suretec.org/our_docs/appendix-recommended-versions.html Haven't we already decided that we aren't updating the 2.3 guide? If we are now going to, then I can put in a big DEPRECATED for slurpd and fix above.

1 0

(ITS#5206) Admin guide: Berkeley DB version
by h.b.furuseth＠usit.uio.no 29 Oct '07

29 Oct '07

Full_Name: Hallvard B Furuseth Version: guide HEAD, 23, web OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard The admin guide says "Generally, the most recent release [of Berkeley DB] (with published patches) is recommended." in CVS openldap-guide/admin/install.sdf and <http://www.openldap.org/doc/admin23/install.html>. Not true with 4.6, and the advise on -software is still 4.2.52+patches: http://www.openldap.org/lists/openldap-software/200710/msg00321.html

1 0

Re: (ITS#5205) CVS to RSS Web Enhancement
by h.b.furuseth＠usit.uio.no 29 Oct '07

29 Oct '07

ghenry(a)suretecsystems.com writes: > http://www.mail-archive.com does RSS feeds. www.gname.org too. That one has feeds and archive of -announce, -devel and "general" (-software). http://dir.gmane.org/search.php?match=openldap -- Hallvard

1 0

Re: (ITS#5205) CVS to RSS Web Enhancement
by ghenry＠suretecsystems.com 29 Oct '07

29 Oct '07

Very nice! http://www.mail-archive.com does RSS feeds. It only has: http://www.mail-archive.com/openldap-software@openldap.org/maillist.xml http://www.mail-archive.com/openldap-devel@openldap.org/maillist.xml I've subscribed openldap-commit(a)openldap.org to the service as per: http://www.mail-archive.com/faq.html#newlist Do we want bugs and announce on to? Then we have all our lists via RSS. Gavin.

1 0

Re: (ITS#5205) CVS to RSS Web Enhancement
by ghenry＠OpenLDAP.org 28 Oct '07

28 Oct '07

<quote who="Howard Chu"> > ghenry(a)OpenLDAP.org wrote: >> Hi, >> >> It would be great to have something like: >> >> http://www.google.co.uk/search?q=cvs2rss&ie=utf-8&oe=utf-8&aq=t&rls=org.moz… > > Feel free to subscribe to the openldap-commit mailing list with an email > alias > pointing to whatever RSS generator you wish. OK, thanks. I'll sort something out and reply to this ticket when I do. Do we want a public available url, or just use this for myself? > -- > -- Howard Chu > Chief Architect, 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#5205) CVS to RSS Web Enhancement
by hyc＠symas.com 28 Oct '07

28 Oct '07

ghenry(a)OpenLDAP.org wrote: > Hi, > > It would be great to have something like: > > http://www.google.co.uk/search?q=cvs2rss&ie=utf-8&oe=utf-8&aq=t&rls=org.moz… Feel free to subscribe to the openldap-commit mailing list with an email alias pointing to whatever RSS generator you wish. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5205) CVS to RSS Web Enhancement
by ghenry＠OpenLDAP.org 28 Oct '07

28 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Hi, It would be great to have something like: http://www.google.co.uk/search?q=cvs2rss&ie=utf-8&oe=utf-8&aq=t&rls=org.moz… Gavin.

1 0

Re: (ITS#5204) Openldap and undefined symbols
by hyc＠symas.com 27 Oct '07

27 Oct '07

galtgendo(a)o2.pl wrote: > Full_Name: Rafał Mużyło > Version: 2.3.38 > OS: Linux > URL: > Submission from: (NULL) (89.228.37.72) > > > A few months ago I came across a problem that I reported to Gentoo Bugzilla, > however that bug (http://bugs.gentoo.org/show_bug.cgi?id=189817) was closed as > invalid. I don't think that it was, at least not 100%. You got the correct answer in comment #2 on that bug. There is no bug in OpenLDAP here. This ITS will be closed. I note that libldap_r was primarily written for use by slapd and slurpd, and nothing else. The only publically documented LDAP API only uses libldap. If you have any software linking against libldap_r, and it's not working, then you should go file a bug with whatever other software is involved. -- -- Howard Chu Chief Architect, 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#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 27 Oct '07

27 Oct '07

On Fri, 2007-10-26 at 19:59 -0700, Quanah Gibson-Mount wrote: > > ldapsearch -ZZ -U "openldap" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" > > "(uid=it)" ldap_sasl_interactive_bind_s: Confidentiality required (13) > > additional info: SASL confidentiality required > > > > Is that a bug? > > > I suggest reading the part on sasl-secprops in the slapd.conf (5) man page. > It notes that the default is to setting is to block anonymous and plain > SASL binds. I suspect you are right in that is the cause of the problem because a -Y DIGEST-MD5 fixes it. But, as I said, it worked before the security option was added. It worked because DIGEST-MD5 was the default. So why isn't it the default now? Now that you have pointed it out, I guess that the addition of the 'security' option prevented SASL from searching dn="" for the types of authentications supported. > access to userPassword > by users read sasl_ssf=128 break > by users read tls=128 > > I think might do it. You would think that would do it - certainly I did. But you would be wrong. Currently it doesn't, and that is what this ITS is about. The patch I supplied with the initial bug report changes things so it does work.

1 0

Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com 27 Oct '07

27 Oct '07

--On Saturday, October 27, 2007 3:00 AM +0000 quanah(a)zimbra.com wrote: > access to userPassword > by users read sasl_ssf=128 break > by users read tls=128 Replace users by self, sorry. Obviously you don't want any user to read it. ;) Although hm, anonymous need access at least for auth, so: access to userPassword by anonymous auth by self read sasl_ssf=128 break by self read tls=128 Note that in the anonymous access case, the user password is never transmitted from the server end, in any case. You could do a similar requirement as above, something like: access to userPassword by anonymous auth sasl_ssf=128 break by anonymous auth tls=128 by self read (At this point, you've forced any user to be encrypted, so no need to duplicate the requirements on the read access). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5195) ssf not available during sasl bind
by quanah＠zimbra.com 27 Oct '07

27 Oct '07

--On Friday, October 26, 2007 9:47 AM +0000 russell-openldap(a)stuart.id.au wrote: > I have now tried: > > security tls=128 sasl=128 > > It didn't work. All the commands below work without > the 'security' option. This says: Require a TLS section of 128 bit security AND SASL security of 128. > ldapsearch -x -ZZ -D "uid=openldap,dc=auth,dc=lubemobile,dc=com,dc=au" > -w "$(ssu cat /etc/libnss-ldap.secret)" -b > "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)" ldap_bind: You aren't using SASL here. So of course it fails. > Which, when I think about it may be reasonable. I am > apparently saying I require a sasl ssf of 128, and > obviously I don't have that. This was a surprise > though: Right. > ldapsearch -ZZ -U "openldap" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" > "(uid=it)" ldap_sasl_interactive_bind_s: Confidentiality required (13) > additional info: SASL confidentiality required > > Is that a bug? I suggest reading the part on sasl-secprops in the slapd.conf (5) man page. It notes that the default is to setting is to block anonymous and plain SASL binds. > Anyway, bugs aside, assuming I now have some idea how it > works its useless for my application. I want to insist > that userPassword to be encrypted when sent and received, > be that via CRAM-MD5 or friends or by using TLS, but clear > text is fine for the rest of the information in the ldap > database, and in fact anonymous connections unencrypted > connections are the rule for VPN access. The 'security' > option applies to all connections. access to userPassword by users read sasl_ssf=128 break by users read tls=128 I think might do it. > Anyway, to state the problem as clearly as I can, I can't > see how to do the following combination of things: > > . Allow anonymous access over unencrypted connections > for the bulk of the database. Above acl followed by access to * by * read (or however else limited). > . Allow simple binds, but they must be over encrypted > connections to protect userPassword. See above ACL. > . Allow sasl binds over unencrypted connections, but > the must not use clear text. Read the sasl-secprops setting. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5204) Openldap and undefined symbols
by galtgendo＠o2.pl 27 Oct '07

27 Oct '07

Full_Name: Rafał Mużyło Version: 2.3.38 OS: Linux URL: Submission from: (NULL) (89.228.37.72) A few months ago I came across a problem that I reported to Gentoo Bugzilla, however that bug (http://bugs.gentoo.org/show_bug.cgi?id=189817) was closed as invalid. I don't think that it was, at least not 100%. I'm not really an openldap user, I simply have it installed as a dependency and probably I'm not using it at all. This is simply something that I noticed while I was building wine. During configure, openldap was not detected, although it was installed. I filed it as --as-needed issue, now, however, I no longer think it the case. As the bug mentions, libldap_r.so had undefined symbols from pthread, so standard configure lib check was failing. I thought that it was an as-needed issue, but now I'm not so sure. You have a closed Build/2209 bug (about an unrelated issue). From the first reply I quote: "It ought to be linked with any libraries it depends on and pull them in implicitly.". Shouldn't it be the same for libldap_r.so - meaning shouldn't it be linked with pthread ? After some checking I found that libslapi.so and most of /usr/lib/openldap have undefined symbols, too, but as far as I understand libslapi is internal use only and it's a design issue cause many symbols that libslapi uses are defined later in slapd (yes, I read that Windows note in servers/slapd/Makefile.in).

1 0

Re: (ITS#5203) [LDAP: error code 32 - No Such Object];
by quanah＠zimbra.com 26 Oct '07

26 Oct '07

--On Friday, October 26, 2007 10:53 AM +0000 hiremath47(a)gmail.com wrote: > Full_Name: Siddeshawr > Version: Version 2.8 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.92.60.81) The ITS system is for bug reports, not usage questions. Please use openldap-software(a)openldap.org for questions you have about using OpenLDAP. I will also note that "2.8" is not a valid OpenLDAP release. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5203) [LDAP: error code 32 - No Such Object];
by hiremath47＠gmail.com 26 Oct '07

26 Oct '07

Full_Name: Siddeshawr Version: Version 2.8 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.92.60.81) Hi, If I try to add the following entry into the LDAP 'uid=seal_koa/denage(a)denimvage.com' javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3013) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2934) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2740) at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:998) at com.sun.jndi.toolkit.ctx.ComponentContext.c_resolveIntermediate_nns(ComponentContext.java:152) at com.sun.jndi.toolkit.ctx.AtomicContext.c_resolveIntermediate_nns(AtomicContext.java:342) at com.sun.jndi.toolkit.ctx.ComponentContext.p_resolveIntermediate(ComponentContext.java:381) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(ComponentDirContext.java:311) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:248) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:236) at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:176) Please suggest on the same. Regards, Siddeshwar

1 0

Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 26 Oct '07

26 Oct '07

I have now tried: security tls=128 sasl=128 It didn't work. All the commands below work without the 'security' option. ldapsearch -x -ZZ -D "uid=openldap,dc=auth,dc=lubemobile,dc=com,dc=au" -w "$(ssu cat /etc/libnss-ldap.secret)" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)" ldap_bind: Confidentiality required (13) additional info: SASL confidentiality required Which, when I think about it may be reasonable. I am apparently saying I require a sasl ssf of 128, and obviously I don't have that. This was a surprise though: ldapsearch -ZZ -U "openldap" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)" ldap_sasl_interactive_bind_s: Confidentiality required (13) additional info: SASL confidentiality required Is that a bug? Anyway, bugs aside, assuming I now have some idea how it works its useless for my application. I want to insist that userPassword to be encrypted when sent and received, be that via CRAM-MD5 or friends or by using TLS, but clear text is fine for the rest of the information in the ldap database, and in fact anonymous connections unencrypted connections are the rule for VPN access. The 'security' option applies to all connections. Anyway, to state the problem as clearly as I can, I can't see how to do the following combination of things: . Allow anonymous access over unencrypted connections for the bulk of the database. . Allow simple binds, but they must be over encrypted connections to protect userPassword. . Allow sasl binds over unencrypted connections, but the must not use clear text. . Not particularly relevant to me, but it would be nice to allow sasl binds using clear text if they are over an encrypted connection. The patch does this of course, but if there is some other way then the patch is irrelevant, except perhaps from a usability point of view.

1 0

Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 26 Oct '07

26 Oct '07

On Thu, 2007-10-25 at 16:33 -0700, Howard Chu wrote: > There are no shortcuts when it comes to security. If you don't take the time > to understand it you'll get it wrong, period. That's true of all systems, no > matter how simple or complex - if you don't take the time to understand the > system's security requirements, you will screw up. As in your example above, > which should use "auth" access, not "read" access. I am not sure I agree, but to borrow your words a discussion about short cuts to security seems irrelevant to this ITS, as is whether I made a typo in my example. The rather long winded rant is relevant in one minor way (sorry about the length). In your original counter example, you said correctly "slap_auxprop_lookup" is doing an internal search and thus doesn't expose the password. The fact that I would have to know that in order to realise that "acl ... by tls_ssf=" doesn't do what I want is what I was railing against. It is purely a technical detail. When plain text is used, the password is sent over the connection. The fact happens not to be the copy in the slapd database (and thus as you say the copy in the database is infinitely secure) is irrelevant to me, the user. You said that if "you don't take the time to understand [the] security [model], you will get it wrong, period". Well there is room for movement at both ends. You can insist the user spends a long time understanding slapd's security model, or you can make the model easier to understand. I think the patch does the latter. If you think I am wrong, ie it makes slapd configuration harder to understand, then by all means reject it.

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 26 Oct '07

26 Oct '07

russell-openldap(a)stuart.id.au wrote: > On Thu, 2007-10-25 at 05:18 -0700, Howard Chu wrote: >> Using ACLs to enforce this requirement is the wrong approach though. You >> should just use the "security" directive instead. With your approach you're >> missing the fact that SASL may not have sent any password at all to slapd >> (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a >> constraint that makes no sense. > > So you are saying: > > security sasl=128 simple_bind=128 > > would achieve that? I guess it would. > > However, with the patch applied this would have the same > effect, with the addition that if some other authorisation > mechanism were introduced (eg pam), it would fail unless > it was encrypted or I explicitly allowed it. > > acl <password-stuff> > by tls_ssf=128 ... read > by sasl_ssf=128 ... read > by * none > > This may look icky to you, but to someone who is just > trying to deploy slapd it means there is one less > slapd.conf option I have to get my head around. There are no shortcuts when it comes to security. If you don't take the time to understand it you'll get it wrong, period. That's true of all systems, no matter how simple or complex - if you don't take the time to understand the system's security requirements, you will screw up. As in your example above, which should use "auth" access, not "read" access. > <rant> > > Perhaps ease of configuration doesn't seem so important. > But I was at a talk given by Andrew Tridgell about why > he wrote tdb instead of using just using openldap. > Answer: because it took him 3 days to get slapd > configured and working. 3 days is an impressively > short time going on my experiences with it. He actually > said it wasn't because slapd had bugs, or slapd was too > slow, or slapd didn't have a feature. It was just > because in the final analysis, he could not see the > typical samba user being able to make the thing work. He should have come and talked to us. (In fact, since then, he has. We've shown how easily a canned Samba config can be setup, and we'll be collaborating closely on schema issues and other things down the road.) > When something is hard to configure typically the doco > is blamed. But that is often wrong and is wrong in the > case of openldap. The blame lies with the design of > the system. The programmers fail to see the > configuration of the system as another interface. They > will put hours of work into designing an API, and > devote 100's of lines of code to making sure that API > is easy to use, that it hides the complexities of its > implementation. Yet they ignore configuration, which > in effect another API - it is the interface between > the users and the program. You presume a lot here. Configuration in OpenLDAP 2.3 and 2.4 is a lot more rational than it ever was in prior releases, and that's because it has been the focus of considerable attention. The fact that your old methods still work, allowing you to limp along without reading about all the new methods, is a testament to the care that was taken in building the configuration enhancements. > If it had of been an API presented to other > programmers, I bet the original designer who of thought > "how can I hide all this behind a simple, clean, easy > to understand interface". But he didn't, and so now > openldap deservedly has the reputation as one of the > harder pieces of open source software to get up and > going. As a consequence it is deployed a lot less > than it should be. Nonsense. The primary reason OpenLDAP has a bad reputation in some circles is because distros like RedHat continued to bundle obsolete versions years after they had been dropped by the Project, and so a vast number of users were never exposed to the myriad improvements made over time. Regardless, OpenLDAP usage is still growing, and it looks like the growth will continue to accelerate. None of this discussion is relevant to this ITS. -- -- Howard Chu Chief Architect, 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#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 26 Oct '07

26 Oct '07

On Thu, 2007-10-25 at 05:18 -0700, Howard Chu wrote: > Using ACLs to enforce this requirement is the wrong approach though. You > should just use the "security" directive instead. With your approach you're > missing the fact that SASL may not have sent any password at all to slapd > (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a > constraint that makes no sense. So you are saying: security sasl=128 simple_bind=128 would achieve that? I guess it would. However, with the patch applied this would have the same effect, with the addition that if some other authorisation mechanism were introduced (eg pam), it would fail unless it was encrypted or I explicitly allowed it. acl <password-stuff> by tls_ssf=128 ... read by sasl_ssf=128 ... read by * none This may look icky to you, but to someone who is just trying to deploy slapd it means there is one less slapd.conf option I have to get my head around. <rant> Perhaps ease of configuration doesn't seem so important. But I was at a talk given by Andrew Tridgell about why he wrote tdb instead of using just using openldap. Answer: because it took him 3 days to get slapd configured and working. 3 days is an impressively short time going on my experiences with it. He actually said it wasn't because slapd had bugs, or slapd was too slow, or slapd didn't have a feature. It was just because in the final analysis, he could not see the typical samba user being able to make the thing work. When something is hard to configure typically the doco is blamed. But that is often wrong and is wrong in the case of openldap. The blame lies with the design of the system. The programmers fail to see the configuration of the system as another interface. They will put hours of work into designing an API, and devote 100's of lines of code to making sure that API is easy to use, that it hides the complexities of its implementation. Yet they ignore configuration, which in effect another API - it is the interface between the users and the program. Like most projects openldap uses many libraries to do its thing. But makes no attempt to hide that from the user. In order to configure openldap you have to understand ldap, sasl, tls, berkley db, but whats worse you have to understand how they interact with each other within openldap. For example, ssf is a sasl concept. simple_bind is an ldap concept. But the "security" option has "simple_bind=<ssf_factor>", so suddenly you have to know both, even if you have no intention of using one of them. Ick, ick, ick. If it had of been an API presented to other programmers, I bet the original designer who of thought "how can I hide all this behind a simple, clean, easy to understand interface". But he didn't, and so now openldap deservedly has the reputation as one of the harder pieces of open source software to get up and going. As a consequence it is deployed a lot less than it should be. </rant>

1 0

Re: (ITS#5202) ldapsearch -E pr segfault
by kurt＠OpenLDAP.org 26 Oct '07

26 Oct '07

On Oct 25, 2007, at 9:35 PM, hyc(a)symas.com wrote: > That doesn't make any sense, the fix for ITS#5100 is not in 2.3.38. After double checking, this issue is the result of a local source merge issue. I withdraw this ITS. -- Kurt

1 0

Re: (ITS#5202) ldapsearch -E pr segfault
by hyc＠symas.com 25 Oct '07

25 Oct '07

ando(a)sys-net.it wrote: > kurt(a)OpenLDAP.org wrote: >> Full_Name: Kurt Zeilenga >> Version: 2.3.38 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.141.229.206) >> >> >> Here's a stack trace; the command was: >> % ldapsearch -x -E pr=2/noprompt -b "o=test2,o=test" -s one "cn=*" cn >> . >> . >> (gdb) where >> #0 0x005303d4 in _int_free () from /lib/tls/libc.so.6 >> #1 0x0053172b in free () from /lib/tls/libc.so.6 >> #2 0x004201e3 in ber_memfree_x (p=0x805405d, ctx=0x0) at memory.c:149 >> #3 0x001d85e8 in ldap_control_free (c=0xbfe3ecd0) at controls.c:260 >> #4 0x001d8669 in ldap_controls_free (controls=0x9c801c8) at controls.c:285 >> #5 0x0804f703 in tool_server_controls (ld=0x9c76550, extra_c=0xbfe3ece0, >> count=-1) at common.c:1250 >> #6 0x0804b910 in main (argc=14, argv=0xbfe40e44) at ldapsearch.c:794 >> >> It's done the bind ok by this stage but never gets as far as sending the search >> request. > > I think this could be a consequence of fixing ITS#5100: probably, > ldapsearch's call of ldap_control_free() was incorrectly relying on its > broken behavior. That doesn't make any sense, the fix for ITS#5100 is not in 2.3.38. -- -- Howard Chu Chief Architect, 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#5202) ldapsearch -E pr segfault
by ando＠sys-net.it 25 Oct '07

25 Oct '07

kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: 2.3.38 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.141.229.206) > > > Here's a stack trace; the command was: > % ldapsearch -x -E pr=2/noprompt -b "o=test2,o=test" -s one "cn=*" cn > . > . > (gdb) where > #0 0x005303d4 in _int_free () from /lib/tls/libc.so.6 > #1 0x0053172b in free () from /lib/tls/libc.so.6 > #2 0x004201e3 in ber_memfree_x (p=0x805405d, ctx=0x0) at memory.c:149 > #3 0x001d85e8 in ldap_control_free (c=0xbfe3ecd0) at controls.c:260 > #4 0x001d8669 in ldap_controls_free (controls=0x9c801c8) at controls.c:285 > #5 0x0804f703 in tool_server_controls (ld=0x9c76550, extra_c=0xbfe3ece0, > count=-1) at common.c:1250 > #6 0x0804b910 in main (argc=14, argv=0xbfe40e44) at ldapsearch.c:794 > > It's done the bind ok by this stage but never gets as far as sending the search > request. I think this could be a consequence of fixing ITS#5100: probably, ldapsearch's call of ldap_control_free() was incorrectly relying on its broken behavior. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5202) ldapsearch -E pr segfault
by quanah＠zimbra.com 25 Oct '07

25 Oct '07

--On Thursday, October 25, 2007 5:11 PM +0000 kurt(a)OpenLDAP.org wrote: > Full_Name: Kurt Zeilenga > Version: 2.3.38 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.141.229.206) Brandon Hume also sees this behavior: /opt/csw/bin/ldapsearch -x -b dc=bofh,dc=ca -h localhost -E pr=2 '(objectclass=*)' dn # search result search: 2 result: 0 Success control: 1.2.840.113556.1.4.319 false MAkCAQAEBAIAAAA= control: 1.2.840.113556.1.4.319 false MAkCAQAEBP////8= Press [size] Enter for the next {2|size} entries. Where obviously that second value is bogus. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5202) ldapsearch -E pr segfault
by kurt＠OpenLDAP.org 25 Oct '07

25 Oct '07

Full_Name: Kurt Zeilenga Version: 2.3.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.141.229.206) Here's a stack trace; the command was: % ldapsearch -x -E pr=2/noprompt -b "o=test2,o=test" -s one "cn=*" cn . . (gdb) where #0 0x005303d4 in _int_free () from /lib/tls/libc.so.6 #1 0x0053172b in free () from /lib/tls/libc.so.6 #2 0x004201e3 in ber_memfree_x (p=0x805405d, ctx=0x0) at memory.c:149 #3 0x001d85e8 in ldap_control_free (c=0xbfe3ecd0) at controls.c:260 #4 0x001d8669 in ldap_controls_free (controls=0x9c801c8) at controls.c:285 #5 0x0804f703 in tool_server_controls (ld=0x9c76550, extra_c=0xbfe3ece0, count=-1) at common.c:1250 #6 0x0804b910 in main (argc=14, argv=0xbfe40e44) at ldapsearch.c:794 It's done the bind ok by this stage but never gets as far as sending the search request.

1 0

Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com 25 Oct '07

25 Oct '07

russell-openldap(a)stuart.id.au wrote: > In one sense you are correct: the userPassword read > by slap_auxprop_lookup will never be revealed. And > so yes, the ssf for the results of that search would > be infinity. > > But what I want to check is the weakest link in the > chain. I can't imagine any instance when that isn't > what you would want to check, so that is what the > ssf should reflect. By definition, the > slap_auxprop_lookup can never be the weakest link. > The weakest link in this case when sasl sent the > password to slapd. Really, what I want to say is if > the password was sent in the clear, whether it be by > sasl or simple auth, then the link must be encrypted. > > The patch makes the information required to do that > test available. Using ACLs to enforce this requirement is the wrong approach though. You should just use the "security" directive instead. With your approach you're missing the fact that SASL may not have sent any password at all to slapd (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a constraint that makes no sense. -- -- Howard Chu Chief Architect, 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#5199
by david＠schmitt.edv-bus.at 25 Oct '07

25 Oct '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 24 October 2007, you wrote: > The stack backtrace you provide is useless, as it refers to the main > thread. Please run "thread apply all bt full". Hmpf. Thanks for your answer, I will try to get a better trace upon the next hang. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHIEgZ/Pp1N6Uzh0URAjTPAJ4oiB8IlYjeDKxIGDKHDFCtQEKr2QCgnECE x5GwRPbtZ4Cl5bMy0NlOsTc= =nnG/ -----END PGP SIGNATURE-----

1 0

Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au 25 Oct '07

25 Oct '07

In one sense you are correct: the userPassword read by slap_auxprop_lookup will never be revealed. And so yes, the ssf for the results of that search would be infinity. But what I want to check is the weakest link in the chain. I can't imagine any instance when that isn't what you would want to check, so that is what the ssf should reflect. By definition, the slap_auxprop_lookup can never be the weakest link. The weakest link in this case when sasl sent the password to slapd. Really, what I want to say is if the password was sent in the clear, whether it be by sasl or simple auth, then the link must be encrypted. The patch makes the information required to do that test available.

1 0

RE: (ITS#5201) pcache has an incorrect LDAP_DEBUG _NONE debug statement
by mhardin＠symas.com 24 Oct '07

24 Oct '07

> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Wednesday, October 24, 2007 11:43 AM [...] > > > > On line 1267 of servers/slapd/overlays/pcache.c there is a debug > > statement, "Entering QC, querystr = %s\n", which is clearly a routine > > debug statement specific to pcache. The channel used is LDAP_DEBUG_NONE, > > and this makes for very chatty output when a loglevel of 'none' is > > specified in slapd.conf and the pcache overlay is in use. The log > channel > > should be changed to 'pcache_debug' instead. > > This is already fixed in REL_ENG_2_3, REL_ENG_2_4, and HEAD. I just saw that- reject if you care to. > --Quanah -Matt Matthew Hardin Symas Corporation- The LDAP Guys http://www.symas.com

1 0

Re: (ITS#5201) pcache has an incorrect LDAP_DEBUG _NONE debug statement
by quanah＠zimbra.com 24 Oct '07

24 Oct '07

--On Wednesday, October 24, 2007 5:27 PM +0000 mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.3.38 > OS: All > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.114.43) > > > On line 1267 of servers/slapd/overlays/pcache.c there is a debug > statement, "Entering QC, querystr = %s\n", which is clearly a routine > debug statement specific to pcache. The channel used is LDAP_DEBUG_NONE, > and this makes for very chatty output when a loglevel of 'none' is > specified in slapd.conf and the pcache overlay is in use. The log channel > should be changed to 'pcache' instead. This is already fixed in REL_ENG_2_3, REL_ENG_2_4, and HEAD. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5201) pcache has an incorrect LDAP_DEBUG _NONE debug statement
by mhardin＠symas.com 24 Oct '07

24 Oct '07

Full_Name: Matthew Hardin Version: 2.3.38 OS: All URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.43) On line 1267 of servers/slapd/overlays/pcache.c there is a debug statement, "Entering QC, querystr = %s\n", which is clearly a routine debug statement specific to pcache. The channel used is LDAP_DEBUG_NONE, and this makes for very chatty output when a loglevel of 'none' is specified in slapd.conf and the pcache overlay is in use. The log channel should be changed to 'pcache' instead.

1 0

ITS#5199
by ando＠sys-net.it 24 Oct '07

24 Oct '07

The stack backtrace you provide is useless, as it refers to the main thread. Please run "thread apply all bt full". p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5200) Wrong maxderefdepth doc or default
by h.b.furuseth＠usit.uio.no 24 Oct '07

24 Oct '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd.conf(5) and slapd-config(5) say MaxDerefDepth defaults to 1, but include/ldap_defaults.h says #define SLAPD_DEFAULT_MAXDEREFDEPTH 15.

1 0

(ITS#5199) slapd sometimes hangs with back-sql
by david＠schmitt.edv-bus.at 24 Oct '07

24 Oct '07

Full_Name: David Schmitt Version: 2.3.38 OS: Debian etch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.170.138.34) Hi! I have OSX clients authenticating via slapd against my postgres database. Once every fortnight slapd stops responding to requests. I got this backtrace out of it: 0x00002b28372e20f5 in pthread_join () from /lib/libpthread.so.0 (gdb) bt full #0 0x00002b28372e20f5 in pthread_join () from /lib/libpthread.so.0 No symbol table info available. #1 0x00000000004230d2 in slapd_daemon () at /root/tmp/openldap2.3-2.3.38/servers/slapd/daemon.c:2579 listener_tid = 1082132832 rc = 0 #2 0x000000000041665f in main (argc=5, argv=0x7fff748e4288) at /root/tmp/openldap2.3-2.3.38/servers/slapd/main.c:859 save_errno = <value optimized out> fp = (FILE *) 0x6a4f70 i = <value optimized out> no_detach = 0 rc = 1 urls = <value optimized out> username = 0x605030 "gidNumber" groupname = 0x605010 "\226{P7(+" sandbox = 0x0 syslogUser = 160 configfile = <value optimized out> configdir = <value optimized out> serverName = <value optimized out> scp = <value optimized out> scp_entry = <value optimized out> debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 l = <value optimized out> slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 __PRETTY_FUNCTION__ = "main" (gdb) When testing with ldapsearch, the client connects, but doesn't receive any data. This is running on a 2.6.21-2-vserver-amd64 kernel, within a vserver container.

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 24 Oct '07

24 Oct '07

jclarke(a)linagora.com wrote: > Got this one: it was a double-free in sets.c occuring after a > slap_set_join() with lset or rset empty - the non empty set was > returned, and then freed, causing a double-free error or segfault. > > The patch attached corrects this problem on RE23 and HEAD for me and > doesn't have any side effects on our test set. However, it may not be > the "right" way - please correct if necessary! It seems to work correctly, but there seems to be an easier fix: just NULL out the pointer to lset/rset, respectively. I'm patching the code this way, please test if you get a chance. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5198) wrong SQL-Statements in Back-SQL
by ando＠sys-net.it 24 Oct '07

24 Oct '07

peter.gietz(a)daasi.de wrote: > This bug report was given to me at the OpenLDAP booth on the Systems in Munich. > > SQL search-statements are wrong because of a strange OR condition: > "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entry_objclasses.oc_name='" > > So instead of a subset, all data are included in the response. It is not a bug, but rather an easy means to indicate that the whole data should be returned to the frontend in order to filter it the LDAP way, since sub-classing might be involved. If that user doesn't want searches for (objectClass=person) to return objects with objectClass=inetOrgPerson, then he shouldn't be using LDAP. > Thats what the > guy, who was too lazy to make the bug report himself told me. He also told me > that he patched his code (by deleting the condition (2=2) and is happy for > now. Well, you see: open source software makes people happy. As a side note, usually, well-designed RDBMSes understand that 2=2 is always true and do not proceed any further in evaluating other clauses in the OR. For those RDBMSes this causes a performance degradation (and, I insist, it would be the RDBMS' fault) the only **improvement** to OpenLDAP's back-sql (no bug) could consist in detecting that condition ourselves and omit that part of the WHERE clause entirely. But this would probably require to rewrite the filter translation layer, and it's not something I plan to do any soon (unless rewarded enough to distract me from other issues, I mean). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5197) result.c uses ldap_pvt_thread_pool_query indiscriminately
by hyc＠symas.com 23 Oct '07

23 Oct '07

richton(a)nbcs.rutgers.edu wrote: > Full_Name: Aaron Richton > Version: RE24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.6.31.135) > > > ldap_pvt_thread_pool_query is referenced even if --without-threads. I believe > this is as simple as... Thanks for the report. > > --- result.c~ 2007-10-23 09:53:36.646614000 -0400 > +++ result.c 2007-10-23 09:53:23.640874000 -0400 > @@ -743,12 +743,14 @@ > return LDAP_SIZELIMIT_EXCEEDED; > } > > +#ifndef NO_THREADS > /* Every 64 entries, check for thread pool pause */ > if (( rs->sr_nentries & 0x3f == 0x3f ) && > ldap_pvt_thread_pool_query( &connection_pool, > LDAP_PVT_THREAD_POOL_PARAM_PAUSING, &i ) == 0 && i ) { > return LDAP_BUSY; > } > +#endif > > rs->sr_type = REP_SEARCH; > > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5198) wrong SQL-Statements in Back-SQL
by peter.gietz＠daasi.de 23 Oct '07

23 Oct '07

Full_Name: Peter Gietz Version: 2.3.38 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.154.95.209) This bug report was given to me at the OpenLDAP booth on the Systems in Munich. SQL search-statements are wrong because of a strange OR condition: "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='" So instead of a subset, all data are included in the response. Thats what the guy, who was too lazy to make the bug report himself told me. He also told me that he patched his code (by deleting the condition (2=2) and is happy for now. If you think this is a bug, please repair. I found this in the source code (.../slapd/back-sql/search.c (lines 780-805): (not sure if this is the only occurance) /* * "structural" objectClass inheritance: * - a search for "person" will also return * "inetOrgPerson" * - a search for "top" will return everything */ if ( is_object_subclass( oc, bsi->bsi_oc->bom_oc ) ) { static struct berval ldap_entry_objclasses = BER_BVC( "ldap_entry_objclasses" ); backsql_merge_from_tbls( bsi, &ldap_entry_objclasses ); backsql_strfcat_x( &bsi->bsi_flt_where, bsi->bsi_op->o_tmpmemctx, "lbl", (ber_len_t)STRLENOF( "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='" /* ')) */ ), "(2=2 OR (ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_name='" /* ')) */, &bsi->bsi_oc->bom_oc->soc_cname, (ber_len_t)STRLENOF( /* ((' */ "'))" ), /* ((' */ "'))" ); bsi->bsi_status = LDAP_SUCCESS; rc = 1; goto done; } break; }

1 0

(ITS#5197) result.c uses ldap_pvt_thread_pool_query indiscriminately
by richton＠nbcs.rutgers.edu 23 Oct '07

23 Oct '07

Full_Name: Aaron Richton Version: RE24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.135) ldap_pvt_thread_pool_query is referenced even if --without-threads. I believe this is as simple as... --- result.c~ 2007-10-23 09:53:36.646614000 -0400 +++ result.c 2007-10-23 09:53:23.640874000 -0400 @@ -743,12 +743,14 @@ return LDAP_SIZELIMIT_EXCEEDED; } +#ifndef NO_THREADS /* Every 64 entries, check for thread pool pause */ if (( rs->sr_nentries & 0x3f == 0x3f ) && ldap_pvt_thread_pool_query( &connection_pool, LDAP_PVT_THREAD_POOL_PARAM_PAUSING, &i ) == 0 && i ) { return LDAP_BUSY; } +#endif rs->sr_type = REP_SEARCH;

1 0

Re: (ITS#5163) slapd segfaults when running as proxy-caching server
by toby＠inf.ed.ac.uk 23 Oct '07

23 Oct '07

I said: > I'll patch and report back. Apologies for the delaying in confirming... Yep, this fixed the problem I was seeing. Many thanks Toby

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 23 Oct '07

23 Oct '07

On Dienstag, 23. Oktober 2007, Howard Chu wrote: > rhafer(a)suse.de wrote: > > On Dienstag, 23. Oktober 2007, ando(a)sys-net.it wrote: > >> For the records: I seem to be ble to consistently reproduce the issue > >> when running slapd under valgrind; > > > > Thanks, that seems to do the trick for me as well. > > Funny, even running either slapd.1 or slapd.2 under valgrind, it still > succeeds for me. > > >> I haven't seen it yet when running the test > >> regularly (single CPU i386, recently). > > Looking at Gavin's testrun files, diffing slapd.2.log against a successful > run, the main difference I see is that on the failed run some queries get > added into the cache later than in the successful run. As such, the > difference comes down to whether the pcache thread gets to run before the > next query arrives or not. So, still non-deterministic and not really a big > deal. Ok, so it's most probably really the same issue as in ITS#5114 Followup 20. The non-deterministic behaviour got introduced by moving the actual caching of the entries to the cleanup handler. As a result of this, the ldapsearch commands in the test suite finishes (and the next operations start) before the data has been completely cached. Which I think is not a bug. Any ideas how we could fix the test without introducing any sleep calls to it? -- Ralf

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by hyc＠symas.com 23 Oct '07

23 Oct '07

rhafer(a)suse.de wrote: > On Dienstag, 23. Oktober 2007, ando(a)sys-net.it wrote: >> For the records: I seem to be ble to consistently reproduce the issue when >> running slapd under valgrind; > Thanks, that seems to do the trick for me as well. Funny, even running either slapd.1 or slapd.2 under valgrind, it still succeeds for me. >> I haven't seen it yet when running the test >> regularly (single CPU i386, recently). Looking at Gavin's testrun files, diffing slapd.2.log against a successful run, the main difference I see is that on the failed run some queries get added into the cache later than in the successful run. As such, the difference comes down to whether the pcache thread gets to run before the next query arrives or not. So, still non-deterministic and not really a big deal. -- -- Howard Chu Chief Architect, 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