- openldap-bugs - openldap.org

(ITS#7262) ppolicy overlay cannot use a policy stored in a different backend from the account that it controls
by andrew.findlay＠skills-1st.co.uk 02 May '12

02 May '12

Full_Name: Andrew Findlay Version: 2.4.26 OS: OpenSuSE 11.4 URL: ftp://ftp.openldap.org/incoming/andrew-findlay-2012050201.tar Submission from: (NULL) (2a01:348:28c:1::94) I have a setup where several OUs share a server, with one backend database per OU. Config data like password policies and service accounts is in another backend DB. The password policies do not work unless they are copied into each backend DB. The attached tar contains a full test to demonstrate the problem. Here is a summary of the README: There are two databases, for suffixes dc=a,dc=example,dc=org and dc=zzz,dc=example,dc=org (note different length, which helps later) There are two accounts - a1 and zzz1 - each stored in a different backend database. Both accounts are locked with 'pwdAccountLockedTime: 00000101000000Z' Each database uses the ppolicy overlay, and both have cn=ppol-a,dc=a,dc=example,dc=org as the default policy. The run-test script does this: echo "Binding as a1" ldapwhoami -x -D uid=a1,dc=a,dc=example,dc=org -w "secret" echo "Binding as zzz1" ldapwhoami -x -D uid=zzz1,dc=zzz,dc=example,dc=org -w "secret" Both accounts are locked so both should fail to bind. In practice a1 fails correctly, but zzz1 binds. If you run slapd with debug: ./start-slapd -d 65535 you can see some clues: => bdb_entry_get: found entry: "uid=zzz1,dc=zzz,dc=example,dc=org" bdb_entry_get: rc=0 => bdb_entry_get: ndn: "cn=ppol-a,dc=a,dc=example,dc=org" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=ppol-a,dc=a,dc=example,dc=org") => hdb_dn2id("a,dc=a,dc=example,dc=org") --------------^^ INVALID DN <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) => bdb_entry_get: cannot find entry: "cn=ppol-a,dc=a,dc=example,dc=org" The corresponding lines for a1 are: => bdb_entry_get: found entry: "uid=a1,dc=a,dc=example,dc=org" bdb_entry_get: rc=0 => bdb_entry_get: ndn: "cn=ppol-a,dc=a,dc=example,dc=org" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=ppol-a,dc=a,dc=example,dc=org") => hdb_dn2id("cn=ppol-a,dc=a,dc=example,dc=org") The big clue here is this line: => hdb_dn2id("a,dc=a,dc=example,dc=org") The invalid DN has the same length as the suffix of the other DB: a,dc=a,dc=example,dc=org dc=zzz,dc=example,dc=org I think the overlay is looking for cn=ppol-a,dc=a,dc=example,dc=org in the DB containing dc=zzz,dc=example,dc=org Andrew

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by hyc＠symas.com 27 Apr '12

27 Apr '12

This is a multi-part message in MIME format. --------------080305040400020709070605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit jvcelak(a)redhat.com wrote: >> What happens is that the memberof overlay, when stacked on the frontend >> database, keeps looping until the stack is exhausted, since internal >> modifications keep calling the frontend's modify hook rather than the >> actual one that needs to be called. > > I have no idea how to fix it. I probably do not understand the manipulation > with BackedInfo structures fully. > > It is obious that it is caused by doing a search from the modrdn operation > callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). Other > backends does not call any backend operation at the same moment (op->callback). > > Frontend fe_op_search() is called. It tries to choose the right backend with > select_backend(). Which returns the overlay backend (bi_type == "over"), > over_op_walk() then selects fe_op_search() again, and we are looping infinitely. > > I have no clue how to hide or temporarily deactivate the overlay in > memberof_res_modrdn() to make the select_backend() function to choose the right > underlaying backend. Or maybe I have choosen a wrong way of fixing it. > > All ideas are welcomed. :-) The attached diff fixes this particular problem. I haven't spent any time to see if the other be_* invocations need to be protected the same way. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------080305040400020709070605 Content-Type: text/plain; charset=UTF-8; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" diff --git a/servers/slapd/overlays/memberof.c b/servers/slapd/overlays/memberof.c index 502cb46..555d5d9 100644 --- a/servers/slapd/overlays/memberof.c +++ b/servers/slapd/overlays/memberof.c @@ -285,7 +285,8 @@ memberof_isGroupOrMember( Operation *op, memberof_cbinfo_t *mci ) op2.ors_filterstr = mo->mo_groupFilterstr; op2.ors_filter = &mo->mo_groupFilter; - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + if (bi->bi_type == memberof.on_bi.bi_type) + op2.o_bd->bd_info = (BackendInfo *)on->on_info; (void)op->o_bd->be_search( &op2, &rs2 ); op2.o_bd->bd_info = bi; @@ -307,9 +308,9 @@ memberof_isGroupOrMember( Operation *op, memberof_cbinfo_t *mci ) op2.ors_filterstr = mo->mo_memberFilterstr; op2.ors_filter = &mo->mo_memberFilter; - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + if (bi->bi_type == memberof.on_bi.bi_type) + op2.o_bd->bd_info = (BackendInfo *)on->on_info; (void)op->o_bd->be_search( &op2, &rs2 ); - op2.o_bd->bd_info = bi; if ( mc.foundit ) { iswhat |= MEMBEROF_IS_MEMBER; --------------080305040400020709070605--

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by jvcelak＠redhat.com 26 Apr '12

26 Apr '12

> What happens is that the memberof overlay, when stacked on the frontend > database, keeps looping until the stack is exhausted, since internal > modifications keep calling the frontend's modify hook rather than the > actual one that needs to be called. I have no idea how to fix it. I probably do not understand the manipulation with BackedInfo structures fully. It is obious that it is caused by doing a search from the modrdn operation callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). Other backends does not call any backend operation at the same moment (op->callback). Frontend fe_op_search() is called. It tries to choose the right backend with select_backend(). Which returns the overlay backend (bi_type == "over"), over_op_walk() then selects fe_op_search() again, and we are looping infinitely. I have no clue how to hide or temporarily deactivate the overlay in memberof_res_modrdn() to make the select_backend() function to choose the right underlaying backend. Or maybe I have choosen a wrong way of fixing it. All ideas are welcomed. :-) Thanks & Regards, Jan

1 0

Re: (ITS#7261) ldapsearch with base specified does not return anything
by ashish＠sendmail.com 26 Apr '12

26 Apr '12

dn: dc=com objectClass: top objectClass: extensibleObject http://www.openldap.org/its/index.cgi/Incoming?id=7261 is not bug (at least not reproducible with the data added). That is because I missed out the objectClass: domain in the above entry.

1 0

(ITS#7261) ldapsearch with base specified does not return anything
by ashish＠sendmail.com 25 Apr '12

25 Apr '12

Full_Name: Ashish Gawarikar Version: 2.4.31 OS: Redhat 5.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.211.143.38) Configure slapd with multiple databases: database bdb directory /var/ldap/openldap-bdb24 suffix "sendmailMTAMapName=virtuser,sendmailMTACluster=hub,dc=example,dc=com" subordinate advertise dbconfig set_lg_dir /var/ldap/openldap-bdb24/log database bdb directory /var/ldap/openldap-bdb23 suffix "sendmailMTAMapName=stduser,sendmailMTACluster=hub,dc=example,dc=com" subordinate advertise dbconfig set_lg_dir /var/ldap/openldap-bdb23/log database bdb directory /var/ldap/openldap-bdb22 suffix "sendmailMTAMapName=generics,sendmailMTACluster=hub,dc=example,dc=com" subordinate advertise dbconfig set_lg_dir /var/ldap/openldap-bdb22/log database bdb directory /var/sendmail/ldap/openldap-bdb21 suffix "sendmailMTAAliasGrouping=aliases,sendmailMTACluster=hub,dc=example,dc=com" subordinate advertise dbconfig set_lg_dir /var/ldap/openldap-bdb21/log database bdb directory /var/ldap/openldap-bdb20 suffix "sendmailMTACluster=hub,dc=example,dc=com" subordinate advertise dbconfig set_lg_dir /var/ldap/openldap-bdb20/log database bdb directory /var/ldap/openldap-bdb13 suffix "sendmailMTAMapName=b,sendmailMTACluster=QQQ,dc=example,dc=com" subordinate advertise dbconfig set_lg_dir /var/ldap/openldap-bdb13/log database bdb directory /var/ldap/openldap-bdb12 suffix "sendmailMTAMapName=E,sendmailMTACluster=QQQ,dc=example,dc=com" subordinate advertise dbconfig set_lg_dir /var/ldap/openldap-bdb12/log database bdb directory /var/ldap/openldap-bdb11 suffix "sendmailMTAMapName=Es,sendmailMTACluster=QQQ,dc=example,dc=com" subordinate advertise dbconfig set_lg_dir /var/ldap/openldap-bdb11/log database bdb directory /var/ldap/openldap-bdb10 suffix "sendmailMTACluster=QQQ,dc=example,dc=com" subordinate advertise dbconfig set_lg_dir /var/ldap/openldap-bdb10/log database hdb directory /var/ldap/openldap-bdb suffix "" === 10 ldifs: 1.ldif dn: sendmailMTAMapName=virtuser,sendmailMTACluster=hub,dc=example,dc=com objectClass: sendmailMTAMap objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTACluster: hub sendmailMTAMapName: virtuser 2.ldif dn: sendmailMTAMapName=stduser,sendmailMTACluster=hub,dc=example,dc=com objectClass: sendmailMTAMap objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTACluster: hub sendmailMTAMapName: stduser 3.ldif dn: sendmailMTAMapName=generics,sendmailMTACluster=hub,dc=example,dc=com objectClass: sendmailMTAMap objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTACluster: hub sendmailMTAMapName: generics 4.ldif dn: sendmailMTAAliasGrouping=aliases,sendmailMTACluster=hub,dc=example,dc=com objectClass: sendmailMTAAlias objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTAAliasGrouping: aliases sendmailMTACluster: hub 5.ldif dn: sendmailMTACluster=hub,dc=example,dc=com objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTACluster: hub 6.ldif dn: sendmailMTAMapName=b,sendmailMTACluster=QQQ,dc=example,dc=com objectClass: sendmailMTAMap objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTACluster: QQQ sendmailMTAMapName: b 7.ldif dn: sendmailMTAMapName=E,sendmailMTACluster=QQQ,dc=example,dc=com objectClass: sendmailMTAMap objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTACluster: QQQ sendmailMTAMapName: E 8.ldif dn: sendmailMTAMapName=Es,sendmailMTACluster=QQQ,dc=example,dc=com objectClass: sendmailMTAMap objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTACluster: QQQ sendmailMTAMapName: Es 9.ldif dn: sendmailMTACluster=QQQ,dc=example,dc=com objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTACluster: QQQ 10.ldif dn: dc=example,dc=com objectClass: top objectClass: extensibleObject dc: example dn: dc=com objectClass: top objectClass: extensibleObject Add entries in the db using: slapadd -w -l 1.ldif -b sendmailMTAMapName=virtuser,sendmailMTACluster=hub,dc=example,dc=com slapadd -w -l 2.ldif -b sendmailMTAMapName=stduser,sendmailMTACluster=hub,dc=example,dc=com slapadd -w -l 3.ldif -b sendmailMTAMapName=generics,sendmailMTACluster=hub,dc=example,dc=com slapadd -w -l 4.ldif -b sendmailMTAAliasGrouping=aliases,sendmailMTACluster=hub,dc=example,dc=com slapadd -w -l 5.ldif -b sendmailMTACluster=hub,dc=example,dc=com slapadd -w -l 6.ldif -b sendmailMTAMapName=b,sendmailMTACluster=QQQ,dc=example,dc=com slapadd -w -l 7.ldif -b sendmailMTAMapName=E,sendmailMTACluster=QQQ,dc=example,dc=com slapadd -w -l 8.ldif -b sendmailMTAMapName=Es,sendmailMTACluster=QQQ,dc=example,dc=com slapadd -w -l 9.ldif -b sendmailMTACluster=QQQ,dc=example,dc=com # rest in the default bucket slapadd -w -l 10.ldif -b '' =========== Do an ldapsearch without the base specified: ldapsearch -x # aliases, hub, example.com dn: sendmailMTAAliasGrouping=aliases,sendmailMTACluster=hub,dc=example,dc=com objectClass: sendmailMTAAlias objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTAAliasGrouping: aliases sendmailMTACluster: hub # hub, example.com dn: sendmailMTACluster=hub,dc=example,dc=com objectClass: sendmailMTA objectClass: top objectClass: extensibleObject sendmailMTACluster: hub ... Do an ldapsearch with base: ldapsearch -x -b "dc=example,dc=com" # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 Similar search works on Openldap 2.3.x ================================================================================= sendmail.schema file # Copyright (c) 2000-2002, 2005 Sendmail, Inc. and its suppliers. # All rights reserved. # # By using this file, you agree to the terms and conditions set # forth in the LICENSE file which can be found at the top level of # the sendmail distribution. # # $Id: sendmail.schema,v 8.22 2005/09/16 20:18:14 ca Exp $ # Note that this schema is experimental at this point as it has had little # public review. Therefore, it may change in future versions. Feedback # via sendmail-YYYY(a)support.sendmail.org is encouraged (replace YYYY with # the current year, e.g., 2005). # OID arcs for Sendmail # enterprise: 1.3.6.1.4.1 # sendmail: enterprise.6152 # sendmail-at: sendmail.3.1 # sendmail-oc: sendmail.3.2 ########################################################################### # # The Sendmail MTA attributes and objectclass # ########################################################################### # attribute sendmailMTACluster cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.10 NAME 'sendmailMTACluster' DESC 'cluster name associated with a set of MTAs' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) # attribute sendmailMTAHost cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.11 NAME 'sendmailMTAHost' DESC 'host name associated with a MTA cluster' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) #objectClass sendmailMTA # requires # objectClass # allows # sendmailMTACluster, # sendmailMTAHost, # Description objectclass ( 1.3.6.1.4.1.6152.10.3.2.10 NAME 'sendmailMTA' SUP top STRUCTURAL DESC 'Sendmail MTA definition' MAY ( sendmailMTACluster $ sendmailMTAHost $ Description ) ) ########################################################################### # # The Sendmail MTA shared attributes # ########################################################################### # attribute sendmailMTAKey cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.13 NAME 'sendmailMTAKey' DESC 'key (left hand side) of an aliases or map entry' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) ########################################################################### # # The Sendmail MTA Map attributes and objectclasses # ########################################################################### # attribute sendmailMTAMapName cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.14 NAME 'sendmailMTAMapName' DESC 'identifier for the particular map' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE ) # attribute sendmailMTAMapValue cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.16 NAME 'sendmailMTAMapValue' DESC 'value (right hand side) of a map entry' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) # attribute sendmailMTAMapSearch cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.24 NAME 'sendmailMTAMapSearch' DESC 'recursive search for values of a map entry' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) # attribute sendmailMTAMapURL cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.25 NAME 'sendmailMTAMapURL' DESC 'recursive search URL for values of a map entry' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) #objectClass sendmailMTAMap # requires # objectClass, # sendmailMTAMapName, # allows # sendmailMTACluster, # sendmailMTAHost, # Description objectclass ( 1.3.6.1.4.1.6152.10.3.2.11 NAME 'sendmailMTAMap' SUP sendmailMTA STRUCTURAL DESC 'Sendmail MTA map definition' MUST sendmailMTAMapName MAY ( sendmailMTACluster $ sendmailMTAHost $ Description ) ) #objectClass sendmailMTAObject # requires # objectClass, # sendmailMTAMapName, # sendmailMTAKey, # allows # sendmailMTACluster, # sendmailMTAHost, # sendmailMTAMapValue, # sendmailMTAMapSearch, # sendmailMTAMapURL, # Description objectclass ( 1.3.6.1.4.1.6152.10.3.2.12 NAME 'sendmailMTAMapObject' SUP sendmailMTAMap STRUCTURAL DESC 'Sendmail MTA map object' MUST ( sendmailMTAMapName $ sendmailMTAKey ) MAY ( sendmailMTACluster $ sendmailMTAHost $ sendmailMTAMapValue $ sendmailMTAMapSearch $ sendmailMTAMapURL $ Description ) ) ########################################################################### # # The Sendmail MTA Alias attributes and objectclasses # ########################################################################### # attribute sendmailMTAAliasGrouping cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.18 NAME 'sendmailMTAAliasGrouping' DESC 'name that identifies a particular aliases grouping' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} ) # attribute sendmailMTAAliasValue cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.20 NAME 'sendmailMTAAliasValue' DESC 'value (right hand side) of an alias' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) # attribute sendmailMTAAliasSearch cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.26 NAME 'sendmailMTAAliasSearch' DESC 'recursive search for values of an alias' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) # attribute sendmailMTAAliasURL cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.27 NAME 'sendmailMTAAliasURL' DESC 'recursive search URL for values of an alias' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) #objectClass sendmailMTAAlias # requires # objectClass, # allows # sendmailMTAAliasGrouping, # sendmailMTACluster, # sendmailMTAHost, # Description objectclass ( 1.3.6.1.4.1.6152.10.3.2.13 NAME 'sendmailMTAAlias' SUP sendmailMTA STRUCTURAL DESC 'Sendmail MTA alias definition' MAY ( sendmailMTAAliasGrouping $ sendmailMTACluster $ sendmailMTAHost $ Description ) ) #objectClass sendmailMTAAliasObject # requires # objectClass, # sendmailMTAKey, # allows # sendmailMTAAliasGrouping, # sendmailMTACluster, # sendmailMTAHost, # sendmailMTAAliasValue, # sendmailMTAAliasSearch, # sendmailMTAAliasURL, # Description objectclass ( 1.3.6.1.4.1.6152.10.3.2.14 NAME 'sendmailMTAAliasObject' SUP sendmailMTAAlias STRUCTURAL DESC 'Sendmail MTA alias object' MUST sendmailMTAKey MAY ( sendmailMTAAliasGrouping $ sendmailMTACluster $ sendmailMTAHost $ sendmailMTAAliasValue $ sendmailMTAAliasSearch $ sendmailMTAAliasURL $ Description ) ) ########################################################################### # # The Sendmail MTA Class attributes and objectclass # ########################################################################### # attribute sendmailMTAClassName cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.22 NAME 'sendmailMTAClassName' DESC 'identifier for the class' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE ) # attribute sendmailMTAClassValue cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.23 NAME 'sendmailMTAClassValue' DESC 'member of a class' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) # attribute sendmailMTAClassSearch cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.28 NAME 'sendmailMTAClassSearch' DESC 'recursive search for members of a class' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) # attribute sendmailMTAClassURL cis attributetype ( 1.3.6.1.4.1.6152.10.3.1.29 NAME 'sendmailMTAClassURL' DESC 'recursive search URL for members of a class' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) #objectClass sendmailMTAClass # requires # objectClass, # sendmailMTAClassName, # allows # sendmailMTACluster, # sendmailMTAHost, # sendmailMTAClassValue, # sendmailMTAClassSearch, # sendmailMTAClassURL, # Description objectclass ( 1.3.6.1.4.1.6152.10.3.2.15 NAME 'sendmailMTAClass' SUP sendmailMTA STRUCTURAL DESC 'Sendmail MTA class definition' MUST sendmailMTAClassName MAY ( sendmailMTACluster $ sendmailMTAHost $ sendmailMTAClassValue $ sendmailMTAClassSearch $ sendmailMTAClassURL $ Description ) )

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by masarati＠aero.polimi.it 25 Apr '12

25 Apr '12

> Hello, > >> Enabling memberof overlay on frontend database causes slapd to >> SEGFAULT due to stack overflow when renaming an entry. > > please, can somebody confirm that this configuration is wrong and > that it should not be allowed? Or that this configuration is > correct and the "overlay effect" should be inherited by backend > database? > > I would like to help with fixing this, but I have no idea what > is the expected behavior. Documentation says nothing about this. What happens is that the memberof overlay, when stacked on the frontend database, keeps looping until the stack is exhausted, since internal modifications keep calling the frontend's modify hook rather than the actual one that needs to be called. I don't recall testing it this way during development, but I don't see any reason to prevent it from working this way. Feel free to look at it, I probably won't have time to do it soon. Thanks, p.

1 0

Re: (ITS#7249) slapd segfault with memberof overlay on frontend db
by jvcelak＠redhat.com 25 Apr '12

25 Apr '12

Hello, > Enabling memberof overlay on frontend database causes slapd to > SEGFAULT due to stack overflow when renaming an entry. please, can somebody confirm that this configuration is wrong and that it should not be allowed? Or that this configuration is correct and the "overlay effect" should be inherited by backend database? I would like to help with fixing this, but I have no idea what is the expected behavior. Documentation says nothing about this. Jan

1 0

Re: (ITS#7258) Possible suffixmassage and syncrepl bug
by masarati＠aero.polimi.it 25 Apr '12

25 Apr '12

> Full_Name: Jon C. Kidder > Version: 2.4.30 > OS: rhel 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (167.239.77.30) > > > Gentlemen, I need some help. I've been working on a problem for a couple > of > weeks and I can't seem to find a solution. I have encountered at least one > bug > and possibly two. > > I am building a new directory for my company using OpenLDAP 2.4.30 and BDB > 5.3.15. I am trying to pull in records from a foreign directory and map > them > into my directory. All of the foreign records are proxied into 3 child > nodes of > my directory. I am able to do this successfully using back-ldif and > overlay-rwm. > The problem I am encountering is that I have setup multi-master > replication of > the entire new directory with a filter to exclude the proxied nodes > because each > of my directory servers independently proxies those nodes. When the > replication > starts syncrepl causes an ABEND on every node that attempts replication. I > have > discovered that the ABEND occurs because my filter does not work and > syncrepl is > trying to replicate the proxied records. I have also discovered that my > filter > is not working because rwm-suffixmassage does not appear to be rewriting > the > entryDN of my proxied records. If my entryDN problem is configuration > related I > could use some help figuring it out. I am still submitting this as a bug > because > even if the entryDN problem is not a bug syncrepl should detect the > replication/proxy conflict and abort the replication gracefully rather > than > ABEND the directory server. > > I love the work the OpenLDAP team is doing. I am a very strong advocate of > open > source products at my company. I would love to take a deep dive into the > code > and resolve this issue myself but unfortunately can not. I am an > administrator/operator by day and a single parent of 6 year old triplet > boys by > night. I am not afforded as many opportunities to exercise my development > skills > as I would like. Any assistance the OpenLDAP team can render would be > greatly > appreciated. I can try to build a complete test suite that will allow > recreation/testing of these 2 issues if needed. > > Sample ldapsearch result showing inconsistent DN rewrite (DN is rewritten > but > entryDN is not): > > /appl/openldap/bin/ldapsearch -x -D "cn=Directory > Manager,dc=Global,dc=aep,dc=com" -y $HOME/buildpwd -s sub -b > 'dc=Global,dc=aep,dc=com' '(cn=s012235)' '+' > # extended LDIF > # > # LDAPv3 > # base <dc=Global,dc=aep,dc=com> with scope subtree > # filter: (cn=s012235) > # requesting: + > # > > # s012235, Information Technology, AD_Corp, Employees, Users, > Global.aep.com > dn: cn=s012235,ou=Information > Technology,ou=AD_Corp,ou=Employees,ou=Users,dc=G > lobal,dc=aep,dc=com > entryDN: cn=s012235,ou=Information Technology,ou=LOB > Users,dc=corp,dc=aepsc,dc > =com > subschemaSubentry: cn=Subschema slapo-rwm(5) explicitly skips entryDN (and removes it from attributes returned by searches) because entryDN is (re-)added by the frontend. Of course both events appear to be erroneous; unless they result from a misconfiguration (and in any case for the sigsegv) they need to be addressed. I suggest you create a minimal setup that shows the problem (either one for each problem, or one for both) and upload it according to instructions here <http://www.openldap.org/devel/contributing.html#submitting>. Attaching it to an email is not an option because the ITS does not handle attachments well. p.

1 0

Re: (ITS#7260) problem with 2.4.30 to 2.4.31 upgrade
by masarati＠aero.polimi.it 24 Apr '12

24 Apr '12

> Full_Name: Andrzej Tobola > Version: 2.4.31 > OS: FreeBSD 9.0 amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.29.146.94) > > > I run slapd from a long time on FreeBSD stable amd64 and it is started > with > args: > > slapd -4 -h "ldapi://%2fvar%2frun%2fslapd.socket ldap://localhost/ > ldap://ldap2/ ldaps://ldap2/" -u ldap -g ldap > > After upgrade from 2.4.30 to 2.4.31 my server can't start: > slapd[29221]: read_config: no serverID / URL match found. Check slapd -h > arguments. > Nothing was change in en environment - only ldap was upgraded. > > After backing-off only this one commit to bconfg.c: > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=b4d4… > > all is working again. > Any clue ? > and IHMO this message shod be more informative for casual user. This message (and the related commit) adds a sanity check (ITS#7200). Apparently, your system is (and was) misconfigured. So I'd try to understand what the misconfiguration is, rather than backing up to a version without sanity check. This discussion belongs to openldap-technical(a)openldap.org rather than to the ITS. You showed the value of -h, can you show your serverID / olcServerID? p.

1 0

(ITS#7260) problem with 2.4.30 to 2.4.31 upgrade
by ato＠iem.pw.edu.pl 24 Apr '12

24 Apr '12

Full_Name: Andrzej Tobola Version: 2.4.31 OS: FreeBSD 9.0 amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.29.146.94) I run slapd from a long time on FreeBSD stable amd64 and it is started with args: slapd -4 -h "ldapi://%2fvar%2frun%2fslapd.socket ldap://localhost/ ldap://ldap2/ ldaps://ldap2/" -u ldap -g ldap After upgrade from 2.4.30 to 2.4.31 my server can't start: slapd[29221]: read_config: no serverID / URL match found. Check slapd -h arguments. Nothing was change in en environment - only ldap was upgraded. After backing-off only this one commit to bconfg.c: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=b4d4… all is working again. Any clue ? and IHMO this message shod be more informative for casual user.

1 0

Re: (ITS#7177) [PATCH] various manpage fixes
by jvcelak＠redhat.com 24 Apr '12

24 Apr '12

Hello, this was not fixed entirely. > ftp://ftp.openldap.org/incoming/jvcelak-20120223-0002-man-add-SASL_NOCANON-… SASL_NOCANON option is still missing in ldap.conf(5). Jan

1 0

Re: (ITS#7259) Ppolicy count bytes not characters
by michael＠stroeder.com 24 Apr '12

24 Apr '12

This is a cryptographically signed message in MIME format. --------------ms090008060908020301080505 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jiri.Netolicky(a)cdt.cz wrote: > Slapo-ppolicy manual page says: > pwdMinLength: ..this attribute contains the minimum number of charact= ers that > will be accepted in a password >=20 > But it seems that the code not chcount number of characters but number = of bytes. I guess this is because attribute type userPassword is declared with LDAP= syntax OctetString. Not sure whether there's a clean way to determine the= number of Unicode code points. Ciao, Michael. --------------ms090008060908020301080505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyNDA3MDc0OFowIwYJKoZIhvcNAQkEMRYE FOYp7BL4H+GvaSFu+gwu4Sv9mOnZMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEA6EjfLNSrrqaW1xIErl+IKpDl7AXerZu3jQj4lZPuP6neHv8WWMHnQ1RaRx7hEvzp1kzt dFcq2da/fZdDBu2KgvAD+eqomHomtHwJPXWfyuhnzdhYCCcW2VG+AzMWyh5q0ea8QsoAPRzG cpF0zcVu6AC+PzT+gS/IwKZyLR3lrynILYLks9W8ponF2Am9clbWmaJx/3WES0NXgUf7s43U SWULCIxH2cXrMuZk5kwWbqx6QwmRGQFUR+8o7eV1WB+IkB6PkI1+027gtdzmxLLlFKQXSXkk IDlmfdYakh3iEMkm8o8IQ3AsXabFrvxoM3wRB/J0leJLob4E3CIYYF0WEQAAAAAAAA== --------------ms090008060908020301080505--

1 0

(ITS#7259) Ppolicy count bytes not characters
by Jiri.Netolicky＠cdt.cz 23 Apr '12

23 Apr '12

Full_Name: Jiří Netolický Version: 2.4.30 OS: Linux - Gentoo URL: Submission from: (NULL) (2001:1a48:5:3::3) Slapo-ppolicy manual page says: pwdMinLength: ..this attribute contains the minimum number of characters that will be accepted in a password But it seems that the code not chcount number of characters but number of bytes. I set pwdMinLength to value 8. When I used password with only ascii characters everything works great. But when I use a two-byte UTF-8 character in password it count this one character as two. For example when I use password "babička" which is 7 characters length but the UTF-8 representation is 8 bytes (0x62 0x61 0x62 0x69 0xc4 0x8d 0x6b 0x61). This password is accepted although the policy forces 8 characters min.length. I think the only soulution is correct the manual page the pwdMinLength count bytes not characters. Because userPassword attribute is binary, in my opinion we should not assume that the password encoding is UTF8 to easy count characters.

1 0

(ITS#7258) Possible suffixmassage and syncrepl bug
by jckidder＠aep.com 23 Apr '12

23 Apr '12

Full_Name: Jon C. Kidder Version: 2.4.30 OS: rhel 5.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (167.239.77.30) Gentlemen, I need some help. I've been working on a problem for a couple of weeks and I can't seem to find a solution. I have encountered at least one bug and possibly two. I am building a new directory for my company using OpenLDAP 2.4.30 and BDB 5.3.15. I am trying to pull in records from a foreign directory and map them into my directory. All of the foreign records are proxied into 3 child nodes of my directory. I am able to do this successfully using back-ldif and overlay-rwm. The problem I am encountering is that I have setup multi-master replication of the entire new directory with a filter to exclude the proxied nodes because each of my directory servers independently proxies those nodes. When the replication starts syncrepl causes an ABEND on every node that attempts replication. I have discovered that the ABEND occurs because my filter does not work and syncrepl is trying to replicate the proxied records. I have also discovered that my filter is not working because rwm-suffixmassage does not appear to be rewriting the entryDN of my proxied records. If my entryDN problem is configuration related I could use some help figuring it out. I am still submitting this as a bug because even if the entryDN problem is not a bug syncrepl should detect the replication/proxy conflict and abort the replication gracefully rather than ABEND the directory server. I love the work the OpenLDAP team is doing. I am a very strong advocate of open source products at my company. I would love to take a deep dive into the code and resolve this issue myself but unfortunately can not. I am an administrator/operator by day and a single parent of 6 year old triplet boys by night. I am not afforded as many opportunities to exercise my development skills as I would like. Any assistance the OpenLDAP team can render would be greatly appreciated. I can try to build a complete test suite that will allow recreation/testing of these 2 issues if needed. Sample ldapsearch result showing inconsistent DN rewrite (DN is rewritten but entryDN is not): /appl/openldap/bin/ldapsearch -x -D "cn=Directory Manager,dc=Global,dc=aep,dc=com" -y $HOME/buildpwd -s sub -b 'dc=Global,dc=aep,dc=com' '(cn=s012235)' '+' # extended LDIF # # LDAPv3 # base <dc=Global,dc=aep,dc=com> with scope subtree # filter: (cn=s012235) # requesting: + # # s012235, Information Technology, AD_Corp, Employees, Users, Global.aep.com dn: cn=s012235,ou=Information Technology,ou=AD_Corp,ou=Employees,ou=Users,dc=G lobal,dc=aep,dc=com entryDN: cn=s012235,ou=Information Technology,ou=LOB Users,dc=corp,dc=aepsc,dc =com subschemaSubentry: cn=Subschema # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Log excerpt showing syncrepl abend: 4f9165ba Config: ** successfully added syncrepl rid=401 "ldap://ctldapcop1.aepsc.com:33389" 4f9165ba Config: ** successfully added syncrepl rid=402 "ldap://ctldaprop1.aepsc.com:33389" 4f9165ba syncprov_matchops: skipping original sid 001 4f9165ba slap_graduate_commit_csn: removing 0x1b4a94f0 20120420133346.749007Z#000000#001#000000 4f9165ba syncrepl_entry: rid=001 be_modify olcDatabase={4}bdb,cn=config (0) 4f9165ba slap_queue_csn: queing 0x1b4b3e50 20120420133346.749007Z#000000#001#000000 4f9165ba slap_graduate_commit_csn: removing 0x1b4a8cd0 20120420133346.749007Z#000000#001#000000 4f9165ba conn=1005 fd=23 ACCEPT from IP=10.92.123.82:45250 (IP=10.21.206.102:33389) 4f9165ba conn=1005 op=0 BIND dn="cn=syncuser,ou=automatons,ou=users,dc=global,dc=aep,dc=com" method=128 4f9165ba conn=1005 op=0 RESULT tag=97 err=49 text= 4f9165ba conn=1005 op=1 UNBIND 4f9165ba conn=1005 fd=23 closed 4f9165ba syncrepl_message_to_entry: rid=401 DN: dc=Global,dc=aep,dc=com, UUID: 750d95da-e7bb-483a-853b-9552466e3d0d 4f9165ba syncrepl_entry: rid=401 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 4f9165ba syncrepl_entry: rid=401 inserted UUID 750d95da-e7bb-483a-853b-9552466e3d0d *** glibc detected *** /appl/openldap/libexec/slapd: free(): invalid pointer: 0x000000001b77f8a7 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3c82c7245f] /lib64/libc.so.6(cfree+0x4b)[0x3c82c728bb] /appl/openldap/libexec/slapd[0x5aa324] /appl/openldap/libexec/slapd[0x46f36c] /appl/openldap/libexec/slapd[0x43aca6] /appl/openldap/libexec/slapd[0x4230fe] /appl/openldap/libexec/slapd[0x560550] /appl/openldap/libexec/slapd[0x560632] /appl/openldap/libexec/slapd[0x55ce73] /appl/openldap/libexec/slapd[0x483a7b] /appl/openldap/libexec/slapd[0x483f9a] /appl/openldap/libexec/slapd[0x4840ce] /appl/openldap/libexec/slapd[0x480bd8] /appl/openldap/libexec/slapd[0x48227f] /appl/openldap/libexec/slapd[0x483a7b] /appl/openldap/libexec/slapd[0x483f9a] /appl/openldap/libexec/slapd[0x4840ce] /appl/openldap/libexec/slapd[0x47a44a] /appl/openldap/libexec/slapd[0x480667] /appl/openldap/libexec/slapd[0x580b20] /lib64/libpthread.so.0[0x3c8340673d] /lib64/libc.so.6(clone+0x6d)[0x3c82cd44bd] ======= Memory map: ======== 00400000-007ac000 r-xp 00000000 fd:00 933895 /appl/openldap/libexec/slapd 009ab000-009ca000 rw-p 003ab000 fd:00 933895 /appl/openldap/libexec/slapd 009ca000-00a73000 rw-p 009ca000 00:00 0 1b3e3000-1b8bb000 rw-p 1b3e3000 00:00 0 [heap] 41be1000-41be2000 ---p 41be1000 00:00 0 41be2000-423e2000 rw-p 41be2000 00:00 0 423e2000-423e3000 ---p 423e2000 00:00 0 423e3000-42be3000 rw-p 423e3000 00:00 0 42be3000-42be4000 ---p 42be3000 00:00 0 42be4000-433e4000 rw-p 42be4000 00:00 0 3c82800000-3c8281c000 r-xp 00000000 fd:fa 65572 /lib64/ld-2.5.so 3c82a1c000-3c82a1d000 r--p 0001c000 fd:fa 65572 /lib64/ld-2.5.so 3c82a1d000-3c82a1e000 rw-p 0001d000 fd:fa 65572 /lib64/ld-2.5.so 3c82c00000-3c82d4e000 r-xp 00000000 fd:fa 65579 /lib64/libc-2.5.so 3c82d4e000-3c82f4e000 ---p 0014e000 fd:fa 65579 /lib64/libc-2.5.so 3c82f4e000-3c82f52000 r--p 0014e000 fd:fa 65579 /lib64/libc-2.5.so 3c82f52000-3c82f53000 rw-p 00152000 fd:fa 65579 /lib64/libc-2.5.so 3c82f53000-3c82f58000 rw-p 3c82f53000 00:00 0 3c83000000-3c83002000 r-xp 00000000 fd:fa 65632 /lib64/libdl-2.5.so 3c83002000-3c83202000 ---p 00002000 fd:fa 65632 /lib64/libdl-2.5.so 3c83202000-3c83203000 r--p 00002000 fd:fa 65632 /lib64/libdl-2.5.so 3c83203000-3c83204000 rw-p 00003000 fd:fa 65632 /lib64/libdl-2.5.so 3c83400000-3c83416000 r-xp 00000000 fd:fa 65600 /lib64/libpthread-2.5.so 3c83416000-3c83615000 ---p 00016000 fd:fa 65600 /lib64/libpthread-2.5.so 3c83615000-3c83616000 r--p 00015000 fd:fa 65600 /lib64/libpthread-2.5.so 3c83616000-3c83617000 rw-p 00016000 fd:fa 65600 /lib64/libpthread-2.5.so 3c83617000-3c8361b000 rw-p 3c83617000 00:00 0 3c84c00000-3c84c04000 r-xp 00000000 fd:fa 65883 /lib64/libuuid.so.1.2 3c84c04000-3c84e03000 ---p 00004000 fd:fa 65883 /lib64/libuuid.so.1.2 3c84e03000-3c84e04000 rw-p 00003000 fd:fa 65883 /lib64/libuuid.so.1.2 3c8ea00000-3c8ea11000 r-xp 00000000 fd:fa 65856 /lib64/libresolv-2.5.so 3c8ea11000-3c8ec11000 ---p 00011000 fd:fa 65856 /lib64/libresolv-2.5.so 3c8ec11000-3c8ec12000 r--p 00011000 fd:fa 65856 /lib64/libresolv-2.5.so 3c8ec12000-3c8ec13000 rw-p 00012000 fd:fa 65856 /lib64/libresolv-2.5.so 3c8ec130Aborted Relevant configuration ldifs: Database Build: dn: olcDatabase={1}ldap,cn=configolcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="XXXXXXXXXXXXXXXXXXXXX" credentials="XXXXXXXX" keepalive=0:0:0olcDbChaseReferrals: TRUEolcLastMod: FALSEolcAddContentAcl: FALSEolcDatabase: {1}ldapolcSuffix: ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=comolcDbConnectionPoolMax: 16olcDbUseTemporaryConn: FALSEolcDbTFSupport: noolcDbCancel: abandonolcDbProtocolVersion: 3olcReadOnly: FALSEolcSubordinate: TRUEolcDbStartTLS: none starttls=noolcDbNoRefs: FALSEolcDbProxyWhoAmI: FALSEolcMaxDerefDepth: 15olcDbSingleConn: FALSEolcDbNoUndefFilter: FALSEolcDbURI: "ldap://msad-corp.aepsc.com"olcMonitoring: FALSEolcSyncUseSubentry: FALSEolcDbRebindAsUser: TRUEobjectClass: olcDatabaseConfigobjectClass: olcLDAPConfigdn: olcOverlay=rwm,olcDatabase={1}ldap,cn=configolcRwmNormalizeMapped: FALSEobjectClass: olcOverlayConfigobjectClass: olcRwmConfigolcRwmMap: objectclass inetOrgPerson userolcRwmMap: objectclass organizationalUnit *olcRwmMap: attribute cn *olcRwmMap: attribute sn *olcRwmMap: attribute telephoneNumber otherTelephoneolcRwmMap: attribute description *olcRwmMap: attribute title *olcRwmMap: attribute postalCode *olcRwmMap: attribute postalAddress streetAddressolcRwmMap: attribute physicalDeliveryOfficeName *olcRwmMap: attribute st *olcRwmMap: attribute l *olcRwmMap: attribute departmentNumber aepDepartmentIDolcRwmMap: attribute displayName *olcRwmMap: attribute employeeNumber employeeIDolcRwmMap: attribute givenName *olcRwmMap: attribute initials *olcRwmMap: attribute mail mailolcRwmMap: attribute manager aepManagerIDolcRwmMap: attribute mobile *olcRwmMap: attribute o aepFBUDescriptionolcRwmMap: attribute roomNumber aepFloorolcRwmMap: attribute uid sAMAccountNameolcRwmMap: attribute ou aepBBUDescriptionolcRwmMap: attribute * olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com" "ou=LOB Users,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=com" "ou=Security Groups,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" "ou=Service Accounts,dc=corp,dc=aepsc,dc=com"olcRwmTFSupport: falseolcOverlay: rwmdn: olcDatabase={2}ldap,cn=configolcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="XXXXXXXXXXXXXXXXXXXXX" credentials="XXXXXXXX" keepalive=0:0:0olcDbChaseReferrals: TRUEolcLastMod: FALSEolcAddContentAcl: FALSEolcDatabase: {2}ldapolcSuffix: ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=comolcDbConnectionPoolMax: 16olcDbUseTemporaryConn: FALSEolcDbTFSupport: noolcDbCancel: abandonolcDbProtocolVersion: 3olcReadOnly: FALSEolcSubordinate: TRUEolcDbStartTLS: none starttls=noolcDbNoRefs: FALSEolcDbProxyWhoAmI: FALSEolcMaxDerefDepth: 15olcDbSingleConn: FALSEolcDbNoUndefFilter: FALSEolcDbURI: "ldap://msad-corp.aepsc.com"olcMonitoring: FALSEolcSyncUseSubentry: FALSEolcDbRebindAsUser: TRUEobjectClass: olcDatabaseConfigobjectClass: olcLDAPConfigdn: olcOverlay=rwm,olcDatabase={2}ldap,cn=configolcRwmNormalizeMapped: FALSEobjectClass: olcOverlayConfigobjectClass: olcRwmConfigolcRwmMap: objectclass groupOfUniqueNames groupolcRwmMap: objectclass organizationalUnit *olcRwmMap: attribute cn *olcRwmMap: attribute description *olcRwmMap: attribute uniqueMember memberolcRwmMap: attribute o *olcRwmMap: attribute ou *olcRwmMap: attribute * olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com" "ou=LOB Users,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=com" "ou=Security Groups,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" "ou=Service Accounts,dc=corp,dc=aepsc,dc=com"olcRwmTFSupport: falseolcOverlay: rwmdn: olcDatabase={3}ldap,cn=configolcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindmethod=simple timeout=0 network-timeout=0 binddn="XXXXXXXXXXXXXXXXXXXXX" credentials="XXXXXXXX" keepalive=0:0:0olcDbChaseReferrals: TRUEolcLastMod: FALSEolcAddContentAcl: FALSEolcDatabase: {3}ldapolcSuffix: ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=comolcDbConnectionPoolMax: 16olcDbUseTemporaryConn: FALSEolcDbTFSupport: noolcDbCancel: abandonolcDbProtocolVersion: 3olcReadOnly: FALSEolcSubordinate: TRUEolcDbStartTLS: none starttls=noolcDbNoRefs: FALSEolcDbProxyWhoAmI: FALSEolcMaxDerefDepth: 15olcDbSingleConn: FALSEolcDbNoUndefFilter: FALSEolcDbURI: "ldap://msad-corp.aepsc.com"olcMonitoring: FALSEolcSyncUseSubentry: FALSEolcDbRebindAsUser: TRUEobjectClass: olcDatabaseConfigobjectClass: olcLDAPConfigdn: olcOverlay=rwm,olcDatabase={3}ldap,cn=configolcRwmNormalizeMapped: FALSEobjectClass: olcOverlayConfigobjectClass: olcRwmConfigolcRwmMap: objectclass inetOrgPerson userolcRwmMap: objectclass organizationalUnit *olcRwmMap: attribute cn *olcRwmMap: attribute sn *olcRwmMap: attribute telephoneNumber otherTelephoneolcRwmMap: attribute description *olcRwmMap: attribute title *olcRwmMap: attribute postalCode *olcRwmMap: attribute postalAddress streetAddressolcRwmMap: attribute physicalDeliveryOfficeName *olcRwmMap: attribute st *olcRwmMap: attribute l *olcRwmMap: attribute departmentNumber aepDepartmentIDolcRwmMap: attribute displayName *olcRwmMap: attribute employeeNumber employeeIDolcRwmMap: attribute givenName *olcRwmMap: attribute initials *olcRwmMap: attribute mail mailolcRwmMap: attribute manager aepManagerIDolcRwmMap: attribute mobile *olcRwmMap: attribute o aepFBUDescriptionolcRwmMap: attribute roomNumber aepFloorolcRwmMap: attribute uid sAMAccountNameolcRwmMap: attribute ou aepBBUDescriptionolcRwmMap: attribute * olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com" "ou=LOB Users,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=com" "ou=Security Groups,dc=corp,dc=aepsc,dc=com"olcRwmRewrite: rwm-suffixmassage "ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com" "ou=Service Accounts,dc=corp,dc=aepsc,dc=com"olcRwmTFSupport: falseolcOverlay: rwmdn: olcDatabase={4}bdb,cn=configolcDbSearchStack: 16olcDbIDLcacheSize: 0olcDbDNcacheSize: 0olcLastMod: TRUEolcAddContentAcl: FALSEolcDatabase: {4}bdbolcSuffix: dc=Global,dc=aep,dc=comolcDbDirtyRead: FALSEolcDbCacheSize: 1000olcReadOnly: FALSEolcDbCacheFree: 1olcDbDirectory: /appl/openldap/var/openldap-data/GlobalolcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxlPTI+olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhlaXIgLXEgb3B0aW9uKS4golcMaxDerefDepth: 15olcDbMode: 0600olcDbIndex: objectClass eqolcDbIndex: entryUUID eqolcDbIndex: entryCSN eqolcDbIndex: cn pres,eq,approx,subolcDbIndex: uid pres,eq,approx,subolcDbIndex: sn pres,eq,approx,subolcMonitoring: TRUEolcDbNoSync: FALSEolcSyncUseSubentry: FALSEolcRootPW: XXXXXXXXXXXXobjectClass: olcDatabaseConfigobjectClass: olcBdbConfigolcDbShmKey: 0olcDbLinearIndex: FALSEolcRootDN: cn=Directory Manager,dc=Global,dc=aep,dc=comdn: olcOverlay=glue,olcDatabase={4}bdb,cn=configchangetype: addobjectClass: olcOverlayConfigolcOverlay: glue Establish replication: dn: olcOverlay=syncprov,olcDatabase={4}bdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcSpCheckpoint: 10 1 olcSpReloadHint: TRUE olcOverlay: syncprov dn: olcDatabase={4}bdb,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: rid=401 provider=ldap://ctldapcop1.aepsc.com:33389 binddn="cn=syncuser,ou=Automatons,ou=Users,dc=global,dc=aep,dc=com" bindmethod=simple credentials="XXXXXXXXXXX" searchbase="dc=global,dc=aep,dc=com" filter="(&(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com))(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com))(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=com)))" type=refreshAndPersist retry="5 5 300 +" timeout=1 olcSyncrepl: rid=402 provider=ldap://ctldaprop1.aepsc.com:33389 binddn="cn=syncuser,ou=Automatons,ou=Users,dc=global,dc=aep,dc=com" bindmethod=simple credentials="XXXXXXXXXXX" searchbase="dc=global,dc=aep,dc=com" filter="(&(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Employees,ou=Users,dc=Global,dc=aep,dc=com))(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Automatons,ou=Users,dc=Global,dc=aep,dc=com))(!(entryDN:dnSubtreeMatch:=ou=AD_Corp,ou=Groups,dc=Global,dc=aep,dc=com)))" type=refreshAndPersist retry="5 5 300 +" timeout=1 - replace: olcMirrorMode olcMirrorMode: TRUE

1 0

Re: (ITS#7212) slapmodify support for back-config
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/23/2012 06:06 PM, ondrej.kuznik(a)acision.com wrote: > On 04/13/2012 04:00 PM, ondrej.kuznik(a)acision.com wrote: >> On 03/20/2012 11:11 AM, ondrej.kuznik(a)acision.com wrote: >>> For slapmodify to be usable on a database, that database needs >>> to implement the bi_tool_dn2id_get and bi_tool_entry_modify >>> functions, which is not the case of the back-config. I've put >>> together a minimal (and maybe too naive) implementation of >>> these for back-config and back-ldif at the above link. > >> Ok, nevermind for now, the implementation was too naive and >> would break some other things (the slapadd in test005). > > I prepared an updated version of the patches below, patches > 1-4,8-12 add this support and introduce a new testcase, temporarily > assigned to the currently free position 007 which will ignore > errors, if encountered during slapmodify invocation. > > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… I > forgot to include the IPR Notice for the above patch series: The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. - -- Ondrej Kuznik A: Because it destroys the flow of the conversation. Q: Why is it bad? A: No, it's bad. Q: Should I top post in replies to mailing lists or on Usenet? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Vfs4ACgkQ9GWxeeH+cXvwDgCeNPRxiAxBZgzX0XDeToxPz71S YTcAoIiwPVXu5zg0TG+o/tdIFlKqd/fO =thvs -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

(ITS#7257) slapdelete hooks
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… Submission from: (NULL) (62.168.56.1) To support deletes in tool mode, I tried drafting a new hook for backends to expose, and implemented that for back-ldif. That, and slapmodify support for this operation are included in patches 5-7 in the above patch series. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#7212) slapmodify support for back-config
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/13/2012 04:00 PM, ondrej.kuznik(a)acision.com wrote: > On 03/20/2012 11:11 AM, ondrej.kuznik(a)acision.com wrote: >> For slapmodify to be usable on a database, that database needs >> to implement the bi_tool_dn2id_get and bi_tool_entry_modify >> functions, which is not the case of the back-config. I've put >> together a minimal (and maybe too naive) implementation of these >> for back-config and back-ldif at the above link. > > Ok, nevermind for now, the implementation was too naive and would > break some other things (the slapadd in test005). I prepared an updated version of the patches below, patches 1-4,8-12 add this support and introduce a new testcase, temporarily assigned to the currently free position 007 which will ignore errors, if encountered during slapmodify invocation. ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VfbEACgkQ9GWxeeH+cXsfNgCfcbPewsqwd5kSW3tHCzqCBfn1 G7gAn3mRB0UoG50F1ezbBLSAzsFDRIhX =J2sk -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

(ITS#7256) back-mdb segfaults trying to free an entry in tool mode
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… Submission from: (NULL) (62.168.56.1) I am not entirely sure that I'm doing everything right, but in slapmodify the fake operation has to set op->o_hdr for several functions to use, but has no intention of setting o_tmpmfuncs. This makes slapd segfault when it is used with back-mdb as it only checks whether o_hdr is set. The last patch in the series at the above URL fixes this, but maybe some other change is more appropriate. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision 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#7255) back-mdb hangs during mdb_tool_entry_modify
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… Submission from: (NULL) (62.168.56.1) When calling mdb_tool_entry_modify, a new transaction is being set up and this hangs the process on a mutex that the thread already holds. For a possible patch see the last patch in the series at the above URL. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision 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#7254) back-bdb cursor is sometimes not available in tool mode
by ondrej.kuznik＠acision.com 23 Apr '12

23 Apr '12

Full_Name: Ondrej Kuznik Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… Submission from: (NULL) (62.168.56.1) bdb_tool_entry_modify unsets the cursor variable, however bdb_tool_entry_get_int expects it to be there whenever it is run. For a possible patch see the last patch in the series at the above URL. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Acision. Acision has not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik am authorized by Acision, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Acision Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 9:17 AM, michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms080904050007060500070608 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > Kurt(a)OpenLDAP.org wrote: >> Client's really should, in general, just do their own sorting over the >> result set, especially for sorting entries for presentation purposes. > > People are always asking for paged displaying of address book data sorted= > by > name. If you have large result sets that's a problem at the client's side= > =2E Most of the server side paging is done stateless, which means that if a client relies on it, it's going to have data consistency problems (in the face of possible data or other changes). If you do it stateful on the server side to ensure data consistency, you kill your server. Most clients can easily deal with large data sets, even mobile devices. In many bandwidth constrained environments, roundtrips are even more problematic than the bandwidth issues. So dealing with presentation issues is often best for everyone. But the issue of this thread is sorting... (which often is used with paging). Code point sorting, as you get on the server side (at least with standard ordering rules), ain't what most clients actually want. And even if you have a desirable to the client ordering rule, the handling of multiple valued attributes called for in RFC 2891 is likely not what the client wants. So you end up needing the dup-entry control as well, and that adds more bandwidth and, if paging, more roundtrips. My guidance is to have client deal with presentation issues, which is what most sorting boils down to. > > But my feeling here is also ambivalent. I always tell people to narrow th= > e > search because wading through large result sets by clicking through pages= > is > not very efficient for the user himself anyway. Same problem with users > constantly asking for tree browsing. A horrible inefficient UI tool in la= > rger > deployments... > >> The only case where I see this control being useful is, in conjunction = > with >> the paged results control, for asking for the entry with the lowest/hig= > hest >> single-valued serial number (or like) attributes. > > For suggesting the next free unique number in an input form? Or for just assigning the next free serial number in decreasing/increasing order. (I rather avoid them, but some times you cannot avoid them (due to not owning the requirements). > > Ciao, Michael. > > > --------------ms080904050007060500070608 > Content-Type: application/pkcs7-signature; name="smime.p7s" > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="smime.p7s" > Content-Description: S/MIME Cryptographic Signature > > MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC > BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w > HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu > ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx > MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj > MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA > A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd > NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV > hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ > 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ > NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH > AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy > IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl > cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB > BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov > L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq > hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj > /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd > dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH > SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ > AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 > TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT > QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ > R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv > n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy > D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB > gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx > IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 > cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq > hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyMDE2MTY1OVowIwYJKoZIhvcNAQkEMRYE > FLqReNhqM0dMvax8KwzbLzq2PziaMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG > CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq > hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc > BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n > IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG > CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 > Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh > MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE > ggEAyVNeNLp1NZXO0tamjjP+hri2OEvcaw5ik9BhpeqH8Vu88UsTd33c5Md3tdYNsXF6D9ud > V8+dFYOSU9E7CTHdfdLojAW3HsBoQYuMvJWq74SkYOoShn8DQ1rG4PGIdOW0ZiUvZTzT+sRY > UEY1Yst/iUG+N5LTaM5IMUoH/GMcgab2pWUSLkF+YkNG05XLHkg9tdIj51xCRP9Ic4kfDQos > zD+TsKM/39xyEBtMMGjBnPUxGurKIdvltS95Z1bZ15L4PApHKMWZBIfizbO8KrFUEA8YT8IQ > +grclVEKMgwybt9K2m3dQ1Vn3niIioysIJED9CVoK00ylvSkpC8fsjMtfAAAAAAAAA== > --------------ms080904050007060500070608-- > >

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by michael＠stroeder.com 20 Apr '12

20 Apr '12

This is a cryptographically signed message in MIME format. --------------ms080904050007060500070608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Kurt(a)OpenLDAP.org wrote: > Client's really should, in general, just do their own sorting over the > result set, especially for sorting entries for presentation purposes. People are always asking for paged displaying of address book data sorted= by name. If you have large result sets that's a problem at the client's side= =2E But my feeling here is also ambivalent. I always tell people to narrow th= e search because wading through large result sets by clicking through pages= is not very efficient for the user himself anyway. Same problem with users constantly asking for tree browsing. A horrible inefficient UI tool in la= rger deployments... > The only case where I see this control being useful is, in conjunction = with > the paged results control, for asking for the entry with the lowest/hig= hest > single-valued serial number (or like) attributes. For suggesting the next free unique number in an input form? Ciao, Michael. --------------ms080904050007060500070608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQyMDE2MTY1OVowIwYJKoZIhvcNAQkEMRYE FLqReNhqM0dMvax8KwzbLzq2PziaMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAyVNeNLp1NZXO0tamjjP+hri2OEvcaw5ik9BhpeqH8Vu88UsTd33c5Md3tdYNsXF6D9ud V8+dFYOSU9E7CTHdfdLojAW3HsBoQYuMvJWq74SkYOoShn8DQ1rG4PGIdOW0ZiUvZTzT+sRY UEY1Yst/iUG+N5LTaM5IMUoH/GMcgab2pWUSLkF+YkNG05XLHkg9tdIj51xCRP9Ic4kfDQos zD+TsKM/39xyEBtMMGjBnPUxGurKIdvltS95Z1bZ15L4PApHKMWZBIfizbO8KrFUEA8YT8IQ +grclVEKMgwybt9K2m3dQ1Vn3niIioysIJED9CVoK00ylvSkpC8fsjMtfAAAAAAAAA== --------------ms080904050007060500070608--

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by clem.oudot＠gmail.com 20 Apr '12

20 Apr '12

Le 20 avril 2012 18:00, <Kurt(a)openldap.org> a écrit : > > On Apr 20, 2012, at 8:25 AM, kurt(a)openldap.org wrote: > >>> which use the sss >>> control on standards attributes like cn or sn. >> >> maybe you should file a bug report with them. > > and I should note that I consider most client use of this control, itself, to be a bug. Ok Kurt, I let you explain that to Microsoft and IBM ;) By the way, I understand your arguments, I just wanted to notify the OpenLDAP team of this problem, because that can force customers to use another LDAP directory in order to stay compatible with such (buggy) softwares. Clément.

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 8:25 AM, kurt(a)openldap.org wrote: >> which use the sss >> control on standards attributes like cn or sn. > > maybe you should file a bug report with them. and I should note that I consider most client use of this control, itself, to be a bug. Client's really should, in general, just do their own sorting over the result set, especially for sorting entries for presentation purposes. The only case where I see this control being useful is, in conjunction with the paged results control, for asking for the entry with the lowest/highest single-valued serial number (or like) attributes. -- Kurt

1 0

Re: ITS#7239: testbed
by h.b.furuseth＠usit.uio.no 20 Apr '12

20 Apr '12

We seem to be two guys discussing work we're not volunteering to do anytime soon, but anyway... On Fri, 20 Apr 2012 07:22:32 GMT, masarati(a)aero.polimi.it wrote: > On 04/19/2012 11:20 PM, Hallvard Breien Furuseth wrote: >> No, I meant the opposite: The macroization is done. It could mostly >> be >> scripted and makes no semantic change unless #ifdef(SlapReply >> debug), >> which is what the macros were for. > > Right. Actually one simpler but uglier macro is enough, without touching non-internal calls: /* * Do ACT with OP->o_internal set. * Example: WITH_INTERNAL_OP( op, rc = op->o_bd->be_add( op, rs )); */ #define WITH_INTERNAL_OP(op, act) do { \ int *const wio_intern_ = &(op)->o_internal; \ int const wio_save_ = (*wio_intern_)++; \ act; \ (*wio_intern_)--; \ assert(*wio_intern_ == wio_save_); /* Keep this while testing */ \ } while (0) Not my preference, but at least it's an option. >> Figuring out which ops to tag as internal does, as you say, require >> review and testing. And one extra arg to the macros. > > How do you suggest to proceed? If I were doing it, I'd play in a separate branch while getting a feel for how it'll end up. Never mind the exact API, it can be rewritten at this stage if it's unsufficient or overkill. Then give master whatever framework is neeed to allow the rest of the job to be done some operation calls at the time, without needing a monster commit to develop and review. Technically, if not just the wrapper macro above: > I believe using different macros, e.g. > slap_bi_op_internal, slap_be_op_internal and SLAP_OP_INTERNAL is > clearer > than having an additional 0/1 parameter. OTOH, adding further > parameters in the future would be probably easier if we extend your > macros. Fair enough. 0/1 could be enum constants, but that's more verbose. And it's just 6 macros for now: My 3 old plus 3 new. /* In proto-slap.h: */ #define slap_bi_op( bi,which,op,rs) ((&(bi)->bi_op_bind)[ which ](op, rs)) #define slap_be_op( be,which,op,rs) slap_bi_op( (be)->bd_info,which,op,rs) #define SLAP_OP( which,op,rs) slap_be_op( (op)->o_bd, which,op,rs) /* Internal operations - as above but with op->o_internal set */ LDAP_SLAPD_F (int) (slap_bi_intop) LDAP_P(( BackendInfo *bi, slap_operation_t which, Operation *op, SlapReply *rs )); #define slap_be_intop(be,which,op,rs) slap_bi_intop((be)->bd_info,which,op,rs) #define SLAP_INTOP( which,op,rs) slap_be_intop(&(op)->o_bd, which,op,rs) /* In backend.c: */ int slap_bi_intop( BackendInfo *bi, slap_operation_t which, Operation *op, SlapReply *rs) { int rc; WITH_INTERNAL_OP( rc = slap_bi_op( bi, which, op, rs )); return rc; } > At this point, we need consensus on addressing ITS#6758 in the first > place. Nah. ITS#6758 needs the macros (at least if I'm to go at it), but the macros don't need ITS#6758 since they don't change what the code does. Hallvard

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 7:56 AM, clem.oudot(a)gmail.com wrote: > Le 20 avril 2012 16:22, <hyc(a)symas.com> a écrit : >> Kurt(a)OpenLDAP.org wrote: >>> On Apr 20, 2012, at 6:35 AM, Howard Chu wrote: >>> >>>> Kurt(a)OpenLDAP.org wrote: >>>>> Incorrect behavior per the standards. If the control is recognized and >>>> implemented, then it's to be processed regardless of the criticality. There's >>>> not supposed to be any "if it errors, ignore it" processing. >>>> >>>> Thanks for the confirmation. The text of RFC2891 seems contradictory here though. >>> >>> RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. >>> >>>> Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). >>> >>> Both 3 and 4, especially when taken together, overload criticality. >>> >>> 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. >>> >>> 4 isn't much better. >>> >>> So the whole specification is a mess. >>> >>> What I recommend is this, >>> >>> If the server implements the control: >>> >>> If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. >>> >>> This, I think is consistent with RFC 2891. >>> The client application is assured that the results are sorted in the >>> specified key order if and only if the result code in the >>> sortKeyResponseControl is success. >>> >>> clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. >> >> OK. I'm going to add some comments to this effect in sssvlv.c but otherwise >> close this ITS, works as designed. > > I would like just mention that this choice may be relevant from an > RFC/standardization point of view, but will lead to incompatibility of > OpenLDAP with some softwares like Cognos or Outlook, which use the sss > control on standards attributes like cn or sn. maybe you should file a bug report with them. > May it be possible to add an option in the sssvlv overlay to ignore such errors? I prefer not to condone non-standard behaviors by adding workarounds for them.

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 7:54 AM, Hallvard Breien Furuseth wrote: >> (...) >> So the whole specification is a mess. >> >> What I recommend is this, >> >> If the server implements the control: >> >> If the control is present, try to sort. If able to do so, return >> sortResult.success. Otherwise return sortResult with sortResult != >> success. >> >> This, I think is consistent with RFC 2891. > > Though the new behavior may be formally compatible with both RFCs, > it certainly breaks the expectations of one of them and must do so. Client developers implementing/using RFC 2891 should only have one key expectation: The client application is assured that the results are sorted in the specified key order if and only if the result code in the sortKeyResponseControl is success. Clients which assume results are otherwise sorted are simply broken. And, more generally, the client developer should not assume servers adhere to all "shoulds" and "SHOULDs" in a spec. > > How long has the previous behavior been in in OpenLDAP? Is it > feasible to delay the change until RE25? Seems like a typical > kind of change to avoid doing in the middle of a release series. As Howard's comment imply, we implement the behavior I suggest... all he's doing is clarifying in comments the current code behaves consistently with both RFC 2891 and RFC 4510. -- Kurt

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by clem.oudot＠gmail.com 20 Apr '12

20 Apr '12

Le 20 avril 2012 16:22, <hyc(a)symas.com> a écrit : > Kurt(a)OpenLDAP.org wrote: >> On Apr 20, 2012, at 6:35 AM, Howard Chu wrote: >> >>> Kurt(a)OpenLDAP.org wrote: >>>> Incorrect behavior per the standards. If the control is recognized and >>> implemented, then it's to be processed regardless of the criticality. There's >>> not supposed to be any "if it errors, ignore it" processing. >>> >>> Thanks for the confirmation. The text of RFC2891 seems contradictory here though. >> >> RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. >> >>> Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). >> >> Both 3 and 4, especially when taken together, overload criticality. >> >> 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. >> >> 4 isn't much better. >> >> So the whole specification is a mess. >> >> What I recommend is this, >> >> If the server implements the control: >> >> If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. >> >> This, I think is consistent with RFC 2891. >> The client application is assured that the results are sorted in the >> specified key order if and only if the result code in the >> sortKeyResponseControl is success. >> >> clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. > > OK. I'm going to add some comments to this effect in sssvlv.c but otherwise > close this ITS, works as designed. I would like just mention that this choice may be relevant from an RFC/standardization point of view, but will lead to incompatibility of OpenLDAP with some softwares like Cognos or Outlook, which use the sss control on standards attributes like cn or sn. May it be possible to add an option in the sssvlv overlay to ignore such errors? Clément.

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by h.b.furuseth＠usit.uio.no 20 Apr '12

20 Apr '12

On Fri, 20 Apr 2012 14:05:34 GMT, Kurt(a)OpenLDAP.org wrote: > RFC 2891 was written before RFC 4510... and to some degree, IIRC, was > the reason why the criticality processing requirements were make more > clear in RFC 4510. Overloading criticality (or any protocol element) > is simply a bad thing. IIRC that was done with the understanding that some control RFCs would have to be rewritten - but apparently nobody volunteered to do the rewrites. > (...) > So the whole specification is a mess. > > What I recommend is this, > > If the server implements the control: > > If the control is present, try to sort. If able to do so, return > sortResult.success. Otherwise return sortResult with sortResult != > success. > > This, I think is consistent with RFC 2891. Though the new behavior may be formally compatible with both RFCs, it certainly breaks the expectations of one of them and must do so. How long has the previous behavior been in in OpenLDAP? Is it feasible to delay the change until RE25? Seems like a typical kind of change to avoid doing in the middle of a release series. -- Hallvard

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by hyc＠symas.com 20 Apr '12

20 Apr '12

Kurt(a)OpenLDAP.org wrote: > On Apr 20, 2012, at 6:35 AM, Howard Chu wrote: > >> Kurt(a)OpenLDAP.org wrote: >>> Incorrect behavior per the standards. If the control is recognized and >> implemented, then it's to be processed regardless of the criticality. There's >> not supposed to be any "if it errors, ignore it" processing. >> >> Thanks for the confirmation. The text of RFC2891 seems contradictory here though. > > RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. > >> Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). > > Both 3 and 4, especially when taken together, overload criticality. > > 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. > > 4 isn't much better. > > So the whole specification is a mess. > > What I recommend is this, > > If the server implements the control: > > If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. > > This, I think is consistent with RFC 2891. > The client application is assured that the results are sorted in the > specified key order if and only if the result code in the > sortKeyResponseControl is success. > > clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. OK. I'm going to add some comments to this effect in sssvlv.c but otherwise close this ITS, works as designed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 6:35 AM, Howard Chu wrote: > Kurt(a)OpenLDAP.org wrote: >> On Apr 20, 2012, at 5:17 AM, coudot(a)linagora.com wrote: >> >>> Full_Name: Clément OUDOT >>> Version: 2.4.30 >>> OS: GNU/Linux >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (88.173.78.196) >>> >>> >>> I noticed that with OpenLDAP 2.4.30, a search request with a non >>> criticical sss control on an attribute without ordering matching rule >>> returns an error: >>> >>> clement@ader:~/Programmes/openldap$ bin/ldapsearch -H >>> ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b >>> ou=people,ou=XXX -E sss=cn >>> # extended LDIF >>> # >>> # LDAPv3 >>> # with server side sorting control >>> # >>> >>> # search result >>> search: 2 >>> result: 18 Inappropriate matching >>> text: serverSort control: No ordering rule >>> >>> # numResponses: 1 >>> >>> I think the error should only be returned if the control is critical. Else, the >>> search results should be returned, not sorted. >> >> Incorrect behavior per the standards. If the control is recognized and > implemented, then it's to be processed regardless of the criticality. There's > not supposed to be any "if it errors, ignore it" processing. > > Thanks for the confirmation. The text of RFC2891 seems contradictory here though. RFC 2891 was written before RFC 4510... and to some degree, IIRC, was the reason why the criticality processing requirements were make more clear in RFC 4510. Overloading criticality (or any protocol element) is simply a bad thing. > Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). Both 3 and 4, especially when taken together, overload criticality. 3 is a complete mess because the server returning unavailableCriticalExtension but still making use of the extension by returning an extension specific control! 3 is also problematic as the server might detect the problem only after it has returned some entries. 4 isn't much better. So the whole specification is a mess. What I recommend is this, If the server implements the control: If the control is present, try to sort. If able to do so, return sortResult.success. Otherwise return sortResult with sortResult != success. This, I think is consistent with RFC 2891. The client application is assured that the results are sorted in the specified key order if and only if the result code in the sortKeyResponseControl is success. clause 3-4 all have "should" (or "SHOULD") in them, all of which mean they are not absolutes. I think it reasonable to use RFC 4510 and the extensions BCP as justification to do something reasonable, such as what I suggest above. > > I remember we had this conversation about control criticality before, but don't recall the details. Does the later clarification of Criticality supersede the text of RFC2891? > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 20 Apr '12

20 Apr '12

> OK, thanks for confirmation. I will report a bug for sudo. http://www.sudo.ws/bugs/show_bug.cgi?id=554

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by hyc＠symas.com 20 Apr '12

20 Apr '12

Kurt(a)OpenLDAP.org wrote: > On Apr 20, 2012, at 5:17 AM, coudot(a)linagora.com wrote: > >> Full_Name: Clément OUDOT >> Version: 2.4.30 >> OS: GNU/Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (88.173.78.196) >> >> >> I noticed that with OpenLDAP 2.4.30, a search request with a non >> criticical sss control on an attribute without ordering matching rule >> returns an error: >> >> clement@ader:~/Programmes/openldap$ bin/ldapsearch -H >> ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b >> ou=people,ou=XXX -E sss=cn >> # extended LDIF >> # >> # LDAPv3 >> # with server side sorting control >> # >> >> # search result >> search: 2 >> result: 18 Inappropriate matching >> text: serverSort control: No ordering rule >> >> # numResponses: 1 >> >> I think the error should only be returned if the control is critical. Else, the >> search results should be returned, not sorted. > > Incorrect behavior per the standards. If the control is recognized and implemented, then it's to be processed regardless of the criticality. There's not supposed to be any "if it errors, ignore it" processing. Thanks for the confirmation. The text of RFC2891 seems contradictory here though. Specifically, section 2 clause #4 says if critical is False, the search results should be returned unsorted, with a sortKeyResponseControl in the searchResultDone message, containing the error (e.g. inappropriateMatching). I remember we had this conversation about control criticality before, but don't recall the details. Does the later clarification of Criticality supersede the text of RFC2891? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by Kurt＠OpenLDAP.org 20 Apr '12

20 Apr '12

On Apr 20, 2012, at 5:17 AM, coudot(a)linagora.com wrote: > Full_Name: Clément OUDOT > Version: 2.4.30 > OS: GNU/Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.173.78.196) > > > I noticed that with OpenLDAP 2.4.30, a search request with a non > criticical sss control on an attribute without ordering matching rule > returns an error: > > clement@ader:~/Programmes/openldap$ bin/ldapsearch -H > ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b > ou=people,ou=XXX -E sss=cn > # extended LDIF > # > # LDAPv3 > # with server side sorting control > # > > # search result > search: 2 > result: 18 Inappropriate matching > text: serverSort control: No ordering rule > > # numResponses: 1 > > I think the error should only be returned if the control is critical. Else, the > search results should be returned, not sorted. Incorrect behavior per the standards. If the control is recognized and implemented, then it's to be processed regardless of the criticality. There's not supposed to be any "if it errors, ignore it" processing. -- Kurt

1 0

(ITS#7253) Error returned when sss control used with a non ordered attribute, even if the control is not critical
by coudot＠linagora.com 20 Apr '12

20 Apr '12

Full_Name: Clément OUDOT Version: 2.4.30 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.173.78.196) I noticed that with OpenLDAP 2.4.30, a search request with a non criticical sss control on an attribute without ordering matching rule returns an error: clement@ader:~/Programmes/openldap$ bin/ldapsearch -H ldap://localhost:3389 -D ou=lsc,ou=accounts,ou=XXX -w secret -b ou=people,ou=XXX -E sss=cn # extended LDIF # # LDAPv3 # with server side sorting control # # search result search: 2 result: 18 Inappropriate matching text: serverSort control: No ordering rule # numResponses: 1 I think the error should only be returned if the control is critical. Else, the search results should be returned, not sorted. A patch was proposed in ITS 6647, it was working when applied to 2.4.23 version: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-09-14-sssvlv.1.pat…

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 20 Apr '12

20 Apr '12

On 04/19/2012 11:20 PM, Hallvard Breien Furuseth wrote: > On Thu, 19 Apr 2012 14:58:32 GMT, masarati(a)aero.polimi.it wrote: >>> I do have a patch+Perl script which wraps all operation(op, rs) >>> calls, but it doesn't know which ops are "internal". >> >> I don't think it's something that can be done automatically. Careful code >> review and testing would be required. >> >>> I want it for the SlapReply cleanup (ITS#6758). The only way to >>> make a hunt for dirty SlapReplies feasible. I suggested it when >>> I was doing the cleanup, but IIRC nobody replied - except there >>> were related complaints that my cleanup was too invasive. >>> >>> http://www.openldap.org/lists/openldap-devel/201101/msg00039.html >>> http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt >>> >>> Anyway, here's me trying agin again:-) >> >> Sort of recall it. Well, it looks pretty invasive, indeed. The two >> things should be kept separate. No preference about the order in which >> the two changes should be applied. I'm in no hurry to work at internal >> ops (mostly because I have scarce time for it and I'm worried about >> possible unexpected showstoppers). >> >> Maybe, if all calls for internal operations are wrapped by a macro, then >> ITS#6758 SlapReply cleanup could be performed just from within that >> macro; >> calls that are not judged internal would need to be explicitly wrapped, >> though. > > No, I meant the opposite: The macroization is done. It could mostly be > scripted and makes no semantic change unless #ifdef(SlapReply debug), > which is what the macros were for. Right. > Figuring out which ops to tag as internal does, as you say, require > review and testing. And one extra arg to the macros. How do you suggest to proceed? I believe using different macros, e.g. slap_bi_op_internal, slap_be_op_internal and SLAP_OP_INTERNAL is clearer than having an additional 0/1 parameter. OTOH, adding further parameters in the future would be probably easier if we extend your macros. At this point, we need consensus on addressing ITS#6758 in the first place. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: ITS#7239: testbed
by h.b.furuseth＠usit.uio.no 19 Apr '12

19 Apr '12

On Thu, 19 Apr 2012 14:58:32 GMT, masarati(a)aero.polimi.it wrote: >> I do have a patch+Perl script which wraps all operation(op, rs) >> calls, but it doesn't know which ops are "internal". > > I don't think it's something that can be done automatically. Careful > code > review and testing would be required. > >> I want it for the SlapReply cleanup (ITS#6758). The only way to >> make a hunt for dirty SlapReplies feasible. I suggested it when >> I was doing the cleanup, but IIRC nobody replied - except there >> were related complaints that my cleanup was too invasive. >> >> >> http://www.openldap.org/lists/openldap-devel/201101/msg00039.html >> http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt >> >> Anyway, here's me trying agin again:-) > > Sort of recall it. Well, it looks pretty invasive, indeed. The two > things should be kept separate. No preference about the order in > which > the two changes should be applied. I'm in no hurry to work at > internal > ops (mostly because I have scarce time for it and I'm worried about > possible unexpected showstoppers). > > Maybe, if all calls for internal operations are wrapped by a macro, > then > ITS#6758 SlapReply cleanup could be performed just from within that > macro; > calls that are not judged internal would need to be explicitly > wrapped, > though. No, I meant the opposite: The macroization is done. It could mostly be scripted and makes no semantic change unless #ifdef(SlapReply debug), which is what the macros were for. Figuring out which ops to tag as internal does, as you say, require review and testing. And one extra arg to the macros. Hallvard

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 19 Apr '12

19 Apr '12

> On Thu, 19 Apr 2012 06:16:16 GMT, masarati(a)aero.polimi.it wrote: >> A definitive and simple solution, although invasive, would be to: >> >> - add a o_internal flag to the Operation structure >> >> - add a macro BE_INTERNAL(op, rs, op_type) like >> >> #define BE_INTERNAL(op, rs, op_type, rcp) \ >> { >> int save_o_internal = op->o_internal; >> op->o_internal = 1; >> *rcp = (&op->o_bd->bi_info->bi_op_bind)[op_type]( op, rs ); >> op->o_internal = save_o_internal; >> } > > I imagine connection.c:operation_fake_init() should set > op->o_internal and any callers which disagree should unset it Good point. >> fix all calls to internal operations (brrr....) > > I do have a patch+Perl script which wraps all operation(op, rs) > calls, but it doesn't know which ops are "internal". I don't think it's something that can be done automatically. Careful code review and testing would be required. > I want it for the SlapReply cleanup (ITS#6758). The only way to > make a hunt for dirty SlapReplies feasible. I suggested it when > I was doing the cleanup, but IIRC nobody replied - except there > were related complaints that my cleanup was too invasive. > > http://www.openldap.org/lists/openldap-devel/201101/msg00039.html > http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt > > Anyway, here's me trying agin again:-) Sort of recall it. Well, it looks pretty invasive, indeed. The two things should be kept separate. No preference about the order in which the two changes should be applied. I'm in no hurry to work at internal ops (mostly because I have scarce time for it and I'm worried about possible unexpected showstoppers). Maybe, if all calls for internal operations are wrapped by a macro, then ITS#6758 SlapReply cleanup could be performed just from within that macro; calls that are not judged internal would need to be explicitly wrapped, though. p.

1 0

(ITS#7252)
by robert.eikermann＠rwth-aachen.de 19 Apr '12

19 Apr '12

This is a multipart message in MIME format. --Boundary_(ID_khV0Q9i4TrDM+jpu+4DSYg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT regarding the first answer of my mail in the mailinglist applying the patch does not change the behavior! Patch: diff --git a/servers/slapd/back-sql/search.c b/servers/slapd/back-sql/search.c index cadd036..92d3f82 100644 --- a/servers/slapd/back-sql/search.c +++ b/servers/slapd/back-sql/search.c @@ -325,7 +325,7 @@ backsql_init_search( rc = rs->sr_err = LDAP_REFERRAL; rs->sr_ref = referral_rewrite( erefs, &bsi->bsi_e->e_nname, - &op->o_req_dn, + NULL /* &op->o_req_dn */ , scope ); ber_bvarray_free( erefs ); @@ -2336,7 +2336,7 @@ backsql_search( Operation *op, SlapReply *rs ) if ( refs ) { rs->sr_ref = referral_rewrite( refs, &e->e_name, - &op->o_req_dn, + NULL /* &op->o_req_dn */ , op->ors_scope ); ber_bvarray_free( refs ); } --Boundary_(ID_khV0Q9i4TrDM+jpu+4DSYg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 = (filtered medium)"><style></style></head><body lang=3DDE link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>regarding the first answer of my mail in the = mailinglist<o:p></o:p>applying the patch does not change the = behavior!<o:p></o:p><o:p> </o:p><o:p> </o:p>Patch:<o:p></o:p><o:p> </o:p>diff --git = a/servers/slapd/back-sql/search.c = b/servers/slapd/back-sql/search.c<o:p></o:p>index cadd036..92d3f82 = 100644<o:p></o:p>--- = a/servers/slapd/back-sql/search.c<o:p></o:p>+++ = b/servers/slapd/back-sql/search.c<o:p></o:p>@@ -325,7 +325,7 @@ = backsql_init_search(<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   rc =3D rs->sr_err =3D = LDAP_REFERRAL;<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   rs->sr_ref =3D referral_rewrite( = erefs,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           &nbsp= ;       = &bsi->bsi_e->e_nname,<o:p></o:p>-       =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = &op->o_req_dn,<o:p></o:p>+       =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = NULL /* &op->o_req_dn */ ,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           &nbsp= ;       scope );<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;   ber_bvarray_free( erefs );<o:p></o:p>        = <o:p></o:p>@@ -2336,7 +2336,7 @@ backsql_search( = Operation *op, SlapReply *rs )<o:p></o:p> =             &= nbsp;         if ( refs ) = {<o:p></o:p> =             &= nbsp;           &n= bsp;     rs->sr_ref =3D referral_rewrite( = refs,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;        &e->e_name,<o:p></o:p>-       =             &= nbsp;           &n= bsp;           &nb= sp; &op->o_req_dn,<o:p></o:p>+       =             &= nbsp;           &n= bsp;           &nb= sp; NULL /* &op->o_req_dn */ ,<o:p></o:p> =             &= nbsp;           &n= bsp;           &nb= sp;        op->ors_scope = );<o:p></o:p> =             &= nbsp;           &n= bsp;     ber_bvarray_free( refs = );<o:p></o:p> =             &= nbsp;         }<o:p></o:p><o:p> </o:p></div></body></html>= --Boundary_(ID_khV0Q9i4TrDM+jpu+4DSYg)--

1 0

(ITS#7252) Referral Problem with SQL Backend
by robert.eikermann＠rwth-aachen.de 19 Apr '12

19 Apr '12

Full_Name: Robert Eikermann Version: 2.4.23 OS: Ubuntu 11.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.226.168.114) Hi, regarding my mail to the mailinglist: http://www.openldap.org/lists/openldap-technical/201204/msg00053.html I'm using openldap with SQL-Backend (Postgres). The configured referral on this server behaves not the way it should. The bind dn of the referral is overwritten by the bind dn (of ldapsearch). Following are the configuration and the Log files of the LDAP Server with SQL Backend at Loglevel -1. In the Logfile you can see the starting of the server + the search ldapsearch -xLLL -h localhost:389 -b dc=sselab,dc=de. I think at line 4114 one can see how the referral is used. Slapd.conf : http://pastebin.com/tvtdNaZ6 sql attribute mappings: http://image-upload.de/image/WcDeaB/fd191aa422.png sql entries: http://image-upload.de/image/qGiBOY/51496a9462.png sql object classes: http://image-upload.de/image/Rei0X3/4f6b2b43f5.png sql oc mapping: http://image-upload.de/image/TRscIQ/7141e04af6.png sql referral: http://image-upload.de/image/LGxZKQ/28773fadf7.png ldap Log: http://pastebin.com/N8NCyLzt To demonstrate the behavior: Search for the referral Object: user@user-desktop:~$ ldapsearch -M -xLLL -h localhost:389 "(objectClass=referral)" '*' ref dn: dc=tim,dc=sselab,dc=de objectClass: referral objectClass: extensibleObject dc: tim ref: ldap://localhost:390/dc=tim,dc=sselab,dc=de# which is exactly what I want! But searching all objects: user@user-desktop:~$ ldapsearch -xLLL -h localhost:389 -b dc=sselab,dc=de dn: dc=sselab,dc=de objectClass: dcObject dc: sselab # refldap://localhost:390/dc=sselab,dc=de??sub Results with the wrong dn in refldap! Search with the dc=tim DN : user@user-desktop:~$ ldapsearch -xLLL -h localhost:389 -b dc=tim,dc=sselab,dc=de Referral (10) Referral: ldap://localhost:390/dc=tim,dc=sselab,dc=de??sub If you need more Information please let me know. Best regards Robert Eikermann

1 0

Re: ITS#7239: testbed
by h.b.furuseth＠usit.uio.no 19 Apr '12

19 Apr '12

On Thu, 19 Apr 2012 06:16:16 GMT, masarati(a)aero.polimi.it wrote: > A definitive and simple solution, although invasive, would be to: > > - add a o_internal flag to the Operation structure > > - add a macro BE_INTERNAL(op, rs, op_type) like > > #define BE_INTERNAL(op, rs, op_type, rcp) \ > { > int save_o_internal = op->o_internal; > op->o_internal = 1; > *rcp = (&op->o_bd->bi_info->bi_op_bind)[op_type]( op, rs ); > op->o_internal = save_o_internal; > } I imagine connection.c:operation_fake_init() should set op->o_internal and any callers which disagree should unset it > fix all calls to internal operations (brrr....) I do have a patch+Perl script which wraps all operation(op, rs) calls, but it doesn't know which ops are "internal". I want it for the SlapReply cleanup (ITS#6758). The only way to make a hunt for dirty SlapReplies feasible. I suggested it when I was doing the cleanup, but IIRC nobody replied - except there were related complaints that my cleanup was too invasive. http://www.openldap.org/lists/openldap-devel/201101/msg00039.html http://folk.uio.no/hbf/OpenLDAP/wrap_slap_ops.txt Anyway, here's me trying agin again:-) -- Hallvard

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

>> Thanks. The explanation is always simple, after one finds it. The DN >> of >> accesslog entries is generated using the reqStart AVA. When logops all >> and internal operations take place, multiple entries are generated with >> the same reqStart AVA. So an internal search which is logged because of >> some overlay eats up the DN of the modrdn, and be_add() called by >> slapo-accesslog(5) fails because the entry already exists. >> >> Although logging internal entries could be of some use, I see two >> solutions: >> >> - modify the value of reqStart (e.g. instead of using o_tincr for the >> fractional part of the timestamp, we could use an incremental counter >> initialized with o_tincr and incremented at each logging within the same >> operation. The counter could be stored somewhere in the operation >> structure (e.g. in o_extra) >> >> - prevent logging of internal ops; again, this could be achieved by >> setting a dedicated o_internal_op field in the Operation structure. >> >> Since this modification could be intrusive, I'd like to gather some >> comments before proceeding with a fix. > > Hm, we've run into this similar problem before with syncprov and > introduced > op->o_dont_replicate. As a general rule, accesslog is meant to log user > operations, not internal operations. Currently accesslog checks > (op->o_dont_replicate && op->orm_no_opattrs) to skip logging of write ops. > I > guess we need a more general flag instead. A definitive and simple solution, although invasive, would be to: - add a o_internal flag to the Operation structure - add a macro BE_INTERNAL(op, rs, op_type) like #define BE_INTERNAL(op, rs, op_type, rcp) \ { int save_o_internal = op->o_internal; op->o_internal = 1; *rcp = (&op->o_bd->bi_info->bi_op_bind)[op_type]( op, rs ); op->o_internal = save_o_internal; } fix all calls to internal operations (brrr....) p.

1 0

(ITS#7251) MDB shared mutexes ambiguous on Apple/Windows
by hyc＠OpenLDAP.org 18 Apr '12

18 Apr '12

Full_Name: Howard Chu Version: HEAD/RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (109.151.244.127) Submitted by: hyc Currently since MacOSX and Windows don't support process-shared mutexes residing in shared memory, MDB uses global named semaphores instead on these platforms. The semaphore name is derived from a hash of the pathname of the lock file. This approach was quick and dirty and is prone to failure if relative paths and absolute paths are mixed, or if a file can be accessed thru multiple paths (e.g. symlinks, loopback mounts, whatever). Instead of the pathname, a unique file identifier of the lock file should be used. For MacOSX we can obtain (device,inode) using fstat(). For Windows we can obtain (dwVolumeSerialNumber,nFileIndexLow,nFileIndexHigh) using GetFileInformationByHandle().

1 0

Re: ITS#7239: testbed
by hyc＠symas.com 18 Apr '12

18 Apr '12

masarati(a)aero.polimi.it wrote: >> This is a cryptographically signed message in MIME format. >> >> --------------ms020801020604080509050502 >> Content-Type: text/plain; charset=ISO-8859-15 >> Content-Transfer-Encoding: quoted-printable >> >> masarati(a)aero.polimi.it wrote: >>> =20 >>> The attachment is unreadable; can you ftp it somewhere? Thanks, p. >> >> http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 > > Thanks. The explanation is always simple, after one finds it. The DN of > accesslog entries is generated using the reqStart AVA. When logops all > and internal operations take place, multiple entries are generated with > the same reqStart AVA. So an internal search which is logged because of > some overlay eats up the DN of the modrdn, and be_add() called by > slapo-accesslog(5) fails because the entry already exists. > > Although logging internal entries could be of some use, I see two solutions: > > - modify the value of reqStart (e.g. instead of using o_tincr for the > fractional part of the timestamp, we could use an incremental counter > initialized with o_tincr and incremented at each logging within the same > operation. The counter could be stored somewhere in the operation > structure (e.g. in o_extra) > > - prevent logging of internal ops; again, this could be achieved by > setting a dedicated o_internal_op field in the Operation structure. > > Since this modification could be intrusive, I'd like to gather some > comments before proceeding with a fix. Hm, we've run into this similar problem before with syncprov and introduced op->o_dont_replicate. As a general rule, accesslog is meant to log user operations, not internal operations. Currently accesslog checks (op->o_dont_replicate && op->orm_no_opattrs) to skip logging of write ops. I guess we need a more general flag instead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

> This is a cryptographically signed message in MIME format. > > --------------ms020801020604080509050502 > Content-Type: text/plain; charset=ISO-8859-15 > Content-Transfer-Encoding: quoted-printable > > masarati(a)aero.polimi.it wrote: >>=20 >> The attachment is unreadable; can you ftp it somewhere? Thanks, p. > > http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 Thanks. The explanation is always simple, after one finds it. The DN of accesslog entries is generated using the reqStart AVA. When logops all and internal operations take place, multiple entries are generated with the same reqStart AVA. So an internal search which is logged because of some overlay eats up the DN of the modrdn, and be_add() called by slapo-accesslog(5) fails because the entry already exists. Although logging internal entries could be of some use, I see two solutions: - modify the value of reqStart (e.g. instead of using o_tincr for the fractional part of the timestamp, we could use an incremental counter initialized with o_tincr and incremented at each logging within the same operation. The counter could be stored somewhere in the operation structure (e.g. in o_extra) - prevent logging of internal ops; again, this could be achieved by setting a dedicated o_internal_op field in the Operation structure. Since this modification could be intrusive, I'd like to gather some comments before proceeding with a fix. p.

1 0

Re: ITS#7239: testbed
by michael＠stroeder.com 18 Apr '12

18 Apr '12

This is a cryptographically signed message in MIME format. --------------ms020801020604080509050502 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable masarati(a)aero.polimi.it wrote: >=20 > The attachment is unreadable; can you ftp it somewhere? Thanks, p. http://www.stroeder.com/temp/openldap-testbed-its7239.tar.bz2 --------------ms020801020604080509050502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxODIwNTAyOFowIwYJKoZIhvcNAQkEMRYE FO5TfD14PMXVNCzh4rtO6MQEgfVNMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAWC2ZU3Z19tk5FafFmH93ox5VIq85YoZoKvQEjiZC/aWis578hUnfkJXS/Dh+Ltt+dyj/ t3DzDSlJHBbvjyAoReVO54SwPKpJZE8SadEXNLK31Cs6J0QJFHt3gW9nW2wr/sXcNnLHqxxm fq8Ofn3ztGC5bxBa2BYTKGq/23Oa6zDK/5GfG7BTw4KZ4JlpGat0/12z9oqDgNkYCEEHFmVa bXNGpFnV5e0+ngjIqBvdRt80iuV9et3vXRBWrJWJMC0uA5NfKWldOh3Ov4WL/GKl2PtCWRo0 Q3twLoa88WPMWDdZzKeKRLvxQxMtYCh2ZIk74aNAATNXPznIDyMnlWPqOAAAAAAAAA== --------------ms020801020604080509050502--

1 0

Re: ITS#7239: testbed
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

The attachment is unreadable; can you ftp it somewhere? Thanks, p.

1 0

ITS#7239: testbed
by michael＠stroeder.com 18 Apr '12

18 Apr '12

This is a multi-part message in MIME format. --------------000704030300080804030201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit See openldap-testbed-its7239.tar.bz2 attached. You have to adjust paths in the config of course. ldapadd -H ldap://localhost:2071 \ -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret \ -f initial.ldif ldapadd -H ldap://localhost:2071 \ -D "uid=diradm,ou=schulung,dc=stroeder,dc=local" -w testsecret \ -f modrdn.ldif Now look at the accesslog DB: ldapsearch -x -H ldap://localhost:2071 -b cn=accesslog -s one "(objectClass=auditModRDN)" => no results. Now repeat that with "logops writes" instead of "logops all": rm db/*/* ldapadd... ldapmodify... $ ldapsearch -x -H ldap://localhost:2071 -b cn=accesslog -s one "(objectClass=auditModRDN)" # extended LDIF # # LDAPv3 # base <cn=accesslog> with scope oneLevel # filter: (objectClass=auditModRDN) # requesting: ALL # # 20120418194545.000001Z, accesslog dn: reqStart=20120418194545.000001Z,cn=accesslog objectClass: auditModRDN reqStart: 20120418194545.000001Z reqEnd: 20120418194545.000002Z reqType: modrdn reqSession: 1001 reqAuthzID: uid=diradm,ou=schulung,dc=stroeder,dc=local reqDN: uid=test1,ou=schulung,dc=stroeder,dc=local reqResult: 0 reqMod: entryCSN:= 20120418194545.412289Z#000000#000#000000 reqMod: modifiersName:= uid=diradm,ou=schulung,dc=stroeder,dc=local reqMod: modifyTimestamp:= 20120418194545Z reqNewRDN: uid=test2 reqDeleteOldRDN: TRUE reqEntryUUID: 86014e61-7c47-4062-931f-39526f738016 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 --------------000704030300080804030201 Content-Type: application/x-bzip2; name="openldap-testbed-its7239.tar.bz2" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="openldap-testbed-its7239.tar.bz2" QlpoOTFBWSZTWUmYCwUAHGV/pf7wIiB//////+///v////4AQEABQAAACGAYTc+5LsPvZ6D5 S0u9988PvuzvWcErt3vmfHtqpub6fXnZrqotFaNWzWqBSlaalKe2+3rXQclH00F7PXeEkhBG mIU9pMnpMTRT8ieptUep6ZTyjaTNQep6mnqPUwmmgeobU0yHqCSITEAJpKeanqbSpptG0j1G iDaTxTQep6hhAMaNAgMQBiJqZBU2p6g9qjRo9QGmajQBoaABoAAZAaAaaDCTUiECRmk9KP0R ogyNNDIekMmgGjQAA0AGmgAEVET1CmnjU0mhiab1TENMmTJkMgyDaIPU0NGIeoMQGjAkSCAE ARkI0yaT0A0KnkhsoaHqaBoNNGQaGgAPShWelmPPk8yZHbmS0CkHt1gnOGQDrIJCM+7nzfOc Z72Sqn4gqiDACCJRBhlQZGTF3hTvhTvZsGMJikIgTnLCIQGUJJIZUVEREUIJEJ3/vXuwnL7p h3znhR3iv2MqIbboLeIBa0NpJjEKAunYNEppc/8z2oXvOhXcOtedrYOHXT4cOK+BIpwcvGhh 3rpNlphr7KbU4qZBqPd5JTP4b5kzQsRFrYeTYoyPyO2pMXZeuz3bMfqwXrYiphmDAdn3jf+O qu/IsCyfb+1mfpLOPWlcNDaA2J95Jrz8+3sfZOWNO7R9/fXyupdZdO27I5jOHhB4NNpNtMsj 3eQM98bZDYslevmFrskMW6HaOzD3qoqlC/zVcT/aUU2KORwxAnm50pFOzZbZqCFbDKcVOyWC lHkKw+R2kr0ZbuEjc2mVeLq69FdhfdFiC08bNU1Azp2+uPze6MAxeP5Ll2vd7SO4JxeO6fCQ jeAwGqU3mugGJ6g6TI82RW0Z0ehKN+Dm9RmdFORarbZkLW0xmfbq9mHPbZl/xsI8ZhSzlsPo JMSEH0ZqDugLWjzoTQghG4wFUhiGcVicNgXpyDAhYPoSZgqkT4zA5QWBQ1EtyVOi79Orq4m8 26fG2+bvViPZTLw+GqXWeFK98VtI8mG38E38EC/H9aYxChiGNTQtqf64f2g11kkgmJ7zbgT4 ++vXWu17abfMoXxNUh4Q2gQhTxw0aURDyMaKROl4U4w4bT072Vhso7qWsOMXF7+pIMPsHQE2 r8TqlkfLIXuKn5zSCDE+nX4eesv9xhEz3Skw458ZIfd3Ekc4IwHyKBcEl+nvrv+dFLkcsydz DGkDrBP1WcfzmZSofJoL77NROzH25fZH13e8Wt/I0I45rlhL09SsK2TIL+cHvlx+JMxYYhjx lLHixxdze1zRXjdw0Ia5T2DYfWcTI9JYHxRXXrxE69qnPFsYWUNFZE02shprwKa1+bGyBtJ4 MWWubpGPnILszMj24321nWdN/a2zO5np27zmuibmxyTkOKuic8s7eC8SoHOb3wYZOHJb4OfL DGYWxt037dQqLa7hql0EBcZ4E/5zLurQ1Y4u9HdoZG6K7lePA8dbMe2BbrsG12cdoX2rYa9s 7zu6i2K2naGeGebxh5i7LRdunRDgrkRYUto+yeJSgykk3ulSGTy4XGXCPMo6+6tnnOOWGSwZ jGnfWRkdlxFweYw5C9LXKtvHbJeRsGfBnJbFtp3iJIEGbd3opT0RGKq2HBIGxRyl+zFLXtvV Z/5bdCW/ZIz5bB1dxotZoXnZ3XSMEwLdakUtJULO7NTVWcsSTnuZMmplpyYJI4iQJccNiiP0 nDuSST7zyjAX/EzxqK8tmedVfcEKqn1pD/UgsCLAgLAUIcsFfDFWIrACoCkmBG7Wybdrq42H Iptw6k2jiRJFemKBLGK5iy/fhg8M1zhMFoTG9HLFofMpI0ENdP6Wz6PBUt6BAB822kqtrN9W NzLrhTdRp8164pkzLVvMwsoOALx/JdV8cNs/gqIbufg8vXf1rv79IHwys9CJulGHpPhhzyT0 er2NM3iursXVdQtfwmC4VEVTnX2wpGFIzS0QrYZs7rVnvS4jTLppJX2pzSWj2uLm5yoS0pL0 efh4DzfjBeWMj6WJi1oVv0FVvwdx/iJjn2BFrygHR9EARWCDdLmkcT2EI3jOJJ9OaOylyRQQ A2zn9xO6xnsIRSWtBglmZyjbfsxz5i9ekNi+SQQoYJsfkAiIckIgKuEKovIDwSAkheN6Z5zy XhL2qQIMxNkkSAQxNo/G9Tw70sFmRyhGO/m3a05XdH67x++8Oh21wKRnoqZdP5Zauj8X4wYw fT00Pws13lqHUB+P3tEKb1qn9W5KdGbeAjelKQF96DQnYFUNNDWXXJWITNGsKU16eYNtLHjB ZGEhYoGV8ULrfPA5oEw4gd3s/oPdWwSSN6IE06OY9dgHaJTgkGFRSSQgJCbbQqeSSHX1YeX9 9/P1dU6StjJDFxVPETsTfDZObiu6RfrIKnC+CRa5j6+O8lhfZzt/vJx+LOOtf0Wu+WR7656J BACIAQ0kBoPHXaSBFG9s2PzmL+YeytHBHz2CHjF0gspGOe2fVKFUKYbQuuSCsFOFUggc8lEw Z6tNlNIaGTEscMyBOjvdCHNtUg2+evYSkCMOeCygfmOT5RxbQvSB8xNI/Jx3IRIxGwhshDrw pGfPMljZE/QOUm4sfrRi7Eb7nLCErW3kUCM8GYqhEmhWq21iQSjQmWwQiMEKiSvrRUpWoOeB VAi2QjZnN3ZUMEjAmILW6qAQ2oI2isrY7IsxusKY0mO/E+ZJIJnF1he0S+hSoIm2FIONiTuE eimQiJ1E5y0u0h5X4lAEUSCtsM0DUZjnqRvZFl4UCcqEFUFTGCQLgWQiU5pRhe2JuDdYTUIp XjywERi117pFg7vmqoVd9hYX44wxbQ6ZTIGNOaVTp2jU0ThBRa7i5+rovnwtjNfU+HRBy6eJ Kevi49xJmx5HQaRmiiKjzThO1oPlvc3vL+yje9UHX29FQLO5IOx2RJlJ26CV9LLPAe0vr+3s TXme5p5pjq/MAmETgGyFYT9V5OiZz3xnvKnsWN/tHqJiN0Y9GL0CZ+1oTu/cN95lQmMwxPjF UCUlfrOseHL8X9nWb0eWfUi+UhWVJE4xS0wSn9IqOL3lkQZRkJmXVJPicOdrTZ2SlLYkdohD RkAYJHI3wbfzGmgMBvy3hRgk8Qyz+w9wTPXtjaPM9YcDP9rquUGLKhyObtkAUvU9RcYMx4iN CxNnDoZ8pBL3b+4PmIvDiAeSgcC8+wxSVTQ9Zv2aoqbjsOwgcgYZmV07txlDerMwBWIiSXR8 zgDgMncLJtZdw0GdmYuEI1kSDgtvcH86biJQ2H5Mc/IMEce2HHd9MwTUJJyFcDWBG4WvwSQ/ m37zZdB4+DbaD4oSOi2o5k6ksic5ScXHSzaH1Hr31XmR3d2S9OhoWLGOuXboRMhajlhqSWQx HCONorkG5bNdmh1MqWRATzq2kd8sEN6MGaCNlza8VrWf0vNw7wS8DoR6QGsep94agtVajEMg hQDGhpkH2sOI+Blslm/HUa7ZncGvPmdKSGG9raBspqEEl3Ly0ZMjQXVpluYM6FB/FcnrAGEU K4tjNCyYANqgpAMdpCROyL4giYMRKI5ZQBUWFlWFpUnCsUFjuaDOl65tPzPqOXrO8+AxQQzs JGKF8Uc22ga+cZ0hQEMugQ7I+lEASBgAdfHpysThPJ+JZzSsi8zHQZwKYBmfeesR++uL/UbD 6H6EdKYwxLVdf9ZRoRB8Mgd4uA3Ky0WVRx7icSnClxkUiYpqIIJr33ej9B3A3CbpNO7JWBfk DQiKCCQVgiKDhM1UvQ84Y20ldJaay1PTzi4FAGhW2UCHOIkg2EdL4IVIzDQ6SiXl4HKyoSe7 OCWvqPYYBmwcENChkJFlp6RDusbrrDodIIbAcRB7gi9SOHbYYtmGOV2xUMIVzreFg8mRGDSW Ikl206i3N8/AcrDALQPjvCNcxMbbDcu486AIFkgCD1LOiYbG31bf7BdpO8QxGSETAjJIMTkT u7sCxL3et28QWMhgQytBaLUY4DUpSqEFpI9rDaTMWte19G0B0o0TSRFgZGfQ39DXaKwYJMoN iS5EGSqJZOhDQgaSBsMSQr+3fnO4MZkwR9G2gHMVqtngMFaGUtQDkKZQuUWLGqBlJqyIUdN7 ilSkqiz0iAckmRwaJJ9viIg8zPeMKnAQf16v+9+UlvNpIlJKGBsElkmwsVeFkvRje3YW9obX x8qhiicwwuN8GxhQMG+aiwwRzDnzlOYpQhhUsniGNpMlcZxCUD41FSX0rpkkDXkKPmPt+B63 wRUR9DsEh3ngI3Gj7Gd5wWaOLWjvtVd4wGFNWU3iQfYSFsGEbEwFj2DEeOBHlkVWDWsvzwHw Mqjb/UXRUmqmZjGlJgUN+2xoGuZi1C7Hp4hq6+ulYJe2JqQJtIL5KQ0oYWB1GjNQTylYYmyh 6Cmlca0kMpZpF8WyBsvcMtRlFnHZN00sa1rna57rqQlAg6yvearR6FyzxcM74LajeDTJLGpT CTzsrPZpWU0r8LjOTnIq7GrSxlqLBoHLLEDsrDpFHXM+VtTrmoP7JJaOY3Z000Ik0WxFrJDo juKFN6EWKwnwFLoEhbr0Y3Efdpl5DbTncjAVhJp3Go5oWnyiGlw2bZiyRgzYZI2gI/he8kjk qqQWAaM1cYrXdrmeoakBw1N5tRAjBbmFEekE7JzBY4CGXhZGO1la6y/JMbtT9kd0gL7L3kQQ tQ9KbaZZxVkWitmRZmlOEEhg1pAEEhkog8RRFX4DlzeDD0SpdNUHT7rAExDcjjCM9I7JygFV ejrxmPi1XRxlj1WKpEFpbPmNVXFbRV4JgxoNdQvaEUTOdi7GSi1sjIRf4AYl6rVJLCfUe70y lVGV+DS5ip3rjtoy2LTb1WEk/G/2zlMiYOdQ2jAUEGdZloFpQke5i6IkS+bQSunkocEPwgRC knYwlh61zRaGB4BEloXuTPtSZ8CVCyqvFVLL60Xpx+d81UpWdp5KDGbxTHZHymEg2cu1ChkB tSpmoqMJcoCdM6/YMLlFUCNTt0YwYCP42g8nUKtphr+PQluPZ68K2FzZ1KQQCa1zVT2EHCod bZCSD1kMbvAj3+2aESmHSGz7ZnpeURfHsaUhwODhz0FsMS76y27V6vUY2OANWYOh9ozdmBFR Jpw1otrN2c147aS22m8Te7UeMGAVtYN+BhsA4CLPYQKv4s8W63MKezzwcdmORshtG+6QY6rz Y5I6Dhl9QxD2RZzuvSMBoJDA7XDA1w5fDE8zf5GLJuHEIIKpljvbNugMsIhks8Zp6XFS+KQX qb4pSJtHUXpMgLztQiasCVegrgmJgZiZqQBiTA2DfGEKBtYl6gzUVSba5vEU+9VLZpVVtVKq rpz86RcqbzKQdeqD2DCwlCbbFDNtkS0IrgQTSYi1NLvRgZNN+kPUFbRF3jgkNjXcQfDcZ8wu jmN4vz219m1IMhGEOohtRY9WXN/bOAz08R9QdR2aEBJjJkSZJGs1JE0Qhwxl9mgq4lCmd5IW xaZaUkll43RQYDOiMfxt+FI4LVkcfLtI7UbsdNOJSUG4RQgFPaD2ViHNQQcqyEIkbAEaI+D7 aT6EXDEqtSZgci0CqFRg7TSQM7JuDKQiBRGsdDCplkRV8G2QokvFC7epKlsQRYrwlfIc6bxQ su4MAk8WlejQUUO9gosVVc9GWvfOlmOFmdil+CjSF3UsLQslgq1oJzLlrKhRlje+RTTzMUqF EKiFaVUMYw4NZJB6GfsEz7bCRgIPdDNVqKvoblpYuNwtFuTkGGkEdDW7jJQaWUHBhCGRczID IJM8Ka0oaJsq7hDZ27QLgiiEsBCJAehXa7phadcJWKWQ4o2EDKFgsUVRgqXZuQvAtMCrwFnh VWscHJLMXQbCsTcgJ1DqcZINbTjuc2HWO0VOfYJYZmQVpWSnMZFUop7JBmUxhRnIVBWqK8F5 T/28nx+NeGeVqYhHlK4RpNjQ39hPpNEyCHKRiVRUUYC9Ayu2xIHYHf9ddlBgXQGRMNvfJSLY N1C1dv6P5mbQ3+PHcbndtPbBBf+ChniH5nUQDFpLrn8wpu+KmKpSiIOIPALbWps2XfcOLr7t 6cbxD5HKuKvSDCKpX3HfrO8Msr/EVI5Hf91PaNIS+bhJiW8GfUZ8wKIhe3NwOojxBBJ4PHOg RIzIMbRyymaqeYiDicqCtEHcZNB44pb5S2o7J+25R0Sjsdu5C2joAE+KiLQT1ohUHuRGSUio KrGFUQWEApkMYX46sS+qwVkZKmxbEAQTONXKAkSUda9GVFVhBQM0aPSN5ZOqjTUVPwlTbUrJ U8wfGVS9QVX4MtYxsNAwoZIQQw+dzFBWaiesN5BNFGJDTCgkJvvXPrRW8qeaRH2pgGTEDBnB CiQ9eC61VZASKMIiFedSF1V7cmWydInBFmudiCxcfv1uWeY/Vyrgjk5g07xzqrERbkO0rHwt ng05jESw8EVAla9ubomONIsulV5CRAishTcgpk4HhxpO3vDixHhBEPoQEjkkWGBuxghjV8Ih ruzxJ9LRvZX7DEffMlhiokhsSfc5jSHhq1TMkNMFvLoLCIPiSitTAW4zV1GGYbXvZgQ1y4Tn XVGgA14Fi1LFIzYNJpm1wEoAiYMT17CbYSHCFqu0CaEVKosJKKcEhggsT3K9UqZ0PyldYbiq opBkQWk7oITjX54bBjMCGBnDhBaWObgxaWxIbcStsNRh7WtSToVSpXSk6kzrETRRILkXVIGT GpDGkTQZYSupUS+9PiWTUkTkvumiaEWAXCC9BIzMjOhDyZE2RQWnD0EsKZzJip5bsOyQSVMA oreC4oR6xqVSSoVzkmrYIGNKYSBoZ0zUFRYAemqieYXFjA6Bq1lAbcnerUrV0lUiJ3q8qJGQ yq0eC7Q4qxcTC7z1BBSYcobEhQ00Gl5K/gTJsYI2UNA9VG0AcS6LEakktbd0a0L1QtCH/Nkc BJNNayNQjTKsiYQHioMl0d3wJLnh/rnqvTDd4DjsBniuAJ0x7SOAwDFgtahmvJeBTvy9F95I CMBSpFkK7kiJGA2zZHaWP+QtSD7mbDmQW//IV5KYIMEHbHd0x2uD2ZngVb6sGw/WifgqUHH0 CRIodpSZaDaTOQRVtlgbAuL7oNVJSmSFpaWTzy5ViizNJyuhw2Diw1yyXSZKxkJVGWBMKUUO xlFU7ZFS/uNSfmIZaeQqADMULa7HJtBWMANsf+PrPP53/oN8o+Q3V0xPWVg+TayXv9HhJAGy LuSKcKEgkzAWCg== --------------000704030300080804030201--

1 0

Re: (ITS#7250) Issue with search filter escape sequanced
by masarati＠aero.polimi.it 18 Apr '12

18 Apr '12

On 04/18/2012 02:47 PM, malleswari.nandi(a)gmail.com wrote: > Full_Name: Malleswari Nandireddy > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (206.126.170.20) > > > In our code we are using ldap_add_ext_s and ldap_search_ext_s , to add an entry > to LDAP and to search and entry in the LDAP. > > If the enter added is "00*#116cr36_1R1T1S1P1Q1" , then we we try to search using > ldap_search_ext_s , it is not returning any records. > > But when I try to search using ldapsearch , after replacing escape charecter "*" > in the string with "\2a" it is returning records. > > ./ldapsearch -h 10.29.6.33:12660 -x -b 'dc=CVGLDAP,dc=com' > 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' > > We have tried passing 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' to ldap_search_ext_s() , > but it is not returning any records. > > Please help me searching records in LDAP using ldap_search_ext_s() if the filter > has escape charecters like "*,(,)....). You're clearly missing the point between escaping in shell and in C code. However this is a user error, not an (Open)LDAP bug, so I suggest you direct your question to openldap-technical(a)openldap.org; this ITS will be closed. p. -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

(ITS#7250) Issue with search filter escape sequanced
by malleswari.nandi＠gmail.com 18 Apr '12

18 Apr '12

Full_Name: Malleswari Nandireddy Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (206.126.170.20) In our code we are using ldap_add_ext_s and ldap_search_ext_s , to add an entry to LDAP and to search and entry in the LDAP. If the enter added is "00*#116cr36_1R1T1S1P1Q1" , then we we try to search using ldap_search_ext_s , it is not returning any records. But when I try to search using ldapsearch , after replacing escape charecter "*" in the string with "\2a" it is returning records. ./ldapsearch -h 10.29.6.33:12660 -x -b 'dc=CVGLDAP,dc=com' 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' We have tried passing 'ets=1:00\2a#116cr36_1R1T1S1P1Q1' to ldap_search_ext_s() , but it is not returning any records. Please help me searching records in LDAP using ldap_search_ext_s() if the filter has escape charecters like "*,(,)....).

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs