openldap-bugs April 2013

openldap-bugs@openldap.org

27 participants
76 discussions

Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr 30 Apr '13

30 Apr '13

Re, and here are more details w/ backtrace after installing slapd-dbg : 517f9323 bdb_modify_internal: 0x000002fd: cn=g1,ou=groups,dc=example,dc=org Breakpoint 1, modify_add_values (e=e@entry=0x7ffff0f507e0, mod=mod@entry=0x7ffff87da880, permissive=1, text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830 "\030", textlen=textlen@entry=256) at ../../../../servers/slapd/mods.c:41 41 in ../../../../servers/slapd/mods.c (gdb) p *mod $10 = {sm_desc = 0x7ffff832bb20, sm_values = 0x7ffff8765760, sm_nvalues = 0x7ffff87da8c0, sm_numvals = 1, sm_op = 0, sm_flags = 1, sm_type = {bv_len = 6, bv_val = 0x7ffff82ee5c0 "member"}} (gdb) p *(mod->sm_values) $11 = {bv_len = 0, bv_val = 0x0} (gdb) bt #0 modify_add_values (e=e@entry=0x7ffff0f507e0, mod=mod@entry=0x7ffff87da880, permissive=1, text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830 "\030", textlen=textlen@entry=256) at ../../../../servers/slapd/mods.c:41 #1 0x00007ffff32110fb in hdb_modify_internal (op=op@entry=0x7ffff0f50ca0, tid=0x7ffff82db2d0, modlist=<optimized out>, e=e@entry=0x7ffff0f507e0, text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830 "\030", textlen=textlen@entry=256) at modify.c:137 #2 0x00007ffff3211df3 in hdb_modify (op=0x7ffff0f50ca0, rs=0x7ffff0f50c30) at modify.c:638 #3 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f50ca0, rs=0x7ffff0f50c30, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #4 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f50ca0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #5 0x00007ffff2be53e7 in autogroup_add_members_from_filter (op=op@entry=0x7ffff82da400, e=<optimized out>, age=0x7ffff82f8ef0, agf=agf@entry=0x7ffff87daea0, modify=modify@entry=1) at autogroup.c:519 #6 0x00007ffff2be5b00 in autogroup_add_group (op=op@entry=0x7ffff82da400, agi=agi@entry=0x7ffff832b8c0, agd=agd@entry=0x7ffff832b910, e=0x7ffff8503b98, e@entry=0x0, ndn=ndn@entry=0x7ffff82da438, scan=scan@entry=1, modify=modify@entry=1) at autogroup.c:667 #7 0x00007ffff2be6c91 in autogroup_response (op=0x7ffff82da400, rs=<optimized out>) at autogroup.c:1213 #8 0x00007ffff7f7f598 in over_back_response (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/backover.c:237 #9 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff82da400, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:507 #10 0x00007ffff7f22d6e in send_ldap_response (op=op@entry=0x7ffff82da400, rs=rs@entry=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:582 #11 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:860 #12 0x00007ffff3211e67 in hdb_modify (op=0x7ffff82da400, rs=0x7ffff0f52a50) at modify.c:749 #13 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff82da400, rs=0x7ffff0f52a50, which=op_modify, oi=0x7ffff8325c90, on=0x0) at ../../../../servers/slapd/backover.c:671 #14 0x00007ffff7f8031b in over_op_func (op=0x7ffff82da400, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #15 0x00007ffff7f2a569 in fe_op_modify (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:303 #16 0x00007ffff7f2c42d in do_modify (op=0x7ffff82da400, rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:177 #17 0x00007ffff7f12961 in connection_operation (ctx=ctx@entry=0x7ffff0f52ba0, arg_v=arg_v@entry=0x7ffff82da400) at ../../../../servers/slapd/connection.c:1150 #18 0x00007ffff7f12c84 in connection_read_thread (ctx=0x7ffff0f52ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 So sm_values looks empty at that point... Note that i've also tried with the default groupOfNames/member objects, instead of posixGroup/memberOf. Same symptoms. -- Landry Breuil

1 0

(ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr 30 Apr '13

30 Apr '13

Full_Name: Landry Breuil Version: 2.4.31 OS: Debian sid URL: Submission from: (NULL) (194.214.164.50) using slapd 2.4.31 on debian sid (with cn=config), i have an abort triggered by the following configuration : I'm using autogroup module/overlay to automatically generate posixGroup objects from various filters on my ou=people branch : dn: cn=SV_REVIEWER,ou=groups,dc=example,dc=org objectClass: labeledURIObject objectClass: posixGroup gidNumber: 10 labeledURI: ldap:///ou=people,dc=example,dc=org?uid?one?(&(objectClass=inetOrgPerson)(o=myorg)) So far, that works fine. Problem is, with that configuration i'm getting memberUid values containing only uid attributes. Now that i want to use memberOf overlay to get the reverse membership, i realize that i need my posixGroup to have DN-valued memberUid attrs. I tried using a labeledURI specifying that i want a DN returned : labeledURI: ldap:///ou=people,dc=example,dc=org?dn?one?(&(objectClass=inetOrgPerson)(o=myorg)) This errors out in autogroup_add_group after parsing the filter with : 517e6bc0 autogroup_add_group: unable to find AttributeDescription "dn". That, i can understand - a dn is not an attribute per se. Tried using a labeledURI without attr specification (as, from what i understand unless mistaken, should return the object, or its dn ?) labeledURI: ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg)) But this results in the following assertion (w/ debug trace) : 517e70d5 ==> autogroup_add_group <cn=SV_REVIEWER,ou=groups,dc=example,dc=org> ldap_url_parse_ext(ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg))) 517e70d5 >>> dnPrettyNormal: <ou=people,dc=example,dc=org> 517e70d5 <<< dnPrettyNormal: <ou=people,dc=example,dc=org>, <ou=people,dc=example,dc=org> put_filter: "(&(objectClass=inetOrgPerson)(o=myorg))" put_filter: AND put_filter_list "(objectClass=inetOrgPerson)(o=myorg)" put_filter: "(objectClass=inetOrgPerson)" put_filter: simple put_simple_filter: "objectClass=inetOrgPerson" put_filter: "(o=myorg)" put_filter: simple put_simple_filter: "o=myorg" ber_scanf fmt ({mm}) ber: ber_scanf fmt ({mm}) ber: 517e70d5 ==> autogroup_add_members_from_filter <cn=SV_REVIEWER,ou=groups,dc=example,dc=org> 517e70d5 => hdb_search 517e70d5 bdb_dn2entry("ou=people,dc=example,dc=org") 517e70d5 search_candidates: base="ou=people,dc=example,dc=org" (0x00000005) scope=1 517e70d5 => hdb_dn2idl("ou=people,dc=example,dc=org") 517e70d5 => bdb_equality_candidates (objectClass) 517e70d5 => key_read 517e70d5 <= bdb_index_read: failed (-30987) 517e70d5 <= bdb_equality_candidates: id=0, first=0, last=0 517e70d5 => bdb_equality_candidates (objectClass) 517e70d5 => key_read 517e70d5 <= bdb_index_read 738 candidates 517e70d5 <= bdb_equality_candidates: id=738, first=6, last=763 517e70d5 => bdb_equality_candidates (o) 517e70d5 <= bdb_equality_candidates: (o) not indexed 517e70d5 bdb_search_candidates: id=437 first=6 last=763 517e70d5 ==> autogroup_member_search_modify_cb <uid=user1,ou=people,dc=example,dc=org> 517e70d5 ==> autogroup_member_search_modify_cb <uid=user2,ou=people,dc=example,dc=org> 517e70d5 hdb_search: 288 does not match filter .... 517e70d5 hdb_search: 762 does not match filter 517e70d5 hdb_search: 763 does not match filter 517e70d5 send_ldap_result: conn=1000 op=8 p=3 517e70d5 bdb_dn2entry("cn=sv_reviewer,ou=groups,dc=example,dc=org") 517e70d5 bdb_entry_get: rc=0 517e70d5 bdb_dn2entry("cn=sv_reviewer,ou=groups,dc=example,dc=org") 517e70d5 bdb_modify_internal: 0x000002e0: cn=SV_REVIEWER,ou=groups,dc=example,dc=org slapd: ../../../../servers/slapd/mods.c:64: modify_add_values: Assertion `mod->sm_numvals == i' failed. How can i achieve the desired setup ? Fix autogroup to allow asking for a dn, or try to see why slapd blows in modify_add_values when not asking for a specific attribute ?

1 0

Re: (ITS#7579) back-sql does not update DIT when DB is updated
by masarati＠aero.polimi.it 29 Apr '13

29 Apr '13

On 04/29/2013 02:33 PM, mail(a)benjamin-behringer.de wrote: > Full_Name: Benjamin Behringer > Version: 2.4.35 > OS: Ubuntu 12.04 64bit > URL: > Submission from: (NULL) (2001:7c0:409:8eaa:cb:7a6a:91f0:f867) > > > Hi, > > I'm using OpenLDAP and back-sql to make the information, stored in a MySQL > Database, available over LDAP (for Authentication purposes). Unfortunately, when > I insert or update an entry in the Database, the DIT is not updated. In > contrast, a delete on the ldap_entries table will cause slapd to reflect the DB > change in the DIT. The issue only occurs, when the DIT has already been loaded, > and the subtree you will make the change to has already been read at least once. > If you restart slapd, the changes are reflected. > > Software Versions: > > Distribution: Ubuntu 12.04 64bit > MySQL: 5.5.31-0ubuntu0.12.04.1 > OpenLDAP: 2.4.35 > libmyodbc: 5.2.4 > unixodbc: 2.3.0-2ubuntu1 > > Here are > > a sample configuration file: > http://pastebin.de/34104 > > odbc config files: > http://pastebin.de/34103 > > sample db script: > http://pastebin.de/34101 > > and insert script: > http://pastebin.de/34102 > > Is there a patch, workaround, anything? There is no caching of the contents of ldap_entries in back-sql; maybe some caching at the odbc level? p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7579) back-sql does not update DIT when DB is updated
by mail＠benjamin-behringer.de 29 Apr '13

29 Apr '13

Full_Name: Benjamin Behringer Version: 2.4.35 OS: Ubuntu 12.04 64bit URL: Submission from: (NULL) (2001:7c0:409:8eaa:cb:7a6a:91f0:f867) Hi, I'm using OpenLDAP and back-sql to make the information, stored in a MySQL Database, available over LDAP (for Authentication purposes). Unfortunately, when I insert or update an entry in the Database, the DIT is not updated. In contrast, a delete on the ldap_entries table will cause slapd to reflect the DB change in the DIT. The issue only occurs, when the DIT has already been loaded, and the subtree you will make the change to has already been read at least once. If you restart slapd, the changes are reflected. Software Versions: Distribution: Ubuntu 12.04 64bit MySQL: 5.5.31-0ubuntu0.12.04.1 OpenLDAP: 2.4.35 libmyodbc: 5.2.4 unixodbc: 2.3.0-2ubuntu1 Here are a sample configuration file: http://pastebin.de/34104 odbc config files: http://pastebin.de/34103 sample db script: http://pastebin.de/34101 and insert script: http://pastebin.de/34102 Is there a patch, workaround, anything? Regards

1 0

Re: (ITS#7577) hdb and mdb derefere aliases differently
by hyc＠symas.com 28 Apr '13

28 Apr '13

juergen.sprenger(a)swisscom.com wrote: > Full_Name: Juergen Sprenger > Version: 2.4.35 > OS: Gentoo Base System release 2.1, Kernel 3.7.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.5.238.18) > > > mdb dereference aliases problem. A fix for this is now in git master, please test, thanks. commit fb537d747c6fd43e08986e99b1fe7781660feaf3 > > I use aliases to keep information about a person who has multiple accounts > consistent over all accounts and avoid redundancy, example: > > dn: uid=joe,ou=Account,dc=its,dc=scom > objectClass: alias > objectClass: extensibleObject > uid: joe > aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom > structuralObjectClass: alias > > When using hdb as backend for slapd everything works fine, and user are > authenticated properly: > # running 'getent passwd' with hdb backend: > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0 > text= > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH > base="ou=account,dc=its,dc=scom" scope=1 deref=3 > filter="(objectClass=posixAccount)" > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid > userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos > description objectClass > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101 > err=0 nentries=656 text= > Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection > lost) > > When using mdb as backend with same directory content, users are no longer > authenticated, search returns nentries=0: > > # running 'getent passwd' with mdb backend: > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND > dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0 > text= > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH > base="ou=account,dc=its,dc=scom" scope=1 deref=3 > filter="(objectClass=posixAccount)" > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid > userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos > description objectClass > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101 > err=0 text= > Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection > lost) > > Both setups have identical md5sum of slapcat output, so directory content can be > assumed identical in my opinion. > > > -- -- 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#7567) Alias dereferencing slowness
by hyc＠symas.com 28 Apr '13

28 Apr '13

luca.scamoni(a)gruppopa.it wrote: > Full_Name: Luca Scamoni > Version: 2.4.35 > OS: Linux > URL: ftp://www.sys-net.it/alias-deref-ITS2.tar.gz > Submission from: (NULL) (78.134.117.13) > > > Investigating alias dereferencing slowness on a customer production system I > came upon a suspect behaviour with back-hdb/bdb. > It seems that slapd, when dereferencing, instead of looking for the exact > aliased DN, starts scanning more entries than needed (at least this is what I > can tell looking to the logs set to log anything) > On the customer system, with over 700,000 entries, the time taken to perform a > simple search with alias dereferencing for a single entry, takes as much as > performing a full ldapsearch of the entire ldap tree. > To reproduce I created a small testcase (that I can't upload because there's no > space left on ftp.openldap.org/incoming). The test case contains also the log > and the operations performed on test data to show the issue. > I tested with openldap 2.4.23, 2.4.31 and 2.4.35. The issue is present in all > versions but seems to manifest itself only with back-bdb/hdb. Back-mdb seems not > to show the issue (even looking at the logs) but right now, moving to back-mdb > is not something the customer is ready to take. I would not recommend switching to back-mdb at this time, see ITS#7577. Alias dereferencing is broken in a few cases in back-mdb. Meanwhile, in back-bdb/hdb, it also depends on whether you're searching with Deref set to Finding, Searching or Always. Deref/Finding works in all 3 backends (bdb/hdb/mdb). (Deref/Searching in back-mdb was mainly broken by the patches in ITS#7473.) When Deref is set to Searching/Always, the backend must find every alias within the target search scope and dereference them. This deref can potentially expand the scope of the search, e.g. if the alias points to a completely different subtree. If you have a lot of aliases in the tree, this is likely going to be very slow. -- -- 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#7578) delta-sync multimaster replication issue
by afrunning＠gmail.com 26 Apr '13

26 Apr '13

Full_Name: Al F Version: 2.4.35 OS: Redhat 6.4 - x64 URL: https://dl.dropboxusercontent.com/u/982376/its/al-f-130426.zip Submission from: (NULL) (74.123.146.10) Hi, I have a multimaster system utilizing delta-sync for replication. The system is utilizing mdb for both the user and the accesslog data. I have ppolicy & memberof overlays enabled as well. all of my writes are directed at a single server using a load balancer. I have found that when a user has a pwdFailureTime attribute set on their entry, if an administrator resets the password, "null_callback : error code 0x10" is produced in the log on the secondary system and the secondary system goes into refresh mode. The mentioned zip file contains most of my configuration as well a portion of the log when the issue occurred. The log was generated during a failure with -d-1 to slapd. I have a lot more log from before and after the issue however it is littered with sensitive data, so I didn't want to redact it unless necessary. Please let me know what else I can do to help. Regards, Al

1 0

Re: ITS#7552
by Matthew.Monaco＠colorado.edu 24 Apr '13

24 Apr '13

This is a multi-part message in MIME format. --------------010002070300090900000609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Caching queries with * attributes broken (compiled from 260fd69, RE24 HEAD). This works: ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \ '(&(objectClass=posixAccount)(uid=matt)' This does not: ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \ '(&(objectClass=posixAccount)(uid=matt)' uid I also have a problem where the attribute set is set to (nssov_passwd_byname): uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass For this, nssov does not work (I see cacheable, but the query never gets cached). However, this does work: ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \ '(&(objectClass=posixAccount)(uid=matt)' uid (Also, test020 passes) --------------010002070300090900000609 Content-Type: text/plain; charset=UTF-8; name="slapd-master.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-master.conf" ######## ## ## CSEL ## ## # Modules #modulepath /usr/lib/ldap moduleload back_mdb.so moduleload nssov.so ## # Schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/ldapns.schema ## # System pidfile /run/slapd/slapd.pid argsfile /run/slapd/slapd.args loglevel 256 sizelimit 5000 TLSCACertificateFile /etc/openldap/ldap-csel-ca.crt TLSCertificateFile /etc/openldap/ldap-csel.crt TLSCertificateKeyFile /etc/openldap/ldap-csel.key ## # ACLs access to attrs=userPassword by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage by self =xw by anonymous auth by * none #access to dn.children="ou=users,dc=cs,dc=colorado,dc=edu" # by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage # by self read # by * none #access to dn.children="ou=groups,dc=cs,dc=colorado,dc=edu" attrs=memberUid # by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage # by users search # by * none access to * by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage by users read by * read ## # Backend (mdb) database mdb directory /var/lib/openldap/csel.mdb maxsize 1073741824 suffix dc=cs,dc=colorado,dc=edu index default eq index objectClass index cn index uid index uidNumber index gidNumber index memberUid index uniqueMember index entryCSN ## # Overlay (nssov) overlay nssov nssov-ssd passwd ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd shadow ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd group ldap:///ou=groups,dc=cs,dc=colorado,dc=edu??one nssov-ssd hosts ldap:///ou=hosts,dc=cs,dc=colorado,dc=edu??one --------------010002070300090900000609 Content-Type: text/plain; charset=UTF-8; name="slapd-client.conf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="slapd-client.conf" ####### ## ## CSEL ## ## # Modules moduleload back_ldap.so moduleload back_mdb.so moduleload pcache.so moduleload nssov.so ## # Schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/ldapns.schema ## # System pidfile /run/slapd/slapd.pid argsfile /run/slapd/slapd.args sizelimit 10000 ## # Backend (ldap) database ldap uri ldaps://xxx.colorado.edu/ tls ldaps tls_reqcert=allow suffix dc=cs,dc=colorado,dc=edu rootdn cn=pcache,ou=sys,dc=cs,dc=colorado,dc=edu ## # Overlay (proxy cache) overlay pcache pcache mdb 10000 1 256 120 pcacheOffline TRUE directory /var/lib/openldap/pcache.mdb maxsize 67108864 index default eq index objectClass index cn index uid index uidNumber index gidNumber index memberUid index uniqueMember pcacheAttrset 0 * pcacheTemplate (&(objectClass=)(uid=)) 0 3600 ## # Overlay (nssov) overlay nssov nssov-ssd passwd ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd shadow ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one nssov-ssd group ldap:///ou=groups,dc=cs,dc=colorado,dc=edu??one nssov-ssd hosts ldap:///ou=hosts,dc=cs,dc=colorado,dc=edu??one --------------010002070300090900000609--

1 0

(ITS#7577) hdb and mdb derefere aliases differently
by juergen.sprenger＠swisscom.com 24 Apr '13

24 Apr '13

Full_Name: Juergen Sprenger Version: 2.4.35 OS: Gentoo Base System release 2.1, Kernel 3.7.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.5.238.18) mdb dereference aliases problem. I use aliases to keep information about a person who has multiple accounts consistent over all accounts and avoid redundancy, example: dn: uid=joe,ou=Account,dc=its,dc=scom objectClass: alias objectClass: extensibleObject uid: joe aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom structuralObjectClass: alias When using hdb as backend for slapd everything works fine, and user are authenticated properly: # running 'getent passwd' with hdb backend: Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0 text= Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)" Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=656 text= Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection lost) When using mdb as backend with same directory content, users are no longer authenticated, search returns nentries=0: # running 'getent passwd' with mdb backend: Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128 Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0 Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0 text= Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH base="ou=account,dc=its,dc=scom" scope=1 deref=3 filter="(objectClass=posixAccount)" Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos description objectClass Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 text= Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection lost) Both setups have identical md5sum of slapcat output, so directory content can be assumed identical in my opinion.

1 0

Re: (ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by tedcheng＠symas.com 23 Apr '13

23 Apr '13

--Apple-Mail-2--242372278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Apr 14, 2013, at 6:39 AM, Hallvard Breien Furuseth wrote: >=20 > You can instead look for a mechanism with built-in credential passing, > apparently like Solaris "doors". =20 The sample client-server programs, see link below, show an experiment on = Solaris 8 that server creates and listens to door calls, while client = invokes them. When client invokes a door_call, server gets the euid and = egid, among others, of the client: https://dl.dropboxusercontent.com/u/94235048/door_call.tgz http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.html # ./server successfully created a door euid (101) egid (1) ruid (101) rgid (1) pid (8947) $ id uid=3D101(tedcheng) gid=3D1(other) $ ./client pid (8947): door_call succeeded There is the situation in which we are sending/getting client = credentials from a door call through say /tmp/door, while service = requests, such as nssov/nslcd (nss-pam-ldapd), through a separate Unix = domain socket. There is therefore the need to tie client credentials = with their respective (name) service requests; "doors" implements its = own threading support. The work to integrate doors for client credential = support into a server with threading support, such as slapd, may get = complicated fast. "Doors" does not seem to be a feasible solution for sending client = credentials in a context such as nssov/slapd. > Or look at what some other well-tested > and portable package does and suggest we steal its code.=20 >=20 This may be the only option, if there exists one, for older-system = support (Solaris 8). Ted C. Cheng Symas Corporation --Apple-Mail-2--242372278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = "><div><div>On Apr 14, 2013, at 6:39 AM, Hallvard Breien Furuseth = wrote:</div><blockquote type=3D"cite"><div><font = class=3D"Apple-style-span" color=3D"#000000"><br></font>You can instead = look for a mechanism with built-in credential passing,<br>apparently = like Solaris "doors". =  </div></blockquote><div><br></div><div><div>The = sample client-server programs, see link below, show an experiment = on Solaris 8 that server creates and listens to door calls, while client = invokes them. When client invokes a door_call, server gets the euid and = egid, among others, of the client:</div><div><br></div><div><a = href=3D"https://dl.dropboxusercontent.com/u/94235048/door_call.tgz">https:= //dl.dropboxusercontent.com/u/94235048/door_call.tgz</a></div><div><br></d= iv><div><a = href=3D"http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.= html">http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.ht= ml</a></div><div><br></div><div># ./server<br>successfully created a = door<br>euid (101) egid (1) ruid (101) rgid (1) pid (8947)<br><br>$ = id<br>uid=3D101(tedcheng) gid=3D1(other)<br>$ ./client<br>pid (8947): = door_call succeeded</div><div><br></div><div>There is the situation = in which we are sending/getting client credentials from a door call = through say /tmp/door, while service requests, such as nssov/nslcd = (nss-pam-ldapd), through a separate Unix domain socket. There is = therefore the need to tie client credentials with their respective = (name) service requests; "doors" implements its own threading = support. The work to integrate doors for client credential support into = a server with threading support, such as slapd, may get complicated = fast.</div><div><br></div><div>"Doors" does not seem to be a feasible = solution for sending client credentials in a context such as = nssov/slapd.</div></div><br><blockquote type=3D"cite"><div>Or look at = what some other well-tested<br>and portable package does and suggest we = steal its code. <font class=3D"Apple-style-span" = color=3D"#006312"><br></font></div></blockquote><blockquote = type=3D"cite"><div><br></div></blockquote><br></div><div>This may be the = only option, if there exists one, for older-system support (Solaris = 8).</div><div><br></div><div><br></div><div><div>Ted C. = Cheng</div><div>Symas = Corporation</div></div><div><br></div><div><br></div></body></html>= --Apple-Mail-2--242372278--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2013