- openldap-bugs - openldap.org

Re: (ITS#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by wking＠tremily.us 13 May '12

13 May '12

--DKU6Jbt7q3WqK7+M Content-Type: multipart/mixed; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I forgot to add the notice to the patch I just submitted. Here's the notice: The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by W. Trevor King wking(a)tremily.us. I have not assigned rights and/or interest in this work to any party. I, W. Trevor King, 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. I've attached the patch again, since that matches the language in the notice. Cheers, Trevor --=20 This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="tool-nocanon.patch" Content-Transfer-Encoding: quoted-printable ITS#7271 fix SASL_NOCANON clobbering in tools/common.c. diff --git a/clients/tools/common.c b/clients/tools/common.c index 9c98b62..9868658 100644 --- a/clients/tools/common.c +++ b/clients/tools/common.c @@ -1214,6 +1214,7 @@ LDAP * tool_conn_setup( int dont, void (*private_setup)( LDAP * ) ) { LDAP *ld =3D NULL; + int i; =20 if ( debug ) { if( ber_set_option( NULL, LBER_OPT_DEBUG_LEVEL, &debug ) @@ -1410,13 +1411,22 @@ dnssrv_free:; =20 #ifdef HAVE_CYRUS_SASL /* canon */ - if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON, - nocanon ? LDAP_OPT_ON : LDAP_OPT_OFF ) !=3D LDAP_OPT_SUCCESS ) + if( ldap_get_option( ld, LDAP_OPT_X_SASL_NOCANON, &i ) + !=3D LDAP_OPT_SUCCESS ) { - fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON %s\n", - nocanon ? "on" : "off" ); + fprintf( stderr, "Could not get LDAP_OPT_X_SASL_NOCANON\n" ); tool_exit( ld, EXIT_FAILURE ); } + if (!i) { + fprintf( stderr, "Set NOCANON to %s\n", nocanon ? "on" : "off" ); + if( ldap_set_option( ld, LDAP_OPT_X_SASL_NOCANON, + nocanon ? LDAP_OPT_ON : LDAP_OPT_OFF ) !=3D LDAP_OPT_SUCCESS ) + { + fprintf( stderr, "Could not set LDAP_OPT_X_SASL_NOCANON %s\n", + nocanon ? "on" : "off" ); + tool_exit( ld, EXIT_FAILURE ); + } + } /* otherwise SASL_NOCANON already set to true (e.g. via ~/.ldaprc) */ #endif if( ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &protocol ) !=3D LDAP_OPT_SUCCESS ) --Nq2Wo0NMKNjxTN9z-- --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQEcBAEBAgAGBQJPrw4RAAoJEPe7CdOcrcTZAiUH/RJN9EcOW0HdIr60/vrHQ01r et05+CMhoSM9OQST7KxVz0IOA0tzgIu6y7KHFSirUFOmb8KNyS+u0uI2b4OMINoF 0qVHo3Ed4gYYQtc9TsTPOTNw0/HfRwiLxYHh6Xrmeq0Z9o+rL1wsFoEwVBQTXc4W 3xsYtjoyRFK5KbmMw+iA1zsIWOTD9cs+PqQ0EWDXl2ptMHjhrBOs8/Demi495UA7 iCmrPbD8uv8T5NMCiqIB3yOkyrX2+0wLsLVO/B21qTb8swFOrSFjlACZ4SjvVYmy ZJ6njl7vu0h7vPF12Z+NQW5xMFCYz6wbesrhCNbj0k7eJ5gbD+Zd2tP8VQOS3C4= =9g7U -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M--

1 0

(ITS#7271) Don't clobber SASL_NOCANON in clients/tools/common.c
by wking＠tremily.us 13 May '12

13 May '12

Full_Name: W. Trevor King Version: git commit 22bf5188 OS: Gentoo URL: http://blog.tremily.us/posts/LDAP/tool-nocanon.patch Submission from: (NULL) (72.68.88.202) The ldap.conf SASL_NOCANON configuration option (or LDAPSASL_NOCANON environment variable) should set the default behaviour for OpenLDAP tools such as ldapwhoami. This configuration option should allow users to use the tools without having to use the matching command line option (-N). Unfortunately, the current code sets the option to true/false after only querying the command line option. I'm linking to a patch that looks at the current value of the option first, and if it's true, skips processing the command line option (which would either be a redundant -N keeping the option true, or an absence of -N which implies the user wants to use the configured value (true)). Another approach would be to set the initial value of nocanon to UNINITIALIZED (-1?). Command line arguments could set nocanon to 1 (true, -N) or false (0, --canon?). Then we would only call ldap_set_option if nocanon was not UNINITIALIZED. I can work up a patch using this second approach if people prefer. If so, let me know if you want me to define UNINITIALIZED, or to just use -1. I didn't check, but I would not be surprised if this same clobbering occurred for other command line options.

1 0

ITS#6997
by michael＠stroeder.com 12 May '12

12 May '12

I think it's worth to note that such a setup with this stacking order works with OpenLDAP 2.4.23 (in a more complex variant done by Manuel). So the big question is what was changed in 2.4.24+ which leads to the crash? Ciao, Michael.

1 0

(ITS#7270) Double free in ldap_int_initialize
by fdeweerdt＠cloudmark.com 11 May '12

11 May '12

Full_Name: Frederik Deweerdt Version: current HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/Frederik-Deweerdt-120511.patch Submission from: (NULL) (72.5.239.5) [PATCH] Protect accesses to ldap_int_hostname with a mutex Not protecting the accesses to ldap_int_hostname would lead to a double free with the following trace: #7 0x0000003aca031d10 in abort () from /lib64/libc.so.6 No symbol table info available. #8 0x0000003aca06a99b in __libc_message () from /lib64/libc.so.6 No symbol table info available. #9 0x0000003aca0729d6 in free () from /lib64/libc.so.6 No symbol table info available. #10 0x000000328902333e in ldap_int_initialize () from /usr/lib64/libldap-2.3.so.0 No symbol table info available. #11 0x000000328900c426 in ldap_create () from /usr/lib64/libldap-2.3.so.0 No symbol table info available. #12 0x000000328900ca0d in ldap_init () from /usr/lib64/libldap-2.3.so.0 No symbol table info available. The race in init.c:ldap_int_initialize is as follows: 646 char *name = ldap_int_hostname; 647 648 ldap_int_hostname = ldap_pvt_get_fqdn( name ); 649 650 if ( name != NULL && name != ldap_int_hostname ) { 651 LDAP_FREE( name ); 652 } - T1 and T2 enter ldap_int_initialize, both assign to name the current address of ldap_int_hostname, say 0x1234. - T1 and T2 call ldap_pvt_get_fqdn(), updating ldap_int_hostname to 0x1235 and 0x1236 respectively. - T1 and T2 reach the name != ldap_int_hostname check. In both threads it's false, because 0x1235 != 0x1234 and 0x1236 != 0x1234, respectively. - T1 and T2 both try to free 0x1234 => Crash. --- libraries/libldap/init.c | 2 ++ libraries/libldap/ldap-int.h | 1 + libraries/libldap/util-int.c | 3 +++ 3 files changed, 6 insertions(+), 0 deletions(-)

1 0

Re: (ITS#7268) syncrepl issue
by quanah＠zimbra.com 10 May '12

10 May '12

--On Thursday, May 10, 2012 9:41 AM +0000 Nithya.narasimhan(a)hp.com wrote: > Full_Name: Nithya Narasimhan > Version: Symas OpenLDAP version 2.4.26 > OS: RHEL 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.219.201.69) > > > We have configured 2 nodes in an n way multimaster configuration. The ITS system is for reporting bug, not asking usage questions. Please (a) upgrade to the lastest version of OpenLDAP (2.4.31) and (b) direct your questions to the openldap-technical(a)openldap.org discussion list. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7269) [PATCH] Make slapd-sha2 module thread-safe
by fumiyas＠osstech.co.jp 10 May '12

10 May '12

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch Submission from: (NULL) (125.2.180.244) In contrib/slapd-modules/passwd/sha2/slapd-sha2.c:sha*_hex_hash(), a static buffer "static char real_hash[]" is declared and is used by threads, but it is not TLS (Thread Local Storage) and no lock. This patch removes sha*_hex_hash() and replaces chk_sha*() with libraries/liblutil/passwd.c:chk_sha1() implementation to fix this problem.

1 0

(ITS#7268) syncrepl issue
by Nithya.narasimhan＠hp.com 10 May '12

10 May '12

Full_Name: Nithya Narasimhan Version: Symas OpenLDAP version 2.4.26 OS: RHEL 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.219.201.69) We have configured 2 nodes in an n way multimaster configuration. Server Definition is configured as follows - Slapd.conf entry in first server serverID 001 ldap://16.181.233.72:1389 serverID 002 ldap://16.181.233.71:1389 Slapd.conf entry in second server serverID 001 ldap://16.181.233.72:1389 serverID 002 ldap://16.181.233.71:1389 Offline replication does not occur.ie:Bring down node1, add entries to node2 which is up.Then bring up the node1 after sometime.In this case the entries added in node2 are not available in node1. However when ServerID is configured as follows in slapd.conf file - Slapd.conf entry in first server serverID 1 Slapd.conf entry in second server serverID 2 offline replication occurs correctly. My Questions are - 1) What is the correct Server Definition for n way multimaster. 2) Is there any other configuration we need to change to make this work? 3) If we are adding LDAP URL to Server Definition , what is the correct format we must use ? 4) If N-way multi-master mode for 2 servers (2-way multi-master Mode), should both nodes information be configured in both servers under syncrepl. Should the syncrepl ID be different in both servers ? Can you share me a sample 2-way multi-master mode setup. 5) Offline data load (Node 1 is up and Node 2 is down Now entries are added in Node 1 and then Node 2 is brought up) How does this synchronization work ? Will it work in Physical server and Virtual Machine as well ? Scenarios of addition/deletion/modification of entries/attributes. 6) What happens if I define an interval even if I have it refreshandpersist type Will it ignore that parameter or does it have any side effects ?

1 0

Re: (ITS#7265) reaching back-mdb database sizelimit can result in corrupt DB
by quanah＠zimbra.com 09 May '12

09 May '12

--On Monday, May 07, 2012 6:05 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.30+patches > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > With a database maxsize of 1GB, found that when the DB hit 1GB in size, > slapd stopped. After upping the maxsize, the mdb database was unreadable > via ldapsearch. Slapcat also failed to pull any data out of the database. > Appears related to ITS7266, this ITS can be closed. There was a size mismatch between data sizes in slapd & libmdb. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7267) [PATCH] Make slapd-sha2 portable
by hyc＠symas.com 08 May '12

08 May '12

fumiyas(a)osstech.jp wrote: > Hi, > >> Full_Name: SATOH Fumiyasu >> Version: master >> OS: >> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable.patch > > Revised patch: > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable-v2.patch > > Sorry. Thanks for the patch. It's always better to preserve comments than to delete them, you should have changed the C++ comments to regular C comments. I'll tweak this and commit. -- -- 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#7267) [PATCH] Make slapd-sha2 portable
by fumiyas＠osstech.jp 08 May '12

08 May '12

Hi, > Full_Name: SATOH Fumiyasu > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable.patch Revised patch: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable-v2.patch Sorry. > Submission from: (NULL) (125.2.180.244) -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- Personal Home: https://github.com/fumiyas/

1 0

(ITS#7267) [PATCH] Make slapd-sha2 portable
by fumiyas＠osstech.co.jp 08 May '12

08 May '12

Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-portable.patch Submission from: (NULL) (125.2.180.244) contrib/slapd-modules/passwd/sha2/sha2.[ch] need portable.h and some macros to be portable source.

1 0

(ITS#7266) back-mdb deletion failures
by quanah＠OpenLDAP.org 07 May '12

07 May '12

Full_Name: Quanah Gibson-Mount Version: 2.4.31 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) Create an MDB database with approximately 130,000 entries. Delete the entries sequentially. Deletes will sporadically fail in blocks: deleting entry "uid=testuser44968,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser44969,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser44970,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed ... continues to fail up to: deleting entry "uid=testuser45093,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser45094,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser45095,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" ldap_delete: Other (e.g., implementation specific) error (80) additional info: entry index delete failed deleting entry "uid=testuser45096,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser45097,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser45098,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" deleting entry "uid=testuser45099,ou=people,dc=zre-ldap004,dc=eng,dc=vmware,dc=com" then deletes work for a while again, then fail again for a while, etc.

1 0

(ITS#7265) reaching back-mdb database sizelimit can result in corrupt DB
by quanah＠OpenLDAP.org 07 May '12

07 May '12

Full_Name: Quanah Gibson-Mount Version: 2.4.30+patches OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) With a database maxsize of 1GB, found that when the DB hit 1GB in size, slapd stopped. After upping the maxsize, the mdb database was unreadable via ldapsearch. Slapcat also failed to pull any data out of the database.

1 0

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

07 May '12

--nextPart2505210.xvcxic42sH Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday 27 of April 2012 12:26:22, Howard Chu wrote: > jvcelak(a)redhat.com wrote: > >> What happens is that the memberof overlay, when stacked on the frontend > >> database, keeps looping until the stack is exhausted, since internal > >> modifications keep calling the frontend's modify hook rather than the > >> actual one that needs to be called. > > > > I have no idea how to fix it. I probably do not understand the > > manipulation > > with BackedInfo structures fully. > > > > It is obious that it is caused by doing a search from the modrdn operation > > callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). > > Other backends does not call any backend operation at the same moment > > (op->callback). > > > > Frontend fe_op_search() is called. It tries to choose the right backend > > with select_backend(). Which returns the overlay backend (bi_type == > > "over"), over_op_walk() then selects fe_op_search() again, and we are > > looping infinitely. > > > > I have no clue how to hide or temporarily deactivate the overlay in > > memberof_res_modrdn() to make the select_backend() function to choose the > > right underlaying backend. Or maybe I have choosen a wrong way of fixing > > it. > > > > All ideas are welcomed. :-) > > The attached diff fixes this particular problem. I haven't spent any time to > see if the other be_* invocations need to be protected the same way. Thank you. I have added this check to another places (attaching patch). But it seems that it is not sufficient. In certain situations I can still trigger the segfault - from memberof_res_modrdn() by calling backend_attribute(). At a first glance, the circumstances are a little bit different but I see no difference in the structures when calling the function with overlay set on frontend and backend database. I hope I will have some time to look at it soon. (gdb) bt -30 #35697 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35698 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35699 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35700 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35701 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35702 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35703 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35704 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35705 0x00000000004dd448 in fe_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/frontend.c:62 #35706 0x00000000004d9368 in overlay_entry_get_ov (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28, on=0x0) at ../../../servers/slapd/backover.c:364 #35707 0x00000000004d9460 in over_entry_get_rw (op=0x7fffe40028f0, dn=0x7ffff23d9050, oc=0x0, ad=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backover.c:396 #35708 0x000000000044fc46 in be_entry_get_rw (op=0x7fffe40028f0, ndn=0x7ffff23d9050, oc=0x0, at=0x9e8450, rw=0, e=0x7ffff23d8d28) at ../../../servers/slapd/backend.c:1366 #35709 0x0000000000450990 in fe_acl_attribute (op=0x7fffe40028f0, target=0x0, edn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backend.c:1658 #35710 0x00000000004d9cdb in over_acl_attribute (op=0x7fffe40028f0, target=0x0, entry_ndn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backover.c:589 #35711 0x0000000000450ed5 in backend_attribute (op=0x7fffe40028f0, target=0x0, edn=0x7ffff23d9050, entry_at=0x9e8450, vals=0x7ffff23d9088, access=ACL_READ) at ../../../servers/slapd/backend.c:1778 #35712 0x00000000005a4c9f in memberof_res_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../../servers/slapd/overlays/memberof.c:1558 #35713 0x000000000045252c in slap_response_play (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:507 #35714 0x0000000000452768 in send_ldap_response (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:582 #35715 0x0000000000453952 in slap_send_ldap_result (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/result.c:860 #35716 0x000000000050dfa9 in bdb_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../../servers/slapd/back-bdb/modrdn.c:789 #35717 0x00000000004625be in fe_op_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/modrdn.c:314 #35718 0x00000000004d9ed4 in overlay_op_walk (op=0x7fffe40028f0, rs=0x7ffff23d9a60, which=op_modrdn, oi=0x7fffe41050e0, on=0x0) at ../../../servers/slapd/backover.c:671 #35719 0x00000000004da125 in over_op_func (op=0x7fffe40028f0, rs=0x7ffff23d9a60, which=op_modrdn) at ../../../servers/slapd/backover.c:723 #35720 0x00000000004da2b2 in over_op_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/backover.c:768 #35721 0x0000000000461d20 in do_modrdn (op=0x7fffe40028f0, rs=0x7ffff23d9a60) at ../../../servers/slapd/modrdn.c:186 #35722 0x000000000043a8df in connection_operation (ctx=0x7ffff23d9ba0, arg_v=0x7fffe40028f0) at ../../../servers/slapd/connection.c:1150 #35723 0x000000000043ae9c in connection_read_thread (ctx=0x7ffff23d9ba0, argv=0x15) at ../../../servers/slapd/connection.c:1286 #35724 0x00000000005d12ce in ldap_int_thread_pool_wrapper (xpool=0x9b0bf0) at ../../../libraries/libldap_r/tpool.c:688 #35725 0x00007ffff73e4d90 in start_thread () from /lib64/libpthread.so.0 #35726 0x00007ffff5cf5f5d in clone () from /lib64/libc.so.6 --nextPart2505210.xvcxic42sH Content-Disposition: attachment; filename="memberof_partial.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="memberof_partial.patch" diff --git a/servers/slapd/overlays/memberof.c b/servers/slapd/overlays/memberof.c index 502cb46..356c1e6 100644 --- a/servers/slapd/overlays/memberof.c +++ b/servers/slapd/overlays/memberof.c @@ -190,7 +190,16 @@ typedef struct memberof_cbinfo_t { BerVarray memberof; memberof_is_t what; } memberof_cbinfo_t; - + +static void +memberof_set_backend(Operation *op_target, Operation *op, slap_overinst *on) +{ + BackendInfo *bi = op->o_bd->bd_info; + + if (bi->bi_type == memberof.on_bi.bi_type) + op_target->o_bd->bd_info = (BackendInfo *)on->on_info; +} + static int memberof_isGroupOrMember_cb( Operation *op, SlapReply *rs ) { @@ -285,7 +294,7 @@ memberof_isGroupOrMember( Operation *op, memberof_cbinfo_t *mci ) op2.ors_filterstr = mo->mo_groupFilterstr; op2.ors_filter = &mo->mo_groupFilter; - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_search( &op2, &rs2 ); op2.o_bd->bd_info = bi; @@ -307,7 +316,7 @@ memberof_isGroupOrMember( Operation *op, memberof_cbinfo_t *mci ) op2.ors_filterstr = mo->mo_memberFilterstr; op2.ors_filter = &mo->mo_memberFilter; - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_search( &op2, &rs2 ); op2.o_bd->bd_info = bi; @@ -407,7 +416,7 @@ memberof_value_modify( oex.oe_key = (void *)&memberof; LDAP_SLIST_INSERT_HEAD(&op2.o_extra, &oex, oe_next); - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_modify( &op2, &rs2 ); op2.o_bd->bd_info = bi; LDAP_SLIST_REMOVE(&op2.o_extra, &oex, OpExtra, oe_next); @@ -449,7 +458,7 @@ memberof_value_modify( oex.oe_key = (void *)&memberof; LDAP_SLIST_INSERT_HEAD(&op2.o_extra, &oex, oe_next); - op2.o_bd->bd_info = (BackendInfo *)on->on_info; + memberof_set_backend(&op2, op, on); (void)op->o_bd->be_modify( &op2, &rs2 ); op2.o_bd->bd_info = bi; LDAP_SLIST_REMOVE(&op2.o_extra, &oex, OpExtra, oe_next); --nextPart2505210.xvcxic42sH--

1 0

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

06 May '12

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

1 0

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

02 May '12

ondrej.kuznik(a)acision.com wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20120423-slapmodify-support.t… > Submission from: (NULL) (62.168.56.1) > > > When calling mdb_tool_entry_modify, a new transaction is being set up and this > hangs the process on a mutex that the thread already holds. > > For a possible patch see the last patch in the series at the above URL. Thanks for the report. Your fix is incomplete, a working fix is in git master now. > > The attached file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by Acision. Acision has not assigned rights > and/or interest in this work to any party. I, Ondrej Kuznik am > authorized by Acision, my employer, to release this work under the > following terms. > > The attached modifications to OpenLDAP Software are subject to the > following notice: > Copyright 2012 Acision > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

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

02 May '12

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

1 0

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

27 Apr '12

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

1 0

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

26 Apr '12

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

1 0

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

26 Apr '12

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

1 0

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

25 Apr '12

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

1 0

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

25 Apr '12

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

1 0

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

25 Apr '12

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

1 0

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

25 Apr '12

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

1 0

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

25 Apr '12

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs