- openldap-bugs - openldap.org

(ITS#6814) back-ldap does not handle undefined objectClass values in search filters
by masarati＠aero.polimi.it 29 Jan '11

29 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.14.92) Submitted by: ando A fix is coming. p.

1 0

(ITS#6813) Error in ldap_int_connect_cbs call from ldap_connect_to_host
by ipuleston＠sonicwall.com 28 Jan '11

28 Jan '11

Full_Name: Ian Puleston Version: 2.4.23 OS: VxWorks URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (67.115.118.5) In function ldap_connect_to_host are two calls to ldap_int_connect_cbs. The first for "#if defined( HAVE_GETADDRINFO ) && defined( HAVE_INET_NTOP )" looks OK, but the 2nd for the #else case of that is this: i = ldap_int_connect_cbs( ld, sb, &s, srv, (struct sockaddr *)&sin ); if ( i ) rc = i; else break; But this is inside a for loop that uses i as a counter for the loop control. ldap_int_connect_cbs returns an error code so, unless I'm missing something, setting i to that will break the loop control.

1 0

Re: (ITS#6812) Confused syncprov return codes
by hyc＠symas.com 28 Jan '11

28 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > syncprov_state_ctrl(), syncprov_done_ctrl(), syncprov_sendinfo() and > thus findpres_cb() can return either an LDAP result code, or a negative > number on BER error. I see no code which expects both classes of error > codes. The first functions's callers set rs->sr_err = return value. > At best I guess it'll be ignored or interpreted as LDAP_SERVER_DOWN. I've fixed the return codes. They still get ignored in a few places. -- -- 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#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by hyc＠symas.com 28 Jan '11

28 Jan '11

subbarao(a)computer.org wrote: > Full_Name: Kartik Subbarao > Version: 2.4.23 > OS: Debian Linux 5.0.5 > URL: ftp://ftp.openldap.org/incoming/kartik_subbarao.101116.tgz > Submission from: (NULL) (76.99.175.5) > > > I'm trying to get a consumer server to forward ppolicy-related updates to its > provider server, and to use certificate-based authentication (SASL EXTERNAL) > over STARTTLS when authenticating to the provider. > > I'm running into multiple problems here. The core problem seems to be that > enabling ppolicy_forward_updates breaks the chaining overlay such that it binds > anonymously instead of with SASL EXTERNAL. That's because your authz-regexp is wrong. You mapped "cn=localhost" but when using SASL EXTERNAL, the user's DN is the complete certificate DN. In your case, "cn=localhost,o=OpenLDAP,st=Some-State,c=US" The reason this didn't break replication is because in this test, everything has anonymous read access so the consumer was able to pull what it needed. > Another problem is that bind > operations to the consumer server start to return two result messages -- one > with the error code of the chained operation, and one with the error code of the > bind operation. I didn't get this far because your test certificate is now expired. I guess I can substitute some other certs and look at it again, but I think the core issue is your misconfigured authz-regexp. > To simplify reproducing the problem, I've worked with test022-ppolicy in the > openldap test framework. Here, I ran into another issue. I can't seem to be able > to configure sasl external/starttls chaining properly with the cn=config style > configuration that test022-ppolicy applies. The self-signed cert that I'm using > works fine with replication, but it doesn't seem to work with chaining. This may > or may not be another issue that needs to be resolved. > > In any case, with the attached files in the ITS, I hope that what I'm trying to > do and the results that I'm getting should be as clear as possible. Better to rename your scripts when you modify one of our existing ones. E.g. test999-xxxxxx and just create new data files instead of modifying ours. -- -- 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#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com 28 Jan '11

28 Jan '11

The same behavior happens with 2.4.23, I initially noticed the problem with 2.4.23, built from source on ubuntu server, and then tried with the rebuilt 2.4.19 rpm on rhel. both die with a bus error message when ldapadd is run on the invalid ldif. Nathanael On Fri, 2011-01-28 at 10:55 -0800, Quanah Gibson-Mount wrote: > --On Thursday, January 27, 2011 3:28 PM +0000 anderson(a)vailsys.com wrote: > > > Full_Name: Nathanael Anderson > > Version: 2.4.19 > > OS: RHEL 6 (Linux) > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (74.63.156.11) > > > Please use a current version of OpenLDAP 2.4 prior to filing a bug report > to ensure the issue has not been fixed in a subsequent release. The > current release is 2.4.23. > > --Quanah > > -- > > Quanah Gibson-Mount > Sr. Member of Technical Staff > Zimbra, Inc > A Division of VMware, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by quanah＠zimbra.com 28 Jan '11

28 Jan '11

--On Thursday, January 27, 2011 3:28 PM +0000 anderson(a)vailsys.com wrote: > Full_Name: Nathanael Anderson > Version: 2.4.19 > OS: RHEL 6 (Linux) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.63.156.11) Please use a current version of OpenLDAP 2.4 prior to filing a bug report to ensure the issue has not been fixed in a subsequent release. The current release is 2.4.23. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6812) Confused syncprov return codes
by h.b.furuseth＠usit.uio.no 28 Jan '11

28 Jan '11

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncprov_state_ctrl(), syncprov_done_ctrl(), syncprov_sendinfo() and thus findpres_cb() can return either an LDAP result code, or a negative number on BER error. I see no code which expects both classes of error codes. The first functions's callers set rs->sr_err = return value. At best I guess it'll be ignored or interpreted as LDAP_SERVER_DOWN.

1 0

Re: (ITS#6684) Patch for autogroup overlay
by moenoel＠informatik.uni-bremen.de 28 Jan '11

28 Jan '11

Am 27.01.2011 16:38, schrieb moenoel(a)informatik.uni-bremen.de: >> 1) it should simply be comparing the AttributeDescription pointers >> 2) since the "memberof" attribute is actually configurable in the memberof >> overlay, there's no guarantee that this is the correct attribute to be looking >> for. It should also be configurable in your patch. >> >> You're using strcasecmp, but your inputs are already normalized values. You >> should just use ber_bvcmp. >> > > Since I am also interested in this, I took some time to make a new > patch. I took Norberts original patch, applied it to a current checkout > from HEAD and tried to fix the issues mentioned by Howard. My initial > tests are looking good. > > My C skills are rather mediocre, though, so I hope I didn't slaughter > the thing :-) > > http://www.informatik.uni-bremen.de/~moenoel/ldap/christian-manal-autogroup… > > > Regards, > Christian Manal > > I just noticed that I messed up the copyright notice. I fixed that and replaced the archive, so the link is still valid.

1 0

(ITS#6811) Patch - Mozilla NSS - disable pkcs11 fork checking for the software token
by rmeggins＠redhat.com 28 Jan '11

28 Jan '11

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-moznss-disable-nofork-20110… Submission from: (NULL) (76.113.111.209) There are some applications that acquire a crypto context in the parent process and expect that crypto context to work after a fork(). This does not work with MozNSS using strict PKCS11 compliance mode. We set the environment variable NSS_STRICT_NOFORK=DISABLED in tlsm_init() to tell the software encryption module/token to allow crypto contexts to persist across a fork(). However, if you are using some other module or encryption device that supports and expects full PKCS11 semantics, the only recourse is to modify the application to use atfork() handlers to save the crypto context in the parent and restore (and SECMOD_RestartModules) the context in the child. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#6810) slapd crashes writing to bdb backend
by bruno_haleblian＠carrefour.com 28 Jan '11

28 Jan '11

Full_Name: Bruno HALEBLIAN Version: 2.4.23 OS: RHEL 5.5/64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.243.12.111) Hello, I'm stuck with "random" slapd crashes, my slapd has been tested successfully in read mode but since I run updates, I get several crashes a day, with no BDB corruption (recover and restart OK) but I can't let this go to production stage. Here's the first core stack I caught, I'll send more if I meet different ones. Thanks for your help. kernel: slapd[13284]: segfault at 0000000000000008 rip 000000000052a377 rsp 0000000043fa5160 error 4 Program terminated with signal 11, Segmentation fault. #0 0x000000000052a377 in syncprov_matchops (op=0x182cdb00, opc=0x182d04c8, saveit=1) at syncprov.c:1309 1309 op2.ors_filter = ss->s_op->ors_filter->f_and->f_next; (gdb) where #0 0x000000000052a377 in syncprov_matchops (op=0x182cdb00, opc=0x182d04c8, saveit=1) at syncprov.c:1309 #1 0x000000000052a5e1 in syncprov_op_mod (op=0x182cdb00, rs=<value optimized out>) at syncprov.c:2075 #2 0x000000000049757a in overlay_op_walk (op=0x182cdb00, rs=0x43fa6c70, which=op_modify, oi=0x17b6e2f0, on=0x17b6e4d0) at backover.c:659 #3 0x0000000000497b47 in over_op_func (op=0x182cdb00, rs=0x43fa6c70, which=op_modify) at backover.c:721 #4 0x000000000044c537 in fe_op_modify (op=0x182cdb00, rs=0x43fa6c70) at modify.c:301 #5 0x000000000044cc92 in do_modify (op=0x182cdb00, rs=0x43fa6c70) at modify.c:175 #6 0x0000000000435655 in connection_operation (ctx=0x43fa6dc0, arg_v=<value optimized out>) at connection.c:1109 #7 0x0000000000435c2f in connection_read_thread (ctx=0x43fa6dc0, argv=<value optimized out>) at connection.c:1245 #8 0x000000000054345c in ldap_int_thread_pool_wrapper (xpool=0x17af0350) at tpool.c:685 #9 0x000000339360673d in start_thread () from /lib64/libpthread.so.0 #10 0x0000003392ed3d1d in removexattr () from /lib64/libc.so.6 #11 0x0000000000000000 in ?? () (gdb) list *0x000000000052a377 0x52a377 is in syncprov_matchops (syncprov.c:1309). 1304 ldap_pvt_thread_mutex_lock( &ss->s_mutex ); 1305 if (ss->s_flags & PS_FIX_FILTER) { 1306 /* Skip the AND/GE clause that we stuck on in front. We 1307 would lose deletes/mods that happen during the refresh 1308 phase otherwise (ITS#6555) */ 1309 op2.ors_filter = ss->s_op->ors_filter->f_and->f_next; 1310 } 1311 ldap_pvt_thread_mutex_unlock( &ss->s_mutex ); 1312 rc = test_filter( &op2, e, op2.ors_filter ); 1313 }

1 0

(ITS#6809) back-sock compare is missing a newline
by hyc＠OpenLDAP.org 28 Jan '11

28 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc All of the messages from back-sock to the other socket server are supposed to be terminated by two newlines. The Compare operation only has one.

1 0

Re: (ITS#6807) syncrepl sends incomplete sync cookie in MMR
by hyc＠symas.com 28 Jan '11

28 Jan '11

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.94.188.8) > Submitted by: hyc > > > In syncrepl_updateCookie() the cookie received from the provider is dup'd as-is. > If the provider is stopped and restarted, this same cookie will be sent back on > the next refresh attempt. In refreshAndPersist mode the cookies sent from the > provider will only contain a single CSN; CSNs from other MMR servers are > omitted. During a restart, because the consumer sends a cookie with only one > CSN, the provider will consider the consumer out of date. > > A fix is coming shortly. For the record... I spent some time considering whether this should actually be fixed in the provider or the consumer. I decided on fixing in the consumer for the sake of network bandwidth/efficiency - in persist mode, a cookie may be sent with every single write operation. Generally only one CSN will be relevant for any given write op, so it would be a waste to send all of the other unchanged CSNs every time. On the consumer side, the consumer must always send all of the context info it has available. This might involve more volume in a request but ordinarily the actual consumer request is only a tiny fraction of the total network traffic. Purists might say that this goes against RFC4533 which states that consumers should treat sync cookies as opaque items, but the OpenLDAP implementation has always relied on exact knowledge of the sync cookie format; this was always required in order to support cascaded replication if nothing else. Also this ITS is specific to MMR, which is not addressed at all in RFC4533. -- -- 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#6808) pcache monitoring cleanup needs monitor entry DN
by masarati＠aero.polimi.it 27 Jan '11

27 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.14.92) Submitted by: ando A fix is coming. p.

1 0

Re: (ITS#6791) Patch - Mozilla NSS - cert verify uses incorrect values
by hyc＠symas.com 27 Jan '11

27 Jan '11

rmeggins(a)redhat.com wrote: > Full_Name: Rich Megginson > Version: 2.4.23 (current CVS HEAD) > OS: RHEL6 > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-cert-verify-uses-incorrect-… > Submission from: (NULL) (76.113.111.209) > > > The cert verify routines were using type SECCertUsage instead of type > SECCertificateUsage. The values are similar, and this was causing verify errors > of SEC_ERROR_INADEQUATE_KEY_USAGE and SEC_ERROR_INADEQUATE_CERT_TYPE. MozNSS > only checks the usage if the cert includes the usage extensions which is why I > didn't see this error earlier. Talk about confusing ... committed to HEAD, thanks. > > These patch files are derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Red Hat. Red Hat has not assigned rights > and/or interest in this work to any party. I, Rich Megginson am > authorized by Red Hat, my employer, to release this work under the > following terms. > > Red Hat hereby place the following modifications to OpenLDAP Software > (and only these modifications) into the public domain. Hence, these > modifications may be freely used and/or redistributed for any purpose > with or without attribution and/or other notice. > -- -- 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#6807) syncrepl sends incomplete sync cookie in MMR
by hyc＠OpenLDAP.org 27 Jan '11

27 Jan '11

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.94.188.8) Submitted by: hyc In syncrepl_updateCookie() the cookie received from the provider is dup'd as-is. If the provider is stopped and restarted, this same cookie will be sent back on the next refresh attempt. In refreshAndPersist mode the cookies sent from the provider will only contain a single CSN; CSNs from other MMR servers are omitted. During a restart, because the consumer sends a cookie with only one CSN, the provider will consider the consumer out of date. A fix is coming shortly.

1 0

Re: (ITS#6684) Patch for autogroup overlay
by moenoel＠informatik.uni-bremen.de 27 Jan '11

27 Jan '11

> 1) it should simply be comparing the AttributeDescription pointers > 2) since the "memberof" attribute is actually configurable in the memberof > overlay, there's no guarantee that this is the correct attribute to be looking > for. It should also be configurable in your patch. > > You're using strcasecmp, but your inputs are already normalized values. You > should just use ber_bvcmp. > Since I am also interested in this, I took some time to make a new patch. I took Norberts original patch, applied it to a current checkout from HEAD and tried to fix the issues mentioned by Howard. My initial tests are looking good. My C skills are rather mediocre, though, so I hope I didn't slaughter the thing :-) http://www.informatik.uni-bremen.de/~moenoel/ldap/christian-manal-autogroup… Regards, Christian Manal

1 0

(ITS#6806) Invalid ldapadd crashes openldap with ndb backend
by anderson＠vailsys.com 27 Jan '11

27 Jan '11

Full_Name: Nathanael Anderson Version: 2.4.19 OS: RHEL 6 (Linux) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.63.156.11) #00_die.ldif dn: cn=die,ou=groups,dc=domain,dc=com objectclass: groupofnames cn: Operations description: People in Operations ldapadd -x -D "cn=admin,dc=domain,dc=com" -W -f 00_die.ldif This will crash the openldap server every time with a Bus error message conn=0 op=1 ADD dn="cn=die,ou=groups,dc=domain,dc=com" Entry (cn=die,ou=groups,dc=domain,dc=com): object class 'groupOfNames' requires attribute 'member' conn=0 op=1 RESULT tag=105 err=65 text=object class 'groupOfNames' requires attribute 'member' Bus error (core dumped)

1 0

Re: ITS#6805
by Kurt＠OpenLDAP.org 27 Jan '11

27 Jan '11

On Jan 27, 2011, at 2:30 AM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> The OP expects somehow for the server to prevent the client from =3D >> exposing information when the server has no control over what the = client =3D >> sends. This simply is not possible and hence should not be expected. >>=20 >> Even if the server were configured only with a ldaps:// listener, =3D >> clients would not be precluded from sending a password to the server = in =3D >> the clear. A client could be told to connect to that listener and = send =3D >> a LDAP Simple Bind with password without ever attempting to start = TLS. =3D >> Sure, the server will error, but the password is exposed none the = less. >=20 > While this is true in general there still could be a benefit from = disallowing > connections without StartTLS at the server-side: Yes, and slapd(8) has long supported such a configuration and, in fact, = the OP had such a configuration. > Normally in a serious deployment there are integration tests done with = client > applications for which no real passwords are used. Disallowing = non-protected > connections would reveal misconfiguration immediately and the = application can > then be modified to do the right thing. >=20 > Ciao, Michael.

1 0

Re: ITS#6805
by michael＠stroeder.com 27 Jan '11

27 Jan '11

Kurt(a)OpenLDAP.org wrote: > The OP expects somehow for the server to prevent the client from = > exposing information when the server has no control over what the client = > sends. This simply is not possible and hence should not be expected. > > Even if the server were configured only with a ldaps:// listener, = > clients would not be precluded from sending a password to the server in = > the clear. A client could be told to connect to that listener and send = > a LDAP Simple Bind with password without ever attempting to start TLS. = > Sure, the server will error, but the password is exposed none the less. While this is true in general there still could be a benefit from disallowing connections without StartTLS at the server-side: Normally in a serious deployment there are integration tests done with client applications for which no real passwords are used. Disallowing non-protected connections would reveal misconfiguration immediately and the application can then be modified to do the right thing. Ciao, Michael.

1 0

Re: (ITS#6804) 'self' access modifier only works for first entry
by hyc＠symas.com 26 Jan '11

26 Jan '11

djpohly(a)gmail.com wrote: > Full_Name: Devin J. Pohly > Version: 2.4.23 > OS: Linux > URL: http://openldap.pastebin.com/gvswpxLX > Submission from: (NULL) (98.235.33.55) Thanks for the detailed report. This is now fixed in HEAD. > Description: > I have set up an LDAP directory which contains users and flat groups > (groupOfNames/member style). I want to use the access controls to only allow > users to see their own groups and membership, so I defined the following > controls: > > access to dn.onelevel="ou=group,o=org" attrs=entry > by dnattr=member read > access to dn.onelevel="ou=group,o=org" attrs=member > by dnattr=member selfread > > Steps to reproduce: > 1. Start a new instance of OpenLDAP with the slapd.conf file provided at > <http://openldap.pastebin.com/gvswpxLX> and an empty database. > 2. Get grouptest.ldif from<http://openldap.pastebin.com/X1DUyGmf> and add it to > the directory: > ldapadd -x -H $LDAPURI -D uid=admin,o=org -w admin -f grouptest.ldif > This creates two users, foo and bar, and two groups, g1 and g2. Each user is in > both groups. > 3. Compare the outputs of: > ldapsearch -x -H $LDAPURI -D uid=foo,ou=user,o=org -w foo -b ou=group,o=org > ldapsearch -x -H $LDAPURI -D uid=bar,ou=user,o=org -w bar -b ou=group,o=org > > Expected results: > Foo's query shows "member: foo" for both g1 and g2. Bar's query shows "member: > bar" for both g1 and g2. > > Actual results: > Foo's query shows "member: foo" for both g1 and g2. Bar's query does not show > any member attributes. > > Note: Changing the order in which the users are listed changes the behavior; > only the first user listed matches 'self'. Changing the 'selfread' privilege to > 'read' behaves correctly: both queries display both users' memberships in the > groups. So the problem lies somewhere in the way the 'self' modifier is > implemented. > -- -- 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#6805
by Kurt＠OpenLDAP.org 26 Jan '11

26 Jan '11

The OP expects somehow for the server to prevent the client from = exposing information when the server has no control over what the client = sends. This simply is not possible and hence should not be expected. Even if the server were configured only with a ldaps:// listener, = clients would not be precluded from sending a password to the server in = the clear. A client could be told to connect to that listener and send = a LDAP Simple Bind with password without ever attempting to start TLS. = Sure, the server will error, but the password is exposed none the less. As you indicate, the same issue exist in more robust clients as well. = It's quite hard to provide client configurability and prevention from = misconfiguration which lead to security issues concurrently. How is the = client software to know that StartTLS or ldaps:// was wanted with it = wasn't so configured? The best a robust client could do here is warn = the user of security concerns that arise from their configuration = choices. I would have no objection to adding such robustness to OpenLDAP command = line tools so long as such warnings were off by default. Kicking out = warnings as the default would likely break a lot of scripts which use = OpenLDAP command line tools. -- Kurt=

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by Kurt＠OpenLDAP.org 26 Jan '11

26 Jan '11

On Jan 26, 2011, at 11:23 AM, masarati(a)aero.polimi.it wrote: >>=20 >> On Jan 26, 2011, at 9:15 AM, masarati(a)aero.polimi.it wrote: >>=20 >>> The complexity of handling this nonsense in libldap seems not worth = the >>> effort; >>=20 >> Ando, you are too kind to refer this extension as 'nonsense'. It's = worse >> than nonsense, it's crap. >>=20 >> The spec you pointed at says: "LDAP servers often place limits on the >> maximum number of attribute values that can be retrieved in a single >> query." >=20 > I'd reword that as "One specific LDAP server places limits on the = maximum > number of attribute values that can be retrieved in a single query." >=20 >> The spec fails to say why would a server want to do that. I >> cannot think of any good reason to do precisely that. While I can >> understand a desire to place limits on what clients can retrieve, I = don't >> see why one would distinguish between a single query and a set of = queries. >> I can also see it desirable to allow a client to page through results >> (but that's a different matter, this is about forcing paging onto >> clients). >>=20 >> It is incredibly stupid to require clients to use multiple operations = to >> obtain information for which the protocol allowed to be fetched in a >> single operation, and this is why I refer to this as "crap". >=20 > :) >=20 >> A major problem with paging, whether server-forced or at = client-option, is >> result set coherency due to changes to the DIT between when various = page >> operations are obtain. This can lead to problems such a member of a = group >> not appearing in the results. While one might argue client might be = able >> to reasonable deal with coherency issues, most client developers = won't. >> This will lead to a range of security issues creeping into directory >> applications. >>=20 >> So while I don't generally oppose introduction of paging extensions = at the >> client option, I think the specifications should warn that the = clients >> using them need to be designed to handle data coherency issues. = However, >> most designers of such extensions seem to have put no thought into = this >> issue at all. >=20 > Well, I don't see paged results as a way to introduce more = inconsistency > than a regular search operation, since nowhere in the specs I see that = the > collection of the entries returned by a search are consistent with the > entries matching the search request at a specific time (e.g. when the > operation was initiated or so). As a consequence, clients need be = aware > of the fact that search results can be inherently inconsistent, paging = or > not. As LDAP is defined as an access protocol to an X.500 directory, it = inherits some data consistency expectations. In generally expected that = entry-level access have ACID properties. That is, each successful = modify operation creates a new DIT state and a read operation returns = information consistent with a particular state. That is, say the DIT = has state X and there is modify operation that produces state Y and a = concurrent issued read operation (and no other operations), the read = operation will return either state X or state Y depending on whether it = is processed before or after the modify operation. The read ought not = provide some intermediate state. A search operation acts upon a collection of entries, there is a = possibility of inconsistencies between different entries (but not within = them), especially in distributed DITs. However, as we're talking about values of an attribute of a particular = entry, this is a non-issue in this discussion.

1 0

ITS#6805
by masarati＠aero.polimi.it 26 Jan '11

26 Jan '11

I'd note that sending cleartext credentials is just wrong regardless of the ssf the server requires. OpenLDAP's ldapsearch assumes users know what they are doing. Actually, this client is mainly intended as a tool that allows to perform operations with as many parameter combinations as needed to test the functionalities of slapd. What you recommend would probably be appropriate for a "real life" client implementation. Moreover, the only way to test whether the security factor requested by the server is in place would require the client to attempt a simple bind with intentionally invalid credentials; considering slapd's possibility to configure security per-database, one would need to either use the "right" DN (thus exposing it), or a fake DN that for sure is within the same naming context, and incorrect credentials. I believe this amount of wisdom is beyond any "real life" client implementation. Of course I would not object to any patch for ldapsearch (actually, for all clients) that solves this problem in a general manner without requiring any user intervention. p.

1 0

(ITS#6805) ldapsearch can expose cleartext password needlessly
by leblanc＠math.toronto.edu 26 Jan '11

26 Jan '11

Full_Name: Emile LeBlanc Version: openldap-clients-2.3.43-12.el5_5.3.i386 OS: Red Hat Enterprise Linux 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.100.68.202) I am running the latest version of ldapsearch (that comes with Red Hat Enterprise Linux 5.6) on my machine. If I run: ldapsearch -Z -W -LLL -D "uid=guest,ou=Unit,dc=math,dc=toronto,dc=edu" -H ldap://test.math.toronto.edu -x -b "dc=math,dc=toronto,dc=edu" "(uid=guest)" then the result is as I expect (after I type the passwd to the "Enter LDAP Password:" prompt). However if I remove the "-Z" flag and run: ldapsearch -W -LLL -D "uid=guest,ou=Unit,dc=math,dc=toronto,dc=edu" -H ldap://test.math.toronto.edu -x -b "dc=math,dc=toronto,dc=edu" "(uid=guest)" then, after typing the password I see: ldap_bind: Confidentiality required (13) additional info: confidentiality required This result was also expected since the ldap server has: security ssf=256 in the slapd.conf file. What was unexpected was that the password was sent in cleartext in the second "ldapsearch" command (I verified this with "wireshark", a network packet analyzer). It is true that I should use the "-Z" flag if I want encryption but I think that a simple error on the client end should not expose a password when the initial connection to a secured server could have been tried without transmitting the password to see if additional security was needed. Perhaps there is some good reason for the current behavior, but I wanted to make sure that people realized what was happening. Perhaps the performance hit my suggestion would entail is not worth it for other users. Thank you.

1 0

Re: (ITS#5472) ldap_get_values() should handle paged results from LDAP/AD
by masarati＠aero.polimi.it 26 Jan '11

26 Jan '11

> > On Jan 26, 2011, at 9:15 AM, masarati(a)aero.polimi.it wrote: > >> The complexity of handling this nonsense in libldap seems not worth the >> effort; > > Ando, you are too kind to refer this extension as 'nonsense'. It's worse > than nonsense, it's crap. > > The spec you pointed at says: "LDAP servers often place limits on the > maximum number of attribute values that can be retrieved in a single > query." I'd reword that as "One specific LDAP server places limits on the maximum number of attribute values that can be retrieved in a single query." > The spec fails to say why would a server want to do that. I > cannot think of any good reason to do precisely that. While I can > understand a desire to place limits on what clients can retrieve, I don't > see why one would distinguish between a single query and a set of queries. > I can also see it desirable to allow a client to page through results > (but that's a different matter, this is about forcing paging onto > clients). > > It is incredibly stupid to require clients to use multiple operations to > obtain information for which the protocol allowed to be fetched in a > single operation, and this is why I refer to this as "crap". :) > A major problem with paging, whether server-forced or at client-option, is > result set coherency due to changes to the DIT between when various page > operations are obtain. This can lead to problems such a member of a group > not appearing in the results. While one might argue client might be able > to reasonable deal with coherency issues, most client developers won't. > This will lead to a range of security issues creeping into directory > applications. > > So while I don't generally oppose introduction of paging extensions at the > client option, I think the specifications should warn that the clients > using them need to be designed to handle data coherency issues. However, > most designers of such extensions seem to have put no thought into this > issue at all. Well, I don't see paged results as a way to introduce more inconsistency than a regular search operation, since nowhere in the specs I see that the collection of the entries returned by a search are consistent with the entries matching the search request at a specific time (e.g. when the operation was initiated or so). As a consequence, clients need be aware of the fact that search results can be inherently inconsistent, paging or not. > I do generally oppose introduction of non-truly optional extensions in > LDAP (and in other application protocols). One would think that a > requirement that extensions to a protocol be truely optional would go > without saying, but in IETF we actually found it necessary to explicitly > state this in the BCP governing LDAP extensions. > > That BCP will effectively stop non-truly optional extension proposal as > this from gaining Standard Track status in the IETF. > >> I think we might consider working this around in proxy backends >> (much like we did for unsolicited paged results response in back-meta, >> ITS#6664, which could be added to back-ldap as well). > > I would think it easier to reconfigure AD not to have the limits which > cause this sort of paging. Of course. The whole discussion about this issue (and others) and often the thrust that pushes the development of many features in the proxy backends (and other features, like slapo-rwm, slapo-translucent and more) is the practical impossibility to affect the configuration of one or more remote servers. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs