- openldap-bugs - openldap.org

Re: (ITS#5863) assertion failed in ber_bvreplace_x() with translucent overlay
by quanah＠zimbra.com 16 Dec '08

16 Dec '08

--On Tuesday, December 16, 2008 3:20 PM +0000 guillaume.pujol(a)eds.com wrote: > I'm not sure if this crash is due to an incoherent configuration, or to an > interaction problem with the Active Directory backend. > In the former case, I think the server should output an error message when > started. In the later case, it is probably a bug. > > Please let me know if you need more specific information. Can you reproduce with OpenLDAP 2.4.13? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5864) slapadd trickle task slows down slapadd when using libdb-4.5
by rhafer＠suse.de 16 Dec '08

16 Dec '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: openSUSE 11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.233.197) Regardless of the recent slapadd fixes discussed on the -devel list (http://www.openldap.org/lists/openldap-devel/200811/msg00126.html), slapadd performance is still bad when linking against berkely-db 4.5.X, there seem to be problems with libdb-4.5's memp_trickle() function. IMO we should just disable the trickle_task when linking against libdb < 4.6.

1 0

(ITS#5863) assertion failed in ber_bvreplace_x() with translucent overlay
by guillaume.pujol＠eds.com 16 Dec '08

16 Dec '08

Full_Name: Guillaume Pujol Version: 2.4.11 (latest debian package) OS: Debian Lenny URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.251.11.120) Hello, I have an OpenLDAP test instance configured as a translucent proxy to an Active Directory server (the later running on W2k3). The relevant database configuration (from slapd.conf) is as follows: database hdb directory /var/lib/ldap-proxy suffix "dc=eds,dc=local" index objectClass eq overlay translucent uri ldap://192.168.65.130:389 lastmod off acl-bind bindmethod=simple binddn="CN=ldapsync,CN=Users,DC=EDS,DC=local" credentials="ldapsync" idassert-bind bindmethod=simple mode=self chase-referrals yes The server loads and runs fine with this configuration, as long as no one binds. The credentials for acl-bind are valid. When I connect to the server and bind with valid credentials, the server crashes with a SIG_ABRT due to an assertion failed (backtrace below). Steps to reproduce: root@debian:~# /etc/init.d/slapd start Starting OpenLDAP: slapd. root@debian:~# ps aux | grep slapd openldap 5978 0.2 2.0 25188 5364 ? Ssl 14:21 0:00 /usr/sbin/slapd -g openldap -u openldap -f /etc/ldap/slapd.conf root 5983 0.0 0.2 3144 760 pts/2 R+ 14:21 0:00 grep slapd root@debian:~# ldapsearch -H ldap://192.168.65.134 -x -b dc=eds,dc=local -D "cn=myuser,cn=Users,dc=eds,dc=local" -W -LL Enter LDAP Password: <input correct password here> ldap_result: Can't contact LDAP server (-1) root@debian:~# ps aux | grep slapd root 5970 0.0 0.2 3144 764 pts/2 S+ 14:20 0:00 grep slapd # TO MAKE SURE THE SERVER WORKS FINE, I TRY TO BIND WITH A WRONG PASSWORD: root@debian:~# /etc/init.d/slapd start Starting OpenLDAP: slapd. root@debian:~# ldapsearch -x -b dc=eds,dc=local -D "cn=myuser,cn=Users,dc=eds,dc=local" -W Enter LDAP Password: <input wrong password here> ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 52e, vece root@debian:~# ps aux | grep slapd openldap 5982 0.2 2.0 25188 5364 ? Ssl 14:21 0:00 /usr/sbin/slapd -g openldap -u openldap -f /etc/ldap/slapd.conf root 5984 0.0 0.2 3144 760 pts/2 R+ 14:21 0:00 grep slapd The backtrace of the SIG_ABRT is as follows: #0 0xb7faf424 in __kernel_vsyscall () #1 0xb7bbb640 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb7bbd018 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb7bb45be in __assert_fail () from /lib/i686/cmov/libc.so.6 #4 0xb7f62d3b in ber_bvreplace_x (dst=0x8b3d458, src=0xb6981d48, ctx=0x0) at /build/buildd/openldap-2.4.11/libraries/liblber/memory.c:700 #5 0xb7f62d6c in ber_bvreplace (dst=0x8b3d458, src=0xb6981d48) at /build/buildd/openldap-2.4.11/libraries/liblber/memory.c:715 #6 0xb77c78ff in ldap_back_dobind_int (lcp=0xb6981e78, op=0x8b3d018, rs=0xb6983148, sendok=22, retries=0, dolock=1) at /build/buildd/openldap-2.4.11/servers/slapd/back-ldap/bind.c:2211 #7 0xb77c2ecd in ldap_back_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/back-ldap/search.c:166 #8 0xb77b65d2 in translucent_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/overlays/translucent.c:976 #9 0x080db6c6 in overlay_op_walk (op=0x8b3d018, rs=0xb6983148, which=op_search, oi=0x8ae4028, on=0x8ae4128) at /build/buildd/openldap-2.4.11/servers/slapd/backover.c:636 #10 0x080dc205 in over_op_func (op=0x8b3d018, rs=0xb6983148, which=op_search) at /build/buildd/openldap-2.4.11/servers/slapd/backover.c:698 #11 0x08078a23 in fe_op_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/search.c:366 #12 0x08079290 in do_search (op=0x8b3d018, rs=0xb6983148) at /build/buildd/openldap-2.4.11/servers/slapd/search.c:217 #13 0x08076436 in connection_operation (ctx=0xb6983238, arg_v=0x8b3d018) at /build/buildd/openldap-2.4.11/servers/slapd/connection.c:1084 #14 0x08076eb7 in connection_read_thread (ctx=0xb6983238, argv=0x13) at /build/buildd/openldap-2.4.11/servers/slapd/connection.c:1211 #15 0xb7f73fb8 in ldap_int_thread_pool_wrapper (xpool=0x8ab46f8) at /build/buildd/openldap-2.4.11/libraries/libldap_r/tpool.c:663 #16 0xb7cf14c0 in start_thread () from /lib/i686/cmov/libpthread.so.0 #17 0xb7c7061e in clone () from /lib/i686/cmov/libc.so.6 So it looks like this assert fails for some reason: at /build/buildd/openldap-2.4.11/libraries/liblber/memory.c:700 assert( !BER_BVISNULL( src ) ); Reproducible: always with the configuration above. If I remove "mode=self" in the configuration above, the server loads and runs fine (no crash when binding), but I can't search anything in the database: root@debian:~# ldapsearch -LL -x -b dc=eds,dc=local -D "cn=myuser,cn=Users,dc=eds,dc=local" -W Enter LDAP Password: <correct password> result: 1 Operations error text: 00000000: LdapErr: DSID-0C090627, comment: In order to perform this ope ration a successful bind must be completed on the connection., data 0, vece I'm not sure if this crash is due to an incoherent configuration, or to an interaction problem with the Active Directory backend. In the former case, I think the server should output an error message when started. In the later case, it is probably a bug. Please let me know if you need more specific information. Regards,

1 0

Re: (ITS#5856) adauth overlay contribution
by neil.dunbar＠hp.com 16 Dec '08

16 Dec '08

Andrew: > One suggestion following a very quick scan of the code: I think it > would be worth bringing the warning about turning off TLS checks > into the manual page. Agreed. Done. > In particular, there is no reason for this > to be AD-specific and it should be easy to adapt it to authenticate > against any [collection of] remote LDAP servers. Actually, it may not be AD specific as is. If you define default_domain to be some rubbish, and default_realm to be the remote AD server, then everything else (including the remote bind DN) can be fetched from the DIT. But I haven't tried this. But what wouldn't get passed back is any information flowing from password controls - and that's an annoyance, which is why I didn't generalise the code (and because HP had no business need for that approach anyway). Cheers, Neil -- SSL, HP Labs/Office of Strategy and Technology Hewlett-Packard Limited Registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 16 Dec '08

16 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-25943-1229438597-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I can also NOT reproduce this with OpenLDAP 2.3.43 on Solaris 10. So this seems to be a regression in OpenLDAP 2.4.x For the moment I'm sticking with 2.3, though it still doens't solve my problem of hashing passwords on change (exop's don't seem to be triggered) Mark --=_server11-25943-1229438597-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklHvocACgkQb6urvDV9IXhY5ACgkuKEb8H03RbTZWDAthb/n10Z d5AAoLsPNEL3UONsg0oG90coRtIT0ktq =T44A -----END PGP SIGNATURE----- --=_server11-25943-1229438597-0001-2--

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 16 Dec '08

16 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-25317-1229436747-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Also tested my config on OpenLDAP 2.3.27 on CentOS 5 (i386) with packages from: http://dev.centos.org/centos/5/testing/i386/RPMS/ This hasn't resulted in a segfault yet.=20 I will try version 2.3.27 on Solaris now. --=_server11-25317-1229436747-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklHt0gACgkQb6urvDV9IXjtlwCeJ8q/q2q+kX48VSoWCyaAfEE5 TIIAoKHn1k0gkXrxqZjiCekBQC3OMR9D =+iFS -----END PGP SIGNATURE----- --=_server11-25317-1229436747-0001-2--

1 0

(ITS#5862) Assert control ignored on non-database entries
by h.b.furuseth＠usit.uio.no 16 Dec '08

16 Dec '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd does not apply the Assert control to non-database entries (at least the root and subschema entries), yet does not reject a critical control either. I have not explored the magnitutde of the problem: Where the control can get ignored, and which other controls are ignored. $ ldapsearch -LLLx -e\!assert='(objectClass=person)' -b "" -s base dn: objectClass: top objectClass: OpenLDAProotDSE $ ldapsearch -LLLx -e\!assert='(objectClass=person)' -b cn=subschema -s base dn: cn=Subschema objectClass: top objectClass: subentry objectClass: subschema objectClass: extensibleObject cn: Subschema -b "" -s sub does apply the control with database bdb + suffix "". Don't know about back-sql. However I imagine it varies how careful backends "" are about generating the root DSE when suffix == "" so controls can be applied to it. Might need a backend flag which says whether the backend does this, and reject the critical controls with unwillingToPerform if this flag is not set.

1 0

(ITS#5861) Assert control on Add request fails
by h.b.furuseth＠usit.uio.no 16 Dec '08

16 Dec '08

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard RFC 4528 says the Assert control is appropriate for Add. Slapd disagrees: $ ldapadd -xhlocalhost:3890 -e\!assert='(objectClass=organization)' <test.ldif adding new entry "o=test" ldap_add: Critical extension is unavailable (12) additional info: critical extension is unavailable back-bdb and back-sql do not apply the assert control to Add. The message comes from slapd/controls.c. Don't fix that before fixing Add in the backends, otherwise critical controls can be ignored. Another strangeness: overlays/syncprov.c applies the Assert control to Compare but not other operations. I don't know why, there are no comments about it.

1 0

(ITS#5860) slapd memeory leak under openldap 2.4
by rlvcosta＠yahoo.com 15 Dec '08

15 Dec '08

Full_Name: Rodrigo Costa Version: 2.4.11 OS: RHEL4 U4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (201.82.161.220) Opeldap dev team, I'm facing an issue and after many tentatives I believe this is really a bug that maybe could be identified and solved by openldap community. I tried to include dmalloc into openldap 2.4.11 code but even I could compile with it any tentative to execute the code generated "Segmentation Fault" so I could not use dmalloc to identify where the memory leak is happening. I compiled both Berkeley DB 4.6.21 with its patches from source and then compiled openldap 2.4.11 also from source. I download both from links provided at Oracle and Openldap so I think the code is ok. For reference I compiled Berkeley DB with the following configuration : env CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" \ ../dist/configure --enable-largefiles --enable-java --prefix=/usr It compiled without problems. The openldap is compiled with the following configuration : env CFLAGS="-march=pentium4 -O3 -pipe -fomit-frame-pointer" ./configure --with-tls --enable-crypt --enable-syslog --enable-modules --enable-bdb=mod --enable-monitor=mod --enable-shared --with-gnu-ld --enable-overlays=mod --sysconfdir=/etc --prefix=/usr It identifies correctly bdb libraries and compile without any problem. The CHANGES file make reference for ITS#5557 which I saw as possible candidate for the problem I'm having. Even with it looks like there is memory leak. My system is a HP DL380-G3 32 bits with 12GB of memory. The OS is Red Hat Enterprise Linux 4 Update 4. I have actually an old version of OpenLdap(version 2.1.30 with bdb 4.2.52) running in a similar machine without any problem. The specific details are "Linux brtldp11 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux". I made several slapd.conf files trying to control cache and see this could be a configuration problem. I put into debug 64 and the file is read correctly without any problem. Please see output below : all schema stuff... line 23 (pidfile /var/run/slapd.pid) line 24 (argsfile /var/run/slapd.args) line 26 (allow bind_v2) line 28 (sizelimit 10000) line 29 (timelimit 5400) line 31 (loglevel 0) line 34 (modulepath /usr/libexec/openldap) line 35 (moduleload back_bdb.la) loaded module back_bdb.la module back_bdb.la: null module registered line 36 (moduleload back_monitor.la) loaded module back_monitor.la module back_monitor.la: null module registered line 78 (database bdb) line 79 (suffix "ou=CONTENT,o=alcatel,c=fr") line 80 (rootdn "cn=admin,ou=CONTENT,o=alcatel,c=fr") line 84 (rootpw ***) line 87 (directory /var/openldap-data/bdb1) line 90 (index userid,pnnumber,submxid,maillogin,abookaliasid eq,pres) index uid 0x0006 index pnnumber 0x0006 index submxid 0x0006 index maillogin 0x0006 index abookaliasid 0x0006 line 91 (index objectClass eq) index objectClass 0x0004 line 93 (cachesize 45000) line 94 (dncachesize 45000) line 95 (idlcachesize 45000) line 96 (cachefree 9000) line 104 (database bdb) line 105 (suffix "ou=INDEXES,o=alcatel,c=fr") line 106 (rootdn "cn=admin,ou=INDEXES,o=alcatel,c=fr") line 110 (rootpw ***) line 113 (directory /var/openldap-data/bdb2) line 116 (index weblogin,maillogin,mail,pnnumber eq,pres) index weblogin 0x0006 index maillogin 0x0006 index mail 0x0006 index pnnumber 0x0006 line 117 (index profileid,loginname eq,pres) index profileid 0x0006 index loginname 0x0006 line 118 (index objectClass eq) index objectClass 0x0004 line 120 (cachesize 45000) line 121 (dncachesize 45000) line 122 (idlcachesize 45000) line 123 (cachefree 9000) line 131 (database monitor) slapd starting My DB has around 4 million entrances and the bdb DB file size is around 15GB. The DB itself is not big since the entrances are not soo big. By openLDAP documents a DB with 4million entrances should be supported correctly into a 32 bits system. The issue becomes clear when I try to make a ldapsearch in these DBs(bdb1 and bdb2). If I do it the memory usage by slapd start to increase until all possible memory be allocated and system start to paging. After sometime slapd cannot allocate anymore memory using malloc and slapd crashes. After I put the cache this behavior is taking a little longer but not much longer. It ends memory in around 1 hour. Even if I stop the ldapsearch the memory previously allocated by slad isn't released and the process can be seen in the machine top with a lot of allocated memory. The only way to release this memory is to stop slapd process manually. I beleive there is a memory leakage but I could not identify where. My tentatives to used dmalloc were not successful and then I would like to report this bug. Your expertise identifying if the correct patches are really applied into the openldap2.4.11 is really important to solve this issue. Please let me know if you need more information. Regards, Rodrigo Costa.

1 0

Re: (ITS#5856) adauth overlay contribution
by andrew.findlay＠skills-1st.co.uk 15 Dec '08

15 Dec '08

On Fri, Dec 12, 2008 at 07:31:47PM +0000, kartik_subbarao(a)hp.com wrote: > As discussed with Howard Chu, HP is contributing the code for an Active > Directory Authentication overlay (written by Neil Dunbar) to OpenLDAP. > > The adauth overlay provides passthrough authentication to Active Directory for > LDAP simple bind operations. The local LDAP entry referenced in the bind > operation is mapped to its counterpart in the Active Directory, an LDAP bind > operation is performed against Active Directory, and results are returned based > on the results of that remote operation. If a local userPassword attribute is > populated for the entry, it is used instead of the AD authentication. This is very good news, as it deals with a common requirement without having to configure saslauthd. One suggestion following a very quick scan of the code: I think it would be worth bringing the warning about turning off TLS checks into the manual page. It is worth noting that this overlay raises issues similar to those raised by the contributed adpwc/extpwc module - see ITS#5042. In this case the access to AD is via LDAP rather than Kerberos, but most of the arguments are similar. In particular, there is no reason for this to be AD-specific and it should be easy to adapt it to authenticate against any [collection of] remote LDAP servers. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#5859) back-hdb entrycache problem
by quanah＠OpenLDAP.org 15 Dec '08

15 Dec '08

--On Monday, December 15, 2008 4:16 PM +0000 openldap-its(a)OpenLDAP.org wrote: Appears to be broken in 2.4.13 as well. Search prior to adding zimbra-3 entry: [zimbra@freelancer ~]$ ldapsearch -x -h freelancer -b "cn=zimbra" -D "uid=zimbra,cn=admins,cn=zimbra" -W # com_zimbra_license, zimlets, zimbra dn: cn=com_zimbra_license,cn=zimlets,cn=zimbra zimbraZimletTarget: admin-main zimbraZimletDescription: License Management for Admin UI zimbraZimletVersion: 5.2 objectClass: zimbraZimletEntry zimbraZimletIndexingEnabled: TRUE zimbraZimletKeyword: com_zimbra_license cn: com_zimbra_license zimbraZimletIsExtension: TRUE zimbraZimletPriority: 1 zimbraZimletEnabled: TRUE # zimbra-2, zimlets, zimbra dn: cn=zimbra-2,cn=zimlets,cn=zimbra cn: zimbra-2 objectClass: zimbraZimletEntry zimbraZimletVersion: 1.0 zimbraZimletEnabled: TRUE # search result search: 2 result: 0 Success # numResponses: 46 # numEntries: 45 Then we add the new entry: [zimbra@freelancer ~]$ ldapadd -f /tmp/test.ldif -x -h freelancer -D "uid=zimbra,cn=admins,cn=zimbra" -W Enter LDAP Password: adding new entry "cn=zimbra-3,cn=zimlets,cn=zimbra" Now we search again: # com_zimbra_license, zimlets, zimbra dn: cn=com_zimbra_license,cn=zimlets,cn=zimbra zimbraZimletTarget: admin-main zimbraZimletDescription: License Management for Admin UI zimbraZimletVersion: 5.2 objectClass: zimbraZimletEntry zimbraZimletIndexingEnabled: TRUE zimbraZimletKeyword: com_zimbra_license cn: com_zimbra_license zimbraZimletIsExtension: TRUE zimbraZimletPriority: 1 zimbraZimletEnabled: TRUE # zimbra-2, zimlets, zimbra dn: cn=zimbra-2,cn=zimlets,cn=zimbra cn: zimbra-2 objectClass: zimbraZimletEntry zimbraZimletVersion: 1.0 zimbraZimletEnabled: TRUE # search result search: 2 result: 0 Success # numResponses: 46 # numEntries: 45 Same result, this is bad. Now we stop/restart slapd: [zimbra@freelancer ~]$ ldap stop Killing slapd with pid 15613 done. [zimbra@freelancer ~]$ ldap start Started slapd: pid 20224 search again: # zimbra-2, zimlets, zimbra dn: cn=zimbra-2,cn=zimlets,cn=zimbra cn: zimbra-2 objectClass: zimbraZimletEntry zimbraZimletVersion: 1.0 zimbraZimletEnabled: TRUE # zimbra-3, zimlets, zimbra dn: cn=zimbra-3,cn=zimlets,cn=zimbra cn: zimbra-3 objectClass: zimbraZimletEntry zimbraZimletVersion: 1.0 zimbraZimletEnabled: TRUE # search result search: 2 result: 0 Success # numResponses: 46 # numEntries: 45 And there is our missing entry. --Quanah -- Quanah Gibson-Mount Release and QA Engineer <http://www.openldap.org>

1 0

(ITS#5859) back-hdb entrycache problem
by quanah＠OpenLDAP.org 15 Dec '08

15 Dec '08

Full_Name: Quanah Gibson-Mount Version: 2.4.13+patches OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) In using 2.4.13 + the slapadd fix from Ralf, ITS#5841, ITS#5842,ITS#5849,ITS#5850, ITS#5854, I found the following: Create an database with back-hdb with a few subtrees, with several entries under that subtree (My database is rooted at "". I have a "cn=zimbra" tree, with "cn=zimlets,cn=zimbra" underneath it). Now, create a brand new entry under one of those subtrees. The new entry will not be returned in queries rooted at the upper level ("cn=zimbra"). It will show up at its level ("cn=zimlets,cn=zimbra"). If you stop/restart slapd to flush the entry/idl cache, things work correctly.

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 15 Dec '08

15 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-3551-1229353986-0001-2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I spoke too soon, both on Solaris and on Linux I still get reproducable segfaults with 2.4.13 as soon as I use a ppolicy overlay in my configuration and query the directory. I have a public shellbox available which has the config loaded Mark --=_server11-3551-1229353986-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJRnQBb6urvDV9IXgRAt7aAKCC3GveYtw6mHaWWi/EkStXn6YtFwCeIKNx mFaCqgogqL0dkjGJQ6mul4s= =ADsB -----END PGP SIGNATURE----- --=_server11-3551-1229353986-0001-2--

1 0

Re: (ITS#5858) Segfault with overlay ppolicy
by maniac＠maniac.nl 15 Dec '08

15 Dec '08

This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_server11-2243-1229351458-0001-2 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I can reproduce this problem also on Linux/amd64 (Debian Testing) with OpenLDAP 2.4.11. I can confirm that it is FIXED on OpenLDAP 2.4.13 on Linux (and am now compiling it on Solaris) Mark --=_server11-2243-1229351458-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAklGaiIACgkQb6urvDV9IXiCRQCgoNI6qsFg+gORmzPaYtWLSmmE higAoI2Cq0G0HQevFuC6Q7y1L/62geES =FKcN -----END PGP SIGNATURE----- --=_server11-2243-1229351458-0001-2--

1 0

(ITS#5858) Segfault with overlay ppolicy
by maniac-openldap＠maniac.nl 15 Dec '08

15 Dec '08

Full_Name: Mark Janssen Version: 2.4.11 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.64.241.2) Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 3] over_entry_get_rw (op=0x403648, dn=0x403664, oc=0x0, ad=0x0, rw=0, e=0xfd3ff4d4) at backover.c:394 394 return overlay_entry_get_ov( op, dn, oc, ad, rw, e, on ); (gdb) bt full #0 over_entry_get_rw (op=0x403648, dn=0x403664, oc=0x0, ad=0x0, rw=0, e=0xfd3ff4d4) at backover.c:394 oi = (slap_overinfo *) 0x293788 on = (slap_overinst *) 0x275148 #1 0x0009b8a8 in fe_entry_get_rw (op=Cannot access memory at address 0xfcfffec0 ) at frontend.c:62 bd = Cannot access memory at address 0xfcfffe88 (gdb) info threads 4 LWP 4 0xfe3c4a9c in __lwp_park () from /lib/libc.so.1 * 3 LWP 3 over_entry_get_rw (op=0x403648, dn=0x403664, oc=0x0, ad=0x0, rw=0, e=0xfd3ff4d4) at backover.c:394 2 LWP 2 0xfe3c57c8 in __pollsys () from /lib/libc.so.1 1 LWP 1 0xfe3c5c1c in __lwp_wait () from /lib/libc.so.1 (gdb) As soon as I enable 'ppolicy' I get a segfault when I login (with lbe) to the ldap server. Repeatable 100% (goes away when I remove ppolicy overlay from slapd.conf) Config snippet: overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=domain,dc=tld" ppolicy_hash_cleartext

1 0

(ITS#5856) adauth overlay contribution
by kartik_subbarao＠hp.com 12 Dec '08

12 Dec '08

Full_Name: Kartik Subbarao Version: 2.4 OS: Red Hat Enterprise Linux URL: ftp://ftp.openldap.org/incoming/adauth.tar.gz Submission from: (NULL) (76.99.180.78) As discussed with Howard Chu, HP is contributing the code for an Active Directory Authentication overlay (written by Neil Dunbar) to OpenLDAP. The adauth overlay provides passthrough authentication to Active Directory for LDAP simple bind operations. The local LDAP entry referenced in the bind operation is mapped to its counterpart in the Active Directory, an LDAP bind operation is performed against Active Directory, and results are returned based on the results of that remote operation. If a local userPassword attribute is populated for the entry, it is used instead of the AD authentication.

1 0

(ITS#5855) slapd crash at hang or shutdown
by carlcarl＠comcast.net 12 Dec '08

12 Dec '08

Full_Name: Carl Traub Version: all ? OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (141.202.248.52) On Windows,I have found that by simply starting slapd, waiting a few minutes for it to get fully loaded, and then hitting Ctrl-C, slapd will often hang and not terminate properly. It occasionally crashed, and that may been related. The problem is that in slapd_daemon_destroy(), tcp_close() was being called for both wake_sds[1] and wake_sds[0], and the 2 values were always the same. This meant that Windows was being asked to close a connection that had already been closed and was no longer valid. A coworker stated that on Windows, these 2 values are always the same, but he thought that on Unix they would always be different. I uploaded the diff file "carlTraub-121208.diff". I wasn't clear on using the diff tool. Below is the diff. --- P:\temp\daemon.c_bef Fri Dec 12 10:05:38 2008 +++ P:\temp\daemon.c_after Fri Dec 12 10:24:30 2008 @@ -1645,14 +1645,10 @@ slapd_daemon_destroy( void ) { connections_destroy(); + // If the 2 connections are actually the same, closing it twice can cause bad things, like hangs or crashes. + // It may be that they are always the same on Windows, always different on Unix. + if (wake_sds[1] != wake_sds[0] ) { #ifdef HAVE_WINSOCK + if ( wake_sds[1] != INVALID_SOCKET ) - if ( wake_sds[1] != INVALID_SOCKET ) #endif /* HAVE_WINSOCK */ + tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); + } - tcp_close( SLAP_FD2SOCK(wake_sds[1]) ); #ifdef HAVE_WINSOCK if ( wake_sds[0] != INVALID_SOCKET ) #endif /* HAVE_WINSOCK */

1 0

Re: (ITS#5854) Double send response in meta backend
by ando＠sys-net.it 12 Dec '08

12 Dec '08

jorge.perez(a)adaptia.net wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.11 > OS: SLES 10 > URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz > Submission from: (NULL) (194.237.142.20) > > > Meta backend send two response codes when trying to reconnect to other slapd. > > Steps to reproduce: > Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough > meta backend. Do some traffic operations. Restart slapd_B and do some modify, > delete or add operation, response code 52 is received although the operation is > sucessful. Using a tcpdump you can see two response codes for the request. > > I attach a possible patch for this issue. Thanks. I've committed an alternative fix to this issue, in line with the analogous code in back-ldap. It makes use of the specific bit of the ldap_back_send_t mask instead of an additional argument. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 11 Dec '08

11 Dec '08

Andrew Bartlett wrote: > On Thu, 2008-12-11 at 23:17 +0100, Pierangelo Masarati wrote: >> Andrew Bartlett wrote: >>> On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: >>>> A tentative implementation is in HEAD, please test. You need to: >>> Thankyou very much. I downloaded CVS HEAD and tested it out (finally - >>> the Samba4 side of the implementation took far longer than I expected). >>> >>>> - configure as --enable-deref >>>> >>>> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't >>>> work as global overlay yet, sorry). >>> This is something Samba4 will need, as many of our links are >>> cross-database. But fixing this for a single DB is a big help in any >>> case. >>> >>>> - run searches like >>>> >>>> $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID' >>>> >>>> you'll see results like >>> When using Samba4's client, it seems to work, but it is as if it extends >>> the control to the full expected length, but not the data. Ie, attached >>> this is the control response I got back from the 'make testenv' >>> environment in Samba4. I've also attached the full LDAP request. >>> >>> The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 >>> parsing bug). >> I've found the bug (erroneous manipulation of octet strings containing >> '\0' octets). The objectSid is octet string-valued. Should be fixed >> now; please test. > > While I'm mostly at sea on ASN.1, I don't think the OpenLDAP's > implementation matches your IETF draft (if not, an education on subtle > details of ASN.1 will be appreciated) > > draft-masarati-ldap-deref-00 > > >> 2.3. Control Response >> >> >> The control type is deref-oid (IANA assigned; see Section 6). The >> specification of the Dereference Control response is: >> >> controlValue ::= SEQUENCE OF derefRes DerefRes >> >> DerefRes ::= SEQUENCE { >> derefAttr AttributeDescription, >> derefVal LDAPDN, >> attrVals [0] PartialAttributeList OPTIONAL } >> >> PartialAttributeList ::= SEQUENCE OF >> partialAttribute PartialAttribute >> >> PartialAttribute is defined in [RFC4511]; the definition is reported >> here for clarity: >> >> PartialAttribute ::= SEQUENCE { >> type AttributeDescription, >> vals SET OF value AttributeValue } >> > > the output of dumpasn1 on the control: > >> 0 983: SEQUENCE { >> 4 168: SEQUENCE { >> 7 8: OCTET STRING 'memberOf' >> 17 56: OCTET STRING >> : 'cn=Enterprise Admins,cn=Users,dc=samba,dc=exampl' >> : 'e,dc=com' >> 75 98: [0] { >> 77 51: SEQUENCE { > > Shouldn't there be another SEQUENCE { here? Well, that was my intention when I ber_printf("{{OOt{{O[W]}{O[W]}}}}"), which, AFAIK, means: "{" SEQUENCE "{" SEQUENCE "OO" derefAttr, derefVal "t" [0] "{" SEQUENCE "{O[W]}" SEQUENCE, type, SET OF vals Am I missing anything? Couldn't "[0] {" be a shortcut in dumpasn1 to indicate SEQUENCE OF and the presence of a context+constructed tag? Looking at the raw data of an example, I see a sequence 240 126 060 063 004 011 which means: 240 context + constructed 126 (the length, 86 octets) 060 sequence 063 (the length, 51 octets) 004 octet string 011 (the length, 9 octets: "entryUUID") I'm not an expert in ASN.1, but from what I infer by looking at LDAP specs and at OpenLDAP implementation, this is consistent with the way similar cases are dealt with (e.g. the "Controls" at the end of a request message). p. > >> 79 9: OCTET STRING 'entryUUID' >> 90 38: SET { >> 92 36: OCTET STRING >> '24476f18-5c24-102d-9945-7320c1040f54' >> : } >> : } >> 130 43: SEQUENCE { >> 132 9: OCTET STRING 'objectSid' >> 143 30: SET { >> 145 28: OCTET STRING >> : 01 05 00 00 00 00 00 05 15 00 00 00 AB BE DB 7B >> : 16 72 AE E6 53 BE 65 6F 07 02 00 00 >> : } >> : } >> : } >> : } >> > > Thanks, > > Andrew Bartlett > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5854) Double send response in meta backend
by ando＠sys-net.it 11 Dec '08

11 Dec '08

hyc(a)symas.com wrote: > Thanks for your report. Sounds a lot like ITS#4782... Howard, the proposed fix is fine, but I think the issue is better addressed in back-ldap by means of the ldap_back_send_t mask without the need of an additional argument. I'm testing a different fix. p. > On Thu, Dec 11, 2008 at 10:14:23AM +0000, jorge.perez(a)adaptia.net wrote: >> Full_Name: Jorge Perez Burgos >> Version: 2.4.11 >> OS: SLES 10 >> URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz >> Submission from: (NULL) (194.237.142.20) >> >> >> Meta backend send two response codes when trying to reconnect to other slapd. >> >> Steps to reproduce: >> Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough >> meta backend. Do some traffic operations. Restart slapd_B and do some modify, >> delete or add operation, response code 52 is received although the operation is >> sucessful. Using a tcpdump you can see two response codes for the request. >> >> I attach a possible patch for this issue. >> >> > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5854) Double send response in meta backend
by hyc＠symas.com 11 Dec '08

11 Dec '08

Thanks for your report. Sounds a lot like ITS#4782... On Thu, Dec 11, 2008 at 10:14:23AM +0000, jorge.perez(a)adaptia.net wrote: > Full_Name: Jorge Perez Burgos > Version: 2.4.11 > OS: SLES 10 > URL: ftp://ftp.openldap.org/incoming/back-meta_changes.diff.gz > Submission from: (NULL) (194.237.142.20) > > > Meta backend send two response codes when trying to reconnect to other slapd. > > Steps to reproduce: > Configure two slapds, slapd_A and slapd_B. slapd_A connects to slapd_B trough > meta backend. Do some traffic operations. Restart slapd_B and do some modify, > delete or add operation, response code 52 is received although the operation is > sucessful. Using a tcpdump you can see two response codes for the request. > > I attach a possible patch for this issue. > >

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 11 Dec '08

11 Dec '08

--=-3TUJtt6yg+CvD9VzraMk Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-12-11 at 23:22 +0100, Pierangelo Masarati wrote: > Andrew Bartlett wrote: > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > >> A tentative implementation is in HEAD, please test. You need to: > >=20 > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > > the Samba4 side of the implementation took far longer than I expected). > >=20 > >> - configure as --enable-deref > >> > >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > >> work as global overlay yet, sorry). > >=20 > > This is something Samba4 will need, as many of our links are > > cross-database. But fixing this for a single DB is a big help in any > > case. >=20 > Apparently this was fixed during the overlay's shakedown, as it seems to=20 > work as expected when only instantiated as global. In fact, nothing was=20 > preventing it from working this way by design, it only didn't work at=20 > some point of its evolution. Please test. Indeed, it works well as a global. Thanks! My only issue remaining is the clarification over the ASN.1 encoding of the control. Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-3TUJtt6yg+CvD9VzraMk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQdk5z4A8Wyi0NrsRAiiOAKCUywnlFS2RIZlclADU/woC7id7OwCfbfwD fh4vPeyWTWqBYACEYVFgdZA= =UdNB -----END PGP SIGNATURE----- --=-3TUJtt6yg+CvD9VzraMk--

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by abartlet＠samba.org 11 Dec '08

11 Dec '08

--=-WGywWWDfCXc78PSX7dDA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2008-12-11 at 23:17 +0100, Pierangelo Masarati wrote: > Andrew Bartlett wrote: > > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: > >> A tentative implementation is in HEAD, please test. You need to: > >=20 > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > > the Samba4 side of the implementation took far longer than I expected). > >=20 > >> - configure as --enable-deref > >> > >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't > >> work as global overlay yet, sorry). > >=20 > > This is something Samba4 will need, as many of our links are > > cross-database. But fixing this for a single DB is a big help in any > > case. > >=20 > >> - run searches like > >> > >> $ ldapsearch -x -b dc=3Dexample,dc=3Dcom -E 'deref=3Dmember:entryUUID' > >> > >> you'll see results like > >=20 > > When using Samba4's client, it seems to work, but it is as if it extend= s > > the control to the full expected length, but not the data. Ie, attache= d > > this is the control response I got back from the 'make testenv' > > environment in Samba4. I've also attached the full LDAP request. > >=20 > > The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 > > parsing bug). >=20 > I've found the bug (erroneous manipulation of octet strings containing=20 > '\0' octets). The objectSid is octet string-valued. Should be fixed=20 > now; please test. While I'm mostly at sea on ASN.1, I don't think the OpenLDAP's implementation matches your IETF draft (if not, an education on subtle details of ASN.1 will be appreciated) draft-masarati-ldap-deref-00 > 2.3. Control Response >=20 >=20 > The control type is deref-oid (IANA assigned; see Section 6). The > specification of the Dereference Control response is: >=20 > controlValue ::=3D SEQUENCE OF derefRes DerefRes >=20 > DerefRes ::=3D SEQUENCE { > derefAttr AttributeDescription, > derefVal LDAPDN, > attrVals [0] PartialAttributeList OPTIONAL } >=20 > PartialAttributeList ::=3D SEQUENCE OF > partialAttribute PartialAttribute >=20 > PartialAttribute is defined in [RFC4511]; the definition is reported > here for clarity: >=20 > PartialAttribute ::=3D SEQUENCE { > type AttributeDescription, > vals SET OF value AttributeValue } >=20 the output of dumpasn1 on the control: > 0 983: SEQUENCE { > 4 168: SEQUENCE { > 7 8: OCTET STRING 'memberOf' > 17 56: OCTET STRING > : 'cn=3DEnterprise Admins,cn=3DUsers,dc=3Dsamba,dc=3Dexamp= l' > : 'e,dc=3Dcom' > 75 98: [0] { > 77 51: SEQUENCE { Shouldn't there be another SEQUENCE { here? > 79 9: OCTET STRING 'entryUUID' > 90 38: SET { > 92 36: OCTET STRING > '24476f18-5c24-102d-9945-7320c1040f54' > : } > : } > 130 43: SEQUENCE { > 132 9: OCTET STRING 'objectSid' > 143 30: SET { > 145 28: OCTET STRING > : 01 05 00 00 00 00 00 05 15 00 00 00 AB BE DB 7B > : 16 72 AE E6 53 BE 65 6F 07 02 00 00 > : } > : } > : } > : } >=20 Thanks, Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-WGywWWDfCXc78PSX7dDA Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJQa1Nz4A8Wyi0NrsRAtyAAJ9Dqzqn3DknKqThzy7KML5Z+i/h2wCfZ2nM d8HdE9UXPLaN2DZRwIseCk0= =HFZS -----END PGP SIGNATURE----- --=-WGywWWDfCXc78PSX7dDA--

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 11 Dec '08

11 Dec '08

Andrew Bartlett wrote: > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: >> A tentative implementation is in HEAD, please test. You need to: > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > the Samba4 side of the implementation took far longer than I expected). > >> - configure as --enable-deref >> >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't >> work as global overlay yet, sorry). > > This is something Samba4 will need, as many of our links are > cross-database. But fixing this for a single DB is a big help in any > case. Apparently this was fixed during the overlay's shakedown, as it seems to work as expected when only instantiated as global. In fact, nothing was preventing it from working this way by design, it only didn't work at some point of its evolution. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5768) [enhancement] add support for Dereference Control
by ando＠sys-net.it 11 Dec '08

11 Dec '08

Andrew Bartlett wrote: > On Thu, 2008-10-23 at 00:15 +0200, Pierangelo Masarati wrote: >> A tentative implementation is in HEAD, please test. You need to: > > Thankyou very much. I downloaded CVS HEAD and tested it out (finally - > the Samba4 side of the implementation took far longer than I expected). > >> - configure as --enable-deref >> >> - enable the "deref" overlay in slapd, with "overlay deref" (doesn't >> work as global overlay yet, sorry). > > This is something Samba4 will need, as many of our links are > cross-database. But fixing this for a single DB is a big help in any > case. > >> - run searches like >> >> $ ldapsearch -x -b dc=example,dc=com -E 'deref=member:entryUUID' >> >> you'll see results like > > When using Samba4's client, it seems to work, but it is as if it extends > the control to the full expected length, but not the data. Ie, attached > this is the control response I got back from the 'make testenv' > environment in Samba4. I've also attached the full LDAP request. > > The extra zeros also appear in the OpenLDAP logs (so it's not a Samba4 > parsing bug). I've found the bug (erroneous manipulation of octet strings containing '\0' octets). The objectSid is octet string-valued. Should be fixed now; please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs