openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Start a nNew thread

ITS#7263 published: SECURITY: ldap_bind: Invalid credentials (49)
by openldap-its＠OpenLDAP.org 06 May '12

06 May '12

Private ITS#7263 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=7263

1 0

Re: (ITS#7255) back-mdb hangs during mdb_tool_entry_modify
by hyc＠symas.com 02 May '12

02 May '12

ondrej.kuznik(a)acision.com wrote: > 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. Thanks for the report. Your fix is incomplete, a working fix is in git master now. > > 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. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs