openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5318) response msgid <= 0 mishandled in libldap
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard libraries/libldap/result.c:try_read1msg() accesses 'lr' uninitialized if 'id' (message ID) from line 577's 'ber_get_int( ber, &id )' is <= 0. I'm not sure if the client should terminate the connection when it receives message id < 0, or if it should just toss the response like it does with unknown message IDs. With message ID 0, the code reaches this statement with 'lr' uninitialized: Debug( LDAP_DEBUG_TRACE, "read1msg: ld %p msgid %ld message type %s\n", (void *)ld, (long)lr->lr_msgid, ldap_int_msgtype2str( tag ) ); As far as I can tell, normally lr->lr_msgid == id. I haven't tracked what those values are with LDAP_CONNECTIONLESS at the 'nextresp2:' label. A 700-line function with 5 labels, yuck. Anyway, I wonder why taht statement and the statement below: if ( id == 0 ) { doesn't use the same value, either id or lr->lr_msgid for both.

1 0

(ITS#5317) bad result for ldapsearch -f
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard ldapsearch rev 1.241 "allow continuous mode" introduced one bug and one probably-byg: * ldapsearch -f/dev/null returns an uninitialized value 'rc'. Fixing. * last instead of "worst" search return value is returned with continuous mode. I.e error followed by success returns success. I assume it should return failure like ldapmodify (see the code which saves rc in 'ret')?

1 0

(ITS#5316) authzTo unevaluated in 2.4.7
by m.erde＠gmx.net 09 Jan '08

09 Jan '08

Full_Name: Matthias Erde Version: 2.4.7 OS: FreeBSD 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.176.162.227) Hello, after upgrading to 2.4.7 (from 2.4.6) I cannot longer authzTo neither authcid in sasl binds nor proxyauth (e.g. as used by Howard's ldapdb contributed to cyrsu-sasl) were working. -Mat

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

Thinking a bit more... I wrote: > But I agree those attribute names make things icky. Attributes named "add"/"delete"/"replace" are not the only problem cases. A program which generates LDIF must also take care with attributes named "control" and "changetype". And with OpenLDAP, "increment". Which may be a worse problem since it's not mentioned in the LDIF spec. Still, the new ldapmodify seems to me to add very little value to the ldapadd program. It is ldapadd which accepts LDIF format. ldapmodify does not. Yet the only difference now seems to be that one can omit the "changetype:" line, one must still use the more verbose "add/..." and "_" lines. Another possible approach: Strict LDIF format, a record's attributes shall use "add/replace/...: attribute" if and only if the record has a "changetype:" line. Without them, ldapadd does changetype:add + add:attrs, ldapmodify does changetype:modify + replace:attrs. -- Hallvard

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

Howard Chu writes: >Hallvard B Furuseth wrote: >> Changing the -devel thread's example a bit, I'd say 2.3 accepted one >> dangerous bug, one unambigious but possibly misleading format (a modify >> record both with and witout "add/delete/replace: attribute" lines), and >> one safe format (changetype: modify but no add/delete/replace"): > > No. If you (foolishly or unluckily) have attributes in your schema named > "add", "delete", or "replace" then in <=2.3 you are completely hosed. There > are no unambiguous or safe cases in these malformed inputs. Well, you'd have to use "add/delete/replace:". ldapmodify only noticed those keywords after "-", "dn:" and "changetype:" lines.to omit it. to omit it. But I agree those attribute names make things icky. And they still do, because "changetype:" is optional. This LDIF: dn: dc=example,dc=com add: foo foo: bar affects attr "foo" with ldapmodify, but "add" and "foo" with ldapadd. The current change seems to me to require either too little or too much RFC 2849 conformance in ldapmodify. (Require the final "-" and it gets stricter.) >> OTOH it would be an LDIF-compatible extension to make the attribute >> description in "attribute: value" optional after "add/replace/delete: >> attribute". Then one could omit the terminating "-" too. > > Likewise, this is unsafe. Why so? Treat a ": value" line followed by a "whatever:" line as if there was a "-" line between. "delete/replace: attr" not followed by attribute value lines might need a "-" after it though. -- Hallvard

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by hyc＠symas.com 09 Jan '08

09 Jan '08

Hallvard B Furuseth wrote: > Changing the -devel thread's example a bit, I'd say 2.3 accepted one > dangerous bug, one unambigious but possibly misleading format (a modify > record both with and witout "add/delete/replace: attribute" lines), and > one safe format (changetype: modify but no add/delete/replace"): No. If you (foolishly or unluckily) have attributes in your schema named "add", "delete", or "replace" then in <=2.3 you are completely hosed. There are no unambiguous or safe cases in these malformed inputs. > OTOH it would be an LDIF-compatible extension to make the attribute > description in "attribute: value" optional after "add/replace/delete: > attribute". Then one could omit the terminating "-" too. Likewise, this is unsafe. > Maybe it's time to take this to the ldapext list and hear what others > do. -- -- 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#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

I wrote: > As far as I can tell Logschema doesn't support full LDIF modify though. > reqMod is unordered, so one cannot make two modifications to the same > attribute. E.g. "delete: foo" followed by "replace: foo". Sorry, followed by "add: foo" makes more sense. E.g. delete sn: chu add sn: Chu -- Hallvard

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by h.b.furuseth＠usit.uio.no 09 Jan '08

09 Jan '08

Howard Chu writes: > Hm... Where were you when we were originally discussing these changes? > http://www.openldap.org/lists/openldap-devel/200611/msg00013.html > http://www.openldap.org/lists/openldap-devel/200611/msg00022.html Absent. I did look at it though, but I didn't realize how far the changes went. See below. > HEAD has been working this way for over a year, and it's clearly more > correct in its behavior now than it was before. True, the old way was quite broken as that thread shows. >> If anything, the LDIF RFC could be revised instead. This format has >> been supported since umich ldap (before the LDIF RFC was written). > > That doesn't mean it has any relevance today; there's plenty of stuff > UMich did that was long since deprecated. True, but this was not deprecated that I know of. So: > It may be OK to revert this single aspect of the change. If you do so, > just make sure that those other corner cases mentioned in the -devel > thread are still handled correctly. Changing the -devel thread's example a bit, I'd say 2.3 accepted one dangerous bug, one unambigious but possibly misleading format (a modify record both with and witout "add/delete/replace: attribute" lines), and one safe format (changetype: modify but no add/delete/replace"): dn: dc=example,dc=com changetype: modify add: cn cn: foo # bug: implicit "add: sn". Since the "-" was optional, one might even # expect the new attribute type to revert to the default "replace:". sn: bar - # Safe after the "-" but possibly confusing - implicit "replace: # description" and "replace: telephoneNumber" description: xyzzy telephoneNumber: 12345678 # OK: implicit "replace:" for everything dn: dc=example,dc=com changetype: modify cn: foo sn: bar description: xyzzy telephoneNumber: 12345678 Snipping a bit from the -devel thread: Howard Chu wrote: > (Did I mention that I've always thought the mod-spec definition was > garbage? The format I use for the logschema has none of these problems > or inefficiences...) As far as I can tell Logschema doesn't support full LDIF modify though. reqMod is unordered, so one cannot make two modifications to the same attribute. E.g. "delete: foo" followed by "replace: foo". OTOH it would be an LDIF-compatible extension to make the attribute description in "attribute: value" optional after "add/replace/delete: attribute". Then one could omit the terminating "-" too. Maybe it's time to take this to the ldapext list and hear what others do. -- Hallvard

1 0

Re: (ITS#5312) ldapmodify(1) man page claims that "changetype:" not necessary
by hyc＠symas.com 09 Jan '08

09 Jan '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> daveh(a)coreng.com.au wrote: >>> As a followup, I should point out that this behaviour worked in at least >>> 2.2 and 2.3. >> Yes, I recall changing this in the 2.4 code; I guess I didn't update >> the manpage. > > Not sure which of this discussion should go where - I saw it first in > the ldap@umich list. But anyway, I suggest to revert that change. Hm... Where were you when we were originally discussing these changes? http://www.openldap.org/lists/openldap-devel/200611/msg00013.html http://www.openldap.org/lists/openldap-devel/200611/msg00022.html HEAD has been working this way for over a year, and it's clearly more correct in its behavior now than it was before. > If > anything, the LDIF RFC could be revised instead. This format has been > supported since umich ldap (before the LDIF RFC was written). That doesn't mean it has any relevance today; there's plenty of stuff UMich did that was long since deprecated. > Note that the format which OpenLDAP-2.4 ldapmodify reads is still not > LDIF, since "changetype:" defaults to modify instead of add. That's > incompatible with LDIF. OTOH default operation "replace:" for > changetype "modify" was compatible with LDIF, since LDIF does not > support a missing "add/delete/replace:" for changetype modify. > > Some history: > > - umich ldap-3.3 (1996): There were two LDIF defaults: Whether a missing > "changetype:" would default to "add" or "modify", and whether a > missing attribute operation type would default to "add" or "replace". > These were controlled by different flags: -a (or invoking as ldapadd) > for the first, -r (replace) for the second. > > - RFC 2849 - LDIF (2000): The defaults "changetype:modify" and > "replace:" were dropped, presumably because a file format could not > support command line options. > > - OpenLDAP 2.1 (2002): Removed the -r option and instead made it the > default when changetype was modify (and thus for ldapmodify). -r was > only used with ldapmodify and was usually what one wanted there. > (Note that "replace:" is equivalent to "add:" if the attribute does > not already exist in the entry.) It may be OK to revert this single aspect of the change. If you do so, just make sure that those other corner cases mentioned in the -devel thread are still handled correctly. -- -- 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#5315) Crash in ldap_parse_page_control
by rhafer＠suse.de 09 Jan '08

09 Jan '08

Full_Name: Ralf Haferkamp Version: RE24, HEAD OS: any URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.8.71.175) Applications using ldap_parse_page_control (e.g. nss_ldap) might crash. valgrind reports this: ==21971== Invalid write of size 8 ==21971== at 0x5BDFF04: ldap_parse_page_control (pagectrl.c:263) ==21971== by 0x599F170: do_result (ldap-nss.c:2511) ==21971== by 0x599F289: do_parse (ldap-nss.c:2844) ==21971== by 0x59A0245: _nss_ldap_getent_ex (ldap-nss.c:3413) [..] ==21971== Address 0x51fad38 is 0 bytes after a block of size 8 alloc'd ==21971== at 0x4C2460E: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so) ==21971== by 0x5E0652C: ber_memalloc_x (memory.c:226) ==21971== by 0x5BDFEEB: ldap_parse_page_control (pagectrl.c:259) ==21971== by 0x599F170: do_result (ldap-nss.c:2511) ==21971== by 0x599F289: do_parse (ldap-nss.c:2844) ==21971== by 0x59A0245: _nss_ldap_getent_ex (ldap-nss.c:3413) [..] Fix is on the way to HEAD.

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