openldap-bugs March 2010

openldap-bugs@openldap.org

31 participants
72 discussions

Re: (ITS#6486) OpenLDAP Admin Guide Backends Documentation
by ghenry＠OpenLDAP.org 05 Mar '10

05 Mar '10

Thanks Ryan. I'll make sure this gets updated when I work through updating everything for cn=config syntax. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6487) Nssov pam_authz authorizedUserService
by crispy＠cluenet.org 04 Mar '10

04 Mar '10

Full_Name: Chris Breneman Version: 2.4.21 OS: Debian Lenny URL: http://paste.cluenet.org/pastebin.php?dl=2648 Submission from: (NULL) (98.212.227.43) My organization needs the capability of per-user (instead of per-group) access control with nssov. Using the method of modifying slapd ACLs to grant or revoke compare privileges on the authorizedService attribute of the host object is not scalable with large numbers of users, each of which have individual access. This patch adds an attribute "authorizedUserService" for use in a host entry. The attribute is in the form of "UID:SERVICE". If an attribute value for the user and service exists, access is granted. Otherwise access is denied. Wildcards in the form of "UID:*", "*:UID", and "*:*" are also supported. This patch also fixes a minor bug in the pam_authz function. Currently, one of the values read from NSCLD is used as a string in a Debug statement without initializing a NULL terminator. The patch extends the lengths of each buffer by 1 and initializes them to 0 so each buffer is always null-terminated and can be used as a string. The patch applies to the latest CVS HEAD as of this report, since several changes have been made in that region of code since 2.4.21. The patch is at http://paste.cluenet.org/pastebin.php?dl=2648 or http://paste.cluenet.org/2648

1 0

Re: (ITS#6485) nssov pam_authz fixes
by hyc＠symas.com 03 Mar '10

03 Mar '10

crispy(a)cluenet.org wrote: > Full_Name: Chris Breneman > Version: 2.4.21 > OS: Debian Lenny > URL: > Submission from: (NULL) (98.212.227.43) > > > In pam_authz(), in pam.c, in nssov, there are two problems: > > 1. Values in the service buffer are overwritten, and values in several other > buffers are never stored, preventing authorizedService checking from working. > 2. pam_authz() fails if nssov is not first used for authentication. Thanks for reporting these, fixes are in HEAD. -- -- 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#6433) patch for the sha2 module: hash methods for passwords generation
by hyc＠symas.com 03 Mar '10

03 Mar '10

cdelfosse(a)mandriva.com wrote: > Full_Name: Cédric Delfosse > Version: HEAD > OS: Mandriva Linux > URL: ftp://ftp.openldap.org/incoming/cedric-delfosse-091221.patch > Submission from: (NULL) (62.212.120.90) > > > Hello, > > this patch allows to use the {SHA256}, {SHA384} and {SHA512} password schemes > (provided by the sha2 module) with LDAP Password Modify Extended Operations. > This patch contains the required hash methods. > > This patch file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Mandriva. Mandriva has not assigned rights and/or interest in this work to any > party. I, Cédric Delfosse am authorized by Mandriva, my employer, to release > this work under the following terms. > > Mandriva hereby place the following modifications to OpenLDAP Software (and only > these modifications) into the public domain. Hence, these modifications may be > freely used and/or redistributed for any purpose with or without attribution > and/or other notice. > > Regards, > > Cédric > Thanks, nice work. Committed in HEAD. -- -- 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#6486) OpenLDAP Admin Guide Backends Documentation
by ryans＠aweber.com 03 Mar '10

03 Mar '10

Full_Name: Ryan Steele Version: 2.4.18 OS: Ubuntu Server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) The Admin Guide section on backends is inconsistent in terms of specifying the moduleload statement, and whether or not it is required for any arbitrary backend. For example, the documentation on back-ldif explicitly states that it is not needed: >You'll notice that when compared to examples below, there is no: > > moduleload back_ldif.la > >directive. This is because back_ldif is always built in by default as it is used by >slapd-config(5), which again is built in by default. This is in contrast to the monitor backend configuration section where it is noted as being required: >You can however set a rootdn and rootpw. The following is all that is needed to >instantiate a monitor backend: > > include ./schema/core.schema > > modulepath /usr/local/libexec/openldap > moduleload back_monitor.la > > database monitor > rootdn "cn=monitoring,cn=Monitor" > rootpw monitoring Or, in the back-ldap configuration section, where mention is omitted entirely: > database ldap > suffix "dc=suretecsystems,dc=com" > rootdn "cn=slapd-ldap" > uri ldap://localhost/ ldap://remotehost ldap://remotehost2 I should note that this ITS is not referring sections in which the configuration section for a backend is missing entirely (such as back-meta), because IMHO the lack of information there precludes it from being subject to the aforementioned ambiguity. I made sure to check with #openldap on Freenode (2010-03-03, 14:05 EST) before submitting this ITS, and have made sure to obtain Howard's blessing: <hyc> go ahead and submit an ITS. I don't think you need to attach a patch. <hyc> probably we'll just add a bluurb at the top "if your installation uses dynamic modules, you may need to add the relevant moduleload directives to the following examples" <hyc> and leave it at that.

1 0

(ITS#6485) nssov pam_authz fixes
by crispy＠cluenet.org 02 Mar '10

02 Mar '10

Full_Name: Chris Breneman Version: 2.4.21 OS: Debian Lenny URL: Submission from: (NULL) (98.212.227.43) In pam_authz(), in pam.c, in nssov, there are two problems: 1. Values in the service buffer are overwritten, and values in several other buffers are never stored, preventing authorizedService checking from working. 2. pam_authz() fails if nssov is not first used for authentication.

1 0

(ITS#6484) slapd 2.4.21 + pcache + rwm coredump
by mhardin＠symas.com 02 Mar '10

02 Mar '10

Full_Name: Matt Hardin Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.215.92.245) A naming context that uses back-ldap, slapo-rwm, and slapo-pcache dumps core when asked to perform an operation. Configuration snippets: database ldap suffix "dc=ad,dc=example,dc=com" subordinate rootdn "dc=ad,dc=example,dc=com" uri "ldaps://ldap01.example.com ldaps://ldap02.example.com" norefs yes chase-referrals no conn-ttl 300 network-timeout 10 use-temporary-conn yes # Identity assertion: connections authenticated as either of the two identities # below will connect to AD as the proxy user. Connections authenticated as # anything else (i.e., AD users) use those credentials for authentication. idassert-bind bindmethod=simple binddn="cn=cnsproxy,dc=example,dc=com" credentials=xxxxxx mode=legacy flags=override idassert-authzFrom "dn.regex:cn=proxy,dc=example,dc=com" # It is necessary to map a number of objectclass and attribute names to # various other names that are supported in RFC2307. We also take this # opportunity to 'lose' certain other attributes that have no place in # UNIX. overlay rwm rwm-normalize-mapped-attrs yes rwm-suffixmassage "dc=ad,dc=example,dc=com" "dc=example,dc=com" rwm-map objectClass posixAccount user rwm-map attribute uid samAccountName rwm-map attribute "" gecos [lots of rwm-map statements removed] # Caching setup overlay pcache proxycache hdb 100000 2 10000 50000 proxycachequeries 20000 proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass memberUid member proxyattrset 1 * # proxytemplate (&(objectClass=)(uid=)) 0 3600 300 proxytemplate (&(objectClass=)(uid=)) 1 3600 300 proxytemplate (&(objectClass=)(uidNumber=)) 0 3600 300 proxytemplate (&(objectClass=)(member=)) 0 3600 300 proxytemplate (&(objectClass=)(|(memberUid=)(member=))) 0 3600 300 proxytemplate (uid=) 0 3600 300 proxytemplate (&(objectClass=)(cn=)) 0 3600 300 proxytemplate (&(objectClass=)(gidNumber=)) 0 3600 300 proxytemplate (objectClass=*) 0 3600 300 # directory /var/symas/openldap-data/example-pcache cachesize 10000 idlcachesize 10000 checkpoint 512 600 sizelimit unlimited index objectClass eq index cn,sn,uid eq index uidNumber eq index gidNumber eq index memberUid eq index member eq index queryid eq dbconfig set_cachesize 0 536870912 0 dbconfig set_flags DB_LOG_AUTOREMOVE dbconfig set_lg_max 10485760 dbconfig set_lg_bsize 2097152 Backtrace is as follows: (gdb) thr apply all bt Thread 5 (process 19756): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00abc297 in pthread_join () from /lib/tls/libpthread.so.0 #2 0x00608524 in ldap_pvt_thread_join (thread=4294967292, thread_return=0xfffffffc) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:197 #3 0x0806f48a in slapd_daemon () at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/daemon.c:2840 #4 0x0805896d in main (argc=7, argv=0xbfe4d694) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/main.c:961 Thread 4 (process 19757): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0070a1ce in epoll_wait () from /lib/tls/libc.so.6 #2 0x0806e505 in slapd_daemon_task (ptr=0x0) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/daemon.c:2465 #3 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 #4 0x00709b4e in clone () from /lib/tls/libc.so.6 Thread 3 (process 19759): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00abdcf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x00608664 in ldap_pvt_thread_cond_wait (cond=0xfffffffc, mutex=0xfffffffc) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00607822 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:672 #4 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #5 0x00709b4e in clone () from /lib/tls/libc.so.6 Thread 2 (process 19760): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00abdcf6 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/libpthread.so.0 #2 0x00608664 in ldap_pvt_thread_cond_wait (cond=0xfffffffc, mutex=0xfffffffc) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00607822 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:672 #4 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 #5 0x00709b4e in clone () from /lib/tls/libc.so.6 Thread 1 (process 19758): #0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00665825 in raise () from /lib/tls/libc.so.6 #2 0x00667289 in abort () from /lib/tls/libc.so.6 #3 0x0065eda1 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0807bc34 in entry_clean (e=0x835ccdc) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/entry.c:483 #5 0x0807bc52 in entry_free (e=0x835ccdc) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/entry.c:514 #6 0x080da90e in overlay_entry_release_ov (op=0x838b5a0, e=0x835ccdc, rw=0, on=0x82fcb50) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:439 #7 0x0093aa55 in rwm_send_entry (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/rwm.c:1508 #8 0x0093b129 in rwm_response (op=0x838b5a0, rs=0x6) ---Type <return> to continue, or q <return> to quit--- at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/rwm.c:1700 #9 0x080da44a in over_back_response (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:237 #10 0x08081be0 in slap_response_play (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/result.c:358 #11 0x0808439b in slap_send_search_entry (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/result.c:843 #12 0x00bd8005 in hdb_search (op=0x838b5a0, rs=0x3a1a100) at search.c:961 #13 0x00a7d495 in pcache_op_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/pcache.c:3029 #14 0x080dad59 in overlay_op_walk (op=0x838b5a0, rs=0x3a1a100, which=op_search, oi=0x82fca50, on=0x8303408) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:659 #15 0x080daebc in over_op_func (op=0x838b5a0, rs=0x3a1a100, which=op_search) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:721 #16 0x080d8f18 in glue_op_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backglue.c:457 #17 0x080dad59 in overlay_op_walk (op=0x838b5a0, rs=0x3a1a100, which=op_search, oi=0x8302778, on=0x8302878) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:659 #18 0x080daebc in over_op_func (op=0x838b5a0, rs=0x3a1a100, which=op_search) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:721 #19 0x08074b36 in fe_op_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/search.c:366 #20 0x08074041 in do_search (op=0x838b5a0, rs=0x3a1a100) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/search.c:217 #21 0x08072205 in connection_operation (ctx=0x3a1a210, arg_v=0x838b5a0) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/connection.c:1109 ---Type <return> to continue, or q <return> to quit--- #22 0x08072b54 in connection_read_thread (ctx=0x3a1a210, argv=0x18) at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/connection.c:1245 #23 0x006077c6 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0) at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:685 #24 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0 #25 0x00709b4e in clone () from /lib/tls/libc.so.6 (gdb) q Commentary from debugging session: the entry in question is owned by pcache's cache DB and the overlay_entry_release() function didn't fall into the right release hook because the pcache overlay didn't provide one so this has to be fixed by adding a release hook to pcache not a big deal. so the fault isn't in rwm this time, it's calling the right API

1 0

Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 01 Mar '10

01 Mar '10

--=-wu98lDL/cs9xvAtVkpXf Content-Type: multipart/mixed; boundary="=-bGZqaJas0lpiam3pf2jA" --=-bGZqaJas0lpiam3pf2jA Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2010-03-02 at 15:30 +1100, Andrew Bartlett wrote: > On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: > > [Resending because I forgot the ITS number in the subject] > >=20 > > I have a simple prototype that on add/modrdn populates/maintains an > > attribute (rdnValue) with the distinguished values of the naming > > attributes of the RDN. While doing this, it also checks for uniqueness= of > > the rdnValue value within siblings. > >=20 > > You can find it here > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.= 2.c> > >=20 > > Please test and comment. I hope it does what intended. >=20 > I'm starting to look at this now. I'm sorry so many months have past > since you posted it. I've now added it into Samba's provision, and using the diff I attach, against current 'master', I get the attached error. It seems to be unable to add the base DN. (The very first entry in the database). Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-bGZqaJas0lpiam3pf2jA Content-Disposition: attachment; filename="rdnval-use-in-samba.diff" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="rdnval-use-in-samba.diff"; charset="UTF-8" ZGlmZiAtLWdpdCBhL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zYW1iYV9kc2RiLmMg Yi9zb3VyY2U0L2RzZGIvc2FtZGIvbGRiX21vZHVsZXMvc2FtYmFfZHNkYi5jDQppbmRleCBjOTI5 ZDY1Li5jOGQ1YjkzIDEwMDY0NA0KLS0tIGEvc291cmNlNC9kc2RiL3NhbWRiL2xkYl9tb2R1bGVz L3NhbWJhX2RzZGIuYw0KKysrIGIvc291cmNlNC9kc2RiL3NhbWRiL2xkYl9tb2R1bGVzL3NhbWJh X2RzZGIuYw0KQEAgLTE3NSw3ICsxNzUsNiBAQCBzdGF0aWMgaW50IHNhbWJhX2RzZGJfaW5pdChz dHJ1Y3QgbGRiX21vZHVsZSAqbW9kdWxlKQ0KIAkJCQkJICAgICAiYXNxIiwNCiAJCQkJCSAgICAg ImV4dGVuZGVkX2RuX3N0b3JlIiwNCiAJCQkJCSAgICAgImV4dGVuZGVkX2RuX2luIiwNCi0JCQkJ CSAgICAgInJkbl9uYW1lIiwNCiAJCQkJCSAgICAgIm9iamVjdGNsYXNzIiwNCiAJCQkJCSAgICAg ImRlc2NyaXB0b3IiLA0KIAkJCQkJICAgICAiYWNsIiwNCkBAIC0xOTEsNiArMTkwLDcgQEAgc3Rh dGljIGludCBzYW1iYV9kc2RiX2luaXQoc3RydWN0IGxkYl9tb2R1bGUgKm1vZHVsZSkNCiAJY29u c3QgY2hhciAqKmxpbmtfbW9kdWxlczsNCiAJc3RhdGljIGNvbnN0IGNoYXIgKnRkYl9tb2R1bGVz X2xpc3RbXSA9IHsNCiAJCSJzdWJ0cmVlX2RlbGV0ZSIsDQorCQkicmRuX25hbWUiLA0KIAkJInJl cGxfbWV0YV9kYXRhIiwNCiAJCSJzdWJ0cmVlX3JlbmFtZSIsDQogCQkibGlua2VkX2F0dHJpYnV0 ZXMiLA0KZGlmZiAtLWdpdCBhL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVf bGRhcF9tYXAuYyBiL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVfbGRhcF9t YXAuYw0KaW5kZXggYmY5Y2Q0Zi4uNWVjN2E0YSAxMDA2NDQNCi0tLSBhL3NvdXJjZTQvZHNkYi9z YW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVfbGRhcF9tYXAuYw0KKysrIGIvc291cmNlNC9kc2RiL3Nh bWRiL2xkYl9tb2R1bGVzL3NpbXBsZV9sZGFwX21hcC5jDQpAQCAtMjg3LDcgKzI4Nyw3IEBAIHN0 YXRpYyBjb25zdCBzdHJ1Y3QgbGRiX21hcF9hdHRyaWJ1dGUgZW50cnl1dWlkX2F0dHJpYnV0ZXNb XSA9DQogCQkudHlwZSA9IExEQl9NQVBfUkVOQU1FLA0KIAkJLnUgPSB7DQogCQkJLnJlbmFtZSA9 IHsNCi0JCQkJIC5yZW1vdGVfbmFtZSA9ICJzYW1iYTRSRE4iDQorCQkJCSAucmVtb3RlX25hbWUg PSAicmRudmFsIg0KIAkJCSB9DQogCQl9DQogCX0sDQpkaWZmIC0tZ2l0IGEvc291cmNlNC9zZXR1 cC9zY2hlbWEtbWFwLW9wZW5sZGFwLTIuMyBiL3NvdXJjZTQvc2V0dXAvc2NoZW1hLW1hcC1vcGVu bGRhcC0yLjMNCmluZGV4IDBkMzg2NTIuLmFlZDU0MDIgMTAwNjQ0DQotLS0gYS9zb3VyY2U0L3Nl dHVwL3NjaGVtYS1tYXAtb3BlbmxkYXAtMi4zDQorKysgYi9zb3VyY2U0L3NldHVwL3NjaGVtYS1t YXAtb3BlbmxkYXAtMi4zDQpAQCAtMTUsNiArMTUsOSBAQCB1aWROdW1iZXINCiBnaWROdW1iZXIN CiAjVGhlIG1lbWJlck9mIHBsdWdpbiBwcm92aWRlcyB0aGlzIGF0dHJpYnV0ZQ0KIG1lbWJlck9m DQorIyduYW1lJyBpcyB0aGUgUkROIGluIEFELCBidXQgc29tZXRoaW5nIGVsc2UgaW4gT3BlbkxE QVAuICBTa2lwIGFuZA0KKyMgdXNlIHRoZSBPcGVuTERBUCBvbmUNCituYW1lDQogI1RoZXNlIGNv bmZsaWN0IHdpdGggT3BlbkxEQVAgYnVpbHRpbnMNCiBhdHRyaWJ1dGVUeXBlczpzYW1iYTRBdHRy aWJ1dGVUeXBlcw0KIDIuNS4yMS41OjEuMy42LjEuNC4xLjcxNjUuNC4yNTUuNw0KQEAgLTI0LDgg KzI3LDYgQEAgb2JqZWN0Q2xhc3NlczpzYW1iYTRPYmplY3RDbGFzc2VzDQogMi41LjIxLjY6MS4z LjYuMS40LjEuNzE2NS40LjI1NS41DQogc3ViU2NoZW1hOnNhbWJhNFN1YlNjaGVtYQ0KIDIuNS4y MC4xOjEuMy42LjEuNC4xLjcxNjUuNC4yNTUuNA0KLSMnbmFtZScgaXMgdGhlIFJETiBpbiBBRCwg YnV0IHNvbWV0aGluZyBlbHNlIGluIE9wZW5MREFQDQotbmFtZTpzYW1iYTRSRE4NCiAjUmVtYXAg dGhlc2Ugc28gdGhhdCB3ZSBkb24ndCBwdXQgb3BlcmF0aW9uYWwgYXR0cmlidXRlcyBpbiBhIHNj aGVtYSBNQVkNCiBtb2RpZnlUaW1lU3RhbXA6c2FtYmE0TW9kaWZ5VGltZXN0YW1wDQogMi41LjE4 LjI6MS4zLjYuMS40LjEuNzE2NS40LjI1NS4zDQpkaWZmIC0tZ2l0IGEvc291cmNlNC9zZXR1cC9z bGFwZC5jb25mIGIvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQppbmRleCAwMDc3YTIyLi5lNWZj ZDA2IDEwMDY0NA0KLS0tIGEvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQorKysgYi9zb3VyY2U0 L3NldHVwL3NsYXBkLmNvbmYNCkBAIC00OSw2ICs0OSw3IEBAIGRlZmF1bHRzZWFyY2hiYXNlICR7 RE9NQUlORE59DQogcm9vdGRuIGNuPU1hbmFnZXINCiANCiBvdmVybGF5IGRlcmVmDQorb3Zlcmxh eSByZG52YWwNCiANCiAke1JFRklOVF9DT05GSUd9DQogDQo= --=-bGZqaJas0lpiam3pf2jA Content-Disposition: attachment; filename="rdnval-errors.txt" Content-Transfer-Encoding: base64 Content-Type: text/plain; name="rdnval-errors.txt"; charset="UTF-8" PT4gZ2V0X2N0cmxzDQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX2R1bXA6IGJ1Zj0weDE2 MjlmMjAgcHRyPTB4MTYyYTkwMSBlbmQ9MHgxNjJhOTFlIGxlbj0yOQ0KICAwMDAwOiAgMzAgMWIg MDQgMTkgMzEgMmUgMzMgMmUgIDM2IDJlIDMxIDJlIDM0IDJlIDMxIDJlICAgMC4uLjEuMy42LjEu NC4xLiAgDQogIDAwMTA6ICAzNCAzMiAzMCAzMyAyZSAzNiAzNiAzNiAgMmUgMzUgMmUgMzEgMzIg ICAgICAgICAgICA0MjAzLjY2Ni41LjEyICAgICANCj0+IGdldF9jdHJsczogb2lkPSIxLjMuNi4x LjQuMS40MjAzLjY2Ni41LjEyIiAobm9uY3JpdGljYWwpDQo8PSBnZXRfY3RybHM6IG49MSByYz0w IGVycj0iIg0KPj4+IGRuUHJldHR5Tm9ybWFsOiA8REM9c2FtYmEsREM9ZXhhbXBsZSxEQz1jb20+ DQo9PiBsZGFwX2J2MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tLDApDQo8PSBsZGFwX2J2 MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigyNzIpDQo8 PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPT4gbGRhcF9kbjJi digyNzIpDQo8PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPDw8 IGRuUHJldHR5Tm9ybWFsOiA8ZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20+LCA8ZGM9c2FtYmEs ZGM9ZXhhbXBsZSxkYz1jb20+DQpjb25uPTEwMDEgb3A9NSBBREQgZG49ImRjPXNhbWJhLGRjPWV4 YW1wbGUsZGM9Y29tIg0KPj4+IGRuUHJldHR5OiA8Q049RG9tYWluLUROUyxDTj1TY2hlbWEsQ049 Q29uZmlndXJhdGlvbixEQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbT4NCj0+IGxkYXBfYnYyZG4o Q049RG9tYWluLUROUyxDTj1TY2hlbWEsQ049Q29uZmlndXJhdGlvbixEQz1zYW1iYSxEQz1leGFt cGxlLERDPWNvbSwwKQ0KPD0gbGRhcF9idjJkbihDTj1Eb21haW4tRE5TLENOPVNjaGVtYSxDTj1D b25maWd1cmF0aW9uLERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tKT0wIA0KPT4gbGRhcF9kbjJi digyNzIpDQo8PSBsZGFwX2RuMmJ2KGNuPURvbWFpbi1ETlMsY249U2NoZW1hLGNuPUNvbmZpZ3Vy YXRpb24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pPTAgDQo8PDwgZG5QcmV0dHk6IDxjbj1E b21haW4tRE5TLGNuPVNjaGVtYSxjbj1Db25maWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUs ZGM9Y29tPg0KPj4+IGRuTm9ybWFsaXplOiA8Y249RG9tYWluLUROUyxjbj1TY2hlbWEsY249Q29u ZmlndXJhdGlvbixkYz1zYW1iYSxkYz1leGFtcGxlLGRjPWNvbT4NCj0+IGxkYXBfYnYyZG4oY249 RG9tYWluLUROUyxjbj1TY2hlbWEsY249Q29uZmlndXJhdGlvbixkYz1zYW1iYSxkYz1leGFtcGxl LGRjPWNvbSwwKQ0KPD0gbGRhcF9idjJkbihjbj1Eb21haW4tRE5TLGNuPVNjaGVtYSxjbj1Db25m aWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigy NzIpDQo8PSBsZGFwX2RuMmJ2KGNuPWRvbWFpbi1kbnMsY249c2NoZW1hLGNuPWNvbmZpZ3VyYXRp b24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pPTAgDQo8PDwgZG5Ob3JtYWxpemU6IDxjbj1k b21haW4tZG5zLGNuPXNjaGVtYSxjbj1jb25maWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUs ZGM9Y29tPg0Kc3RyMmZpbHRlciAiKHJkblZhbHVlPXNhbWJhKSINCnB1dF9maWx0ZXI6ICIocmRu VmFsdWU9c2FtYmEpIg0KcHV0X2ZpbHRlcjogc2ltcGxlDQpwdXRfc2ltcGxlX2ZpbHRlcjogInJk blZhbHVlPXNhbWJhIg0KYmVnaW4gZ2V0X2ZpbHRlcg0KRVFVQUxJVFkNCmJlcl9zY2FuZiBmbXQg KHttbX0pIGJlcjoNCmJlcl9kdW1wOiBidWY9MHg3ZjQ2Y2M4NzgxZjggcHRyPTB4N2Y0NmNjODc4 MWY4IGVuZD0weDdmNDZjYzg3ODIwYiBsZW49MTkNCiAgMDAwMDogIGEzIDExIDA0IDA4IDcyIDY0 IDZlIDU2ICA2MSA2YyA3NSA2NSAwNCAwNSA3MyA2MSAgIC4uLi5yZG5WYWx1ZS4uc2EgIA0KICAw MDEwOiAgNmQgNjIgNjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bWJhICAgICAgICAgICAgICAgDQplbmQgZ2V0X2ZpbHRlciAwDQpzZW5kX2xkYXBfcmVzdWx0OiBj b25uPTEwMDEgb3A9NSBwPTMNCnNlbmRfbGRhcF9yZXN1bHQ6IGVycj0xMCBtYXRjaGVkPSIiIHRl eHQ9IiINCnNlbmRfbGRhcF9yZXN1bHQ6IGNvbm49MTAwMSBvcD01IHA9Mw0Kc2VuZF9sZGFwX3Jl c3VsdDogZXJyPTE5IG1hdGNoZWQ9IiIgdGV4dD0icmRuVmFsdWUgbm90IHVuaXF1ZSB3aXRoaW4g c2libGluZ3MiDQpzZW5kX2xkYXBfcmVzcG9uc2U6IG1zZ2lkPTYgdGFnPTEwNSBlcnI9MTkNCmJl cl9mbHVzaDI6IDQ5IGJ5dGVzIHRvIHNkIDIxDQogIDAwMDA6ICAzMCAyZiAwMiAwMSAwNiA2OSAy YSAwYSAgMDEgMTMgMDQgMDAgMDQgMjMgNzIgNjQgICAwLy4uLmkqLi4uLi4uI3JkICANCiAgMDAx MDogIDZlIDU2IDYxIDZjIDc1IDY1IDIwIDZlICA2ZiA3NCAyMCA3NSA2ZSA2OSA3MSA3NSAgIG5W YWx1ZSBub3QgdW5pcXUgIA0KICAwMDIwOiAgNjUgMjAgNzcgNjkgNzQgNjggNjkgNmUgIDIwIDcz IDY5IDYyIDZjIDY5IDZlIDY3ICAgZSB3aXRoaW4gc2libGluZyAgDQogIDAwMzA6ICA3MyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzICAgICAgICAgICAg ICAgICANCmxkYXBfd3JpdGU6IHdhbnQ9NDksIHdyaXR0ZW49NDkNCiAgMDAwMDogIDMwIDJmIDAy IDAxIDA2IDY5IDJhIDBhICAwMSAxMyAwNCAwMCAwNCAyMyA3MiA2NCAgIDAvLi4uaSouLi4uLi4j cmQgIA0KICAwMDEwOiAgNmUgNTYgNjEgNmMgNzUgNjUgMjAgNmUgIDZmIDc0IDIwIDc1IDZlIDY5 IDcxIDc1ICAgblZhbHVlIG5vdCB1bmlxdSAgDQogIDAwMjA6ICA2NSAyMCA3NyA2OSA3NCA2OCA2 OSA2ZSAgMjAgNzMgNjkgNjIgNmMgNjkgNmUgNjcgICBlIHdpdGhpbiBzaWJsaW5nICANCiAgMDAz MDogIDczICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHMg ICAgICAgICAgICAgICAgIA0KY29ubj0xMDAxIG9wPTUgUkVTVUxUIHRhZz0xMDUgZXJyPTE5IHRl eHQ9cmRuVmFsdWUgbm90IHVuaXF1ZSB3aXRoaW4gc2libGluZ3MNClRyYWNlYmFjayAobW9zdCBy ZWNlbnQgY2FsbCBsYXN0KToNCiAgRmlsZSAiLi9zZXR1cC9wcm92aXNpb24iLCBsaW5lIDI0NSwg aW4gPG1vZHVsZT4NCiAgICBub3N5bmM9b3B0cy5ub3N5bmMsbGRhcF9kcnlydW5fbW9kZT1vcHRz LmxkYXBfZHJ5cnVuX21vZGUsdXNlZWFkYj1lYWRiKQ0KICBGaWxlICJiaW4vcHl0aG9uL3NhbWJh L3Byb3Zpc2lvbi5weSIsIGxpbmUgMTMwNSwgaW4gcHJvdmlzaW9uDQogICAgZG9tX2Zvcl9mdW5f bGV2ZWw9ZG9tX2Zvcl9mdW5fbGV2ZWwpDQogIEZpbGUgImJpbi9weXRob24vc2FtYmEvcHJvdmlz aW9uLnB5IiwgbGluZSA5MTIsIGluIHNldHVwX3NhbWRiDQogICAgIkRFU0NSSVBUT1IiOiBkZXNj cg0KICBGaWxlICJiaW4vcHl0aG9uL3NhbWJhL3Byb3Zpc2lvbi5weSIsIGxpbmUgMjM5LCBpbiBz ZXR1cF9hZGRfbGRpZg0KICAgIGxkYi5hZGRfbGRpZihkYXRhLGNvbnRyb2xzKQ0KICBGaWxlICJi aW4vcHl0aG9uL3NhbWJhL19faW5pdF9fLnB5IiwgbGluZSAyNTgsIGluIGFkZF9sZGlmDQogICAg c2VsZi5hZGQobXNnLGNvbnRyb2xzKQ0KX2xkYi5MZGJFcnJvcjogKDE5LCAnTERBUCBlcnJvciAx OSBMREFQX0NPTlNUUkFJTlRfVklPTEFUSU9OIC0gIDxyZG5WYWx1ZSBub3QgdW5pcXVlIHdpdGhp biBzaWJsaW5ncz4gPD4nKQ0K --=-bGZqaJas0lpiam3pf2jA-- --=-wu98lDL/cs9xvAtVkpXf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLjLtkz4A8Wyi0NrsRApu+AJ0cW7Vd8zPhS57s8r+iW3D5lFbNHQCgkYCP vgrrkMMEYjbxPtMqqgUHbrY= =ZH85 -----END PGP SIGNATURE----- --=-wu98lDL/cs9xvAtVkpXf--

1 0

Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org 01 Mar '10

01 Mar '10

--=-3cgveKzr2Byp6ib+VYg9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: > [Resending because I forgot the ITS number in the subject] >=20 > I have a simple prototype that on add/modrdn populates/maintains an > attribute (rdnValue) with the distinguished values of the naming > attributes of the RDN. While doing this, it also checks for uniqueness o= f > the rdnValue value within siblings. >=20 > You can find it here > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.= c> >=20 > Please test and comment. I hope it does what intended. I'm starting to look at this now. I'm sorry so many months have past since you posted it. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-3cgveKzr2Byp6ib+VYg9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLjJRvz4A8Wyi0NrsRAqh2AJ4uvpxIGj0PTacpWVLVO18BRrWqaQCeOqhh VdZtFVltm6uv6qY3Lw7ULpk= =zoZi -----END PGP SIGNATURE----- --=-3cgveKzr2Byp6ib+VYg9--

1 0

Status of ITS 5941?
by Lars Kellogg-Stedman 01 Mar '10

01 Mar '10

Hello all, I think I've just run into ITS 5941 (http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5941). I'm trying to set up a proxy using the "translucent" overlay in front of an Active Directory server; I'd like to rewrite some attributes (e.g., sAMAccountName -> uid) as part of this process. The config looks like this: moduleload translucent moduleload rwm database ldif suffix "dc=dept,dc=example,dc=com" directory "/var/lib/ldap/ad-proxy" rootdn "cn=admin,dc=dept,dc=example,dc=com" rootpw "password" overlay translucent uri ldap://127.0.0.1/ acl-bind bindmethod=simple binddn=cn=binduser,ou=people,cn=admin,dc=dept,dc=example,dc=com credentials=password overlay rwm rwm-map attribute uid sAMAccountName With this configuration in place, I can complete one search, after which slapd dies with: Segmentation fault If I explicitly request the rewritten attribute: $ ldapsearch ... cn=lars uid Slapd dies with a backtrace: *** glibc detected *** slapd: double free or corruption (!prev): 0xb6602320 *** ======= Backtrace: ========= /lib/libc.so.6(+0x1b7751)[0x858751] slapd(ber_memfree_x+0x50)[0x610c40] slapd(slap_sl_free+0x70)[0x527240] slapd(do_search+0x17f)[0x4c819f] slapd(+0x3c15e)[0x4c515e] slapd(+0x15921c)[0x5e221c] /lib/libpthread.so.0(+0x2f8ab5)[0x334ab5] /lib/libc.so.6(clone+0x5e)[0x8c4dce] Does this look like the same problem? Is there a fix available? If not, is there a workaround that doesn't involve running a second instance of slapd as a rewriting proxy?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2010