openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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: > 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 25 Oct '07

25 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 25 Oct '07

25 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs