openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#7694) cldap fails with IPv6 due to wrong size sockaddr
by stefw＠redhat.com 12 Sep '13

12 Sep '13

Full_Name: Stef Walter Version: 2.4.35 OS: Fedora 19 URL: ftp://ftp.openldap.org/incoming/stef-walter-130912.patch Submission from: (NULL) (46.5.2.70) Connectionless LDAP (ie: cldap enabled with -DLDAP_CONNECTIONLESS) is broken for IPv6 for current versions of openldap. Tested with version 2.4.35 It's not clear if this ever worked properly. Connections immediately fail with: ldap_search_ext: Can't contact LDAP server (-1) The reason for this is that the LDAP_CONNECTIONLESS buffers include a prefix containing an address in a "struct sockaddr". However, struct sockaddr, is not a concrete type. In particular struct sockaddr_in6 is longer than struct sockaddr. Noted here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… So this leads to failures when using IPv6 as the code assumes that the address length is equal to sizeof (struct sockaddr). Seen here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/… Example command: $ ldapsearch -d -1 -LL -H 'cldap://[2620:52:0:2223::1:1]' -b '' -s base '(&(DnsDomain=ad.baseos.qe)(NtVer=\06\00\00\00))' NetLogon Output will contain this: ldap_write: want=96 error=Invalid argument Which is the EINVAL resulting from bad value passed to sendto().

1 0

(ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 12 Sep '13

12 Sep '13

Full_Name: Mike Teichler Version: 2.4 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.152.191.58) Hello, I have an Issue with the ProxyCache on OpenLDAP (2.4.23-32.el6_4.1)[CentOS 6] which should Cache the Queryanswers from an OpenLDAP ( 2.3.43-12.el5_7.9)[CentOS 5] Server. The Problem isn't the Proxy but the Cache. When I do a query, i get the right Answer. But if I look into the LDAP.log with locklevel=2048, I always get the Strings: QUERY NOT ANSWERABLE QUERY NOT CACHABLE and if I shutdown the Server where the Proxy get its Informations it doesn't answers to the same query. My Konfiguration: In: /etc/openldap/slapd.d/olcDatabase={1}ldap/olcOverlay={0}pcache.ldif dn: olcOverlay={0}pcache objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {0}pcache olcPcache: bdb 100000 30 1000 3600 olcPcacheAttrset: 0 objectClass gidNumber mail cn uid displayName uidNumber ou userPassword olcPcacheTemplate: "(objectClass=)" 0 3600 olcPcachePosition: tail olcPcacheMaxQueries: 10000 olcPcacheValidate: FALSE structuralObjectClass: olcPcacheConfig entryUUID: 3a14c15c-ab42-1032-824e-7d8dac3932bf creatorsName: cn=config createTimestamp: 20130906131604Z olcPcacheOffline: FALSE olcPcachePersist: TRUE entryCSN: 20130910133719.273176Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130910133719Z In: /etc/openldap/slapd.d/olcDatabase={1}ldap/olcOverlay={0}pcache/olcDatabase={0}bdb.ldif dn: olcDatabase={0}bdb objectClass: olcBdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}bdb olcDbDirectory: /var/lib/ldap olcDbCacheSize: 10000 olcDbConfig: {0} # olcDbConfig: {1} # Set the database in memory cache size. olcDbConfig: {2} # olcDbConfig: {3} set_cachesize 0 524288000 1 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: displayName pres,eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 3a14cbde-ab42-1032-824f-7d8dac3932bf creatorsName: cn=config createTimestamp: 20130906131604Z entryCSN: 20130906131604.110178Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20130906131604Z If you need more Informations please ask. best regards, M. Teichler

1 0

(ITS#7692) segfault in overlay constraint - constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at constraint.c:713
by coudot＠linagora.com 12 Sep '13

12 Sep '13

Full_Name: Clement OUDOT Version: 2.4.35 OS: CentOS 6 64bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.145.72.122) I use the overlay constraint to check that a value of the attribute ssoRoles exists in the directory. The configuration looks like this: ---------------------------------------------- overlay constraint constraint_attribute ssoRoles uri ldap:///ou=applications,dc=cirra,dc=net?entrydn?sub?(&(objectClass=organizationalUnit)(ou:dn:=roles)) restrict="ldap:///ou=users,dc=cirra,dc=net??one?(objectClass=inetOrgPerson)" ---------------------------------------------- An ldapmodify with this LDIF crash the slapd process: ---------------------------------------------- dn: uid=toto,ou=users,dc=cirra,dc=net changetype: modify add: ssoRoles ssoRoles: ou=ROLE_PES,ou=roles,ou=simabo,ou=applications,dc=cirra,dc=net ---------------------------------------------- The crash occurs because the entry uid=toto,ou=users,dc=cirra,dc=net do not exist. The same LDIF on an existing entry works well. Below is the stacktrace generated with gdb: ---------------------------------------------- (gdb) run -d 0 Starting program: /usr/local/openldap/libexec/slapd -d 0 [Thread debugging using libthread_db enabled] [New Thread 0x7fffb3d42700 (LWP 16519)] [New Thread 0x7fffb3541700 (LWP 16521)] [New Thread 0x7fffb2d40700 (LWP 16522)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb2d40700 (LWP 16522)] constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at constraint.c:713 713 int diff = e->e_nname.bv_len - c->restrict_ndn.bv_len; Missing separate debuginfos, use: debuginfo-install berkeleydb-ltb-4.6.21.NC-4.el6.patch4.x86_64 cyrus-sasl-gssapi-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-ldap-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-lib-2.1.23-13.el6_3.1.x86_64 cyrus-sasl-plain-2.1.23-13.el6_3.1.x86_64 db4-4.7.25-17.el6.x86_64 glibc-2.12-1.107.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6.x86_64 libcom_err-1.41.12-14.el6.x86_64 libselinux-2.0.94-5.3.el6.x86_64 libtool-ltdl-2.2.6-15.5.el6.x86_64 nss-softokn-freebl-3.12.9-11.el6.x86_64 openssl-1.0.0-27.el6.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) bt full #0 constraint_check_restrict (op=0x7fffa8000960, c=0x9e60f0, e=0x0) at constraint.c:713 diff = <value optimized out> __PRETTY_FUNCTION__ = "constraint_check_restrict" #1 0x000000000054b39f in constraint_update (op=<value optimized out>, rs=0x7fffb2d3f950) at constraint.c:989 j = <value optimized out> ce = 0 on = 0x9e5e30 be = 0x7fffb2d3e4e0 c = 0x9e60f0 cp = <value optimized out> target_entry = 0x0 target_entry_copy = 0x0 modlist = 0x7fffa8000920 m = 0x7fffa8000920 b = 0x7fffa81015c0 i = <value optimized out> rsv = {bv_len = 24, bv_val = 0x60f2a4 "modify breaks constraint"} rc = <value optimized out> msg = 0x0 is_v = <value optimized out> #2 0x00000000004a6d7a in overlay_op_walk (op=0x7fffa8000960, rs=0x7fffb2d3f950, which=op_modify, oi=0x9e1020, on=0x9e5e30) at backover.c:661 func = 0x9e5e88 rc = 32768 #3 0x00000000004a7847 in over_op_func (op=0x7fffa8000960, rs=<value optimized out>, which=<value optimized out>) at backover.c:723 oi = <value optimized out> on = <value optimized out> be = 0x9ba220 db = {bd_info = 0x9e5e30, bd_self = 0x9ba220, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\001", '\000' <repeats 12 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x9dca20, be_nsuffix = 0x9dca50, be_schemadn = { bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 26, bv_val = 0x9dcb70 "cn=manager,dc=cirra,dc=net"}, be_rootndn = {bv_len = 26, bv_val = 0x9dcbc0 "cn=manager,dc=cirra,dc=net"}, be_rootpw = {bv_len = 38, bv_val = 0x9dc8b0 "{SSHA}2S9rqrduHEq4AcNIfS+wxClQwbD5aoLn"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x9e01a0, be_acl = 0x9b9850, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, ---Type <return> to continue, or q <return> to quit--- be_pending_csn_list = 0xa6f7f0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x8838c0, be_private = 0x9ba3c0, be_next = { stqe_next = 0x9e6470}} cb = {sc_next = 0x0, sc_response = 0x4a6af0 <over_back_response>, sc_cleanup = 0, sc_private = 0x9e1020} sc = <value optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #4 0x000000000045728b in fe_op_modify (op=0x7fffa8000960, rs=0x7fffb2d3f950) at modify.c:303 update = <value optimized out> repl_user = <value optimized out> op_be = <value optimized out> bd = 0x88c200 textbuf = ">\000\000\000\000\000\000\000\240\030\020\250\377\177\000\000\000\000\000\000\000\000\000\000@\026\020\250\377\177\000\000\240\235G\000\000\000\000\000\267\244E", '\000' <repeats 13 times>, "\003\000\000\000\060\000\000\000[\000\000\000|", '\000' <repeats 11 times>, "\b", '\000' <repeats 31 times>, ">\000\000\000\000\000\000\000\360\025\020\250\377\177\000\000\000\000\000\000\000\000\000\000 \t\000\250\377\177\000\000\000\000\000\000\000\000\000\000@É #5 0x0000000000457bb6 in do_modify (op=0x7fffa8000960, rs=0x7fffb2d3f950) at modify.c:177 dn = {bv_len = 33, bv_val = 0x7fffa8101507 "uid=toto,ou=users,dc=cirra,dc=net"} textbuf = "\027\f\000\250\377\177", '\000' <repeats 42 times>, "PG\253\367\000\000\000\000P\333\377\367\377\177\000\000\000\000A", '\000' <repeats 13 times>, "\030f@\000\000\000\000\000Y\345`\237\064", '\000' <repeats 11 times>"\351, \363[\000\000\000\000\000`\t\000\250\377\177\000\000\340\024\302\236\064\000\000\000\377\377\377\377\377\177\000\000\030\372Ó²\377\177\000\000\210\021\302\236\064\000\000\000@\304X\237\064", '\000' <repeats 11 times>, ":\236\240\236\064\000\000\000\320\016\000\250\377\177\000\000\000\000\020\000\000\000\000\000\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\260\372Ó²\377\177\000\000\360.I", '\000' <repeats 13 times>, "\t\000\000\000\062\000\000\000`\t\000\250\377\177\000\000\320\016\000\250\377\177\000" tmp = <value optimized out> #6 0x000000000043f9a9 in connection_operation (ctx=0x7fffb2d3fab0, arg_v=0x7fffa8000960) at connection.c:1155 rc = 80 cancel = <value optimized out> op = 0x7fffa8000960 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = 0x7ffff632bc10 ---Type <return> to continue, or q <return> to quit--- memctx = 0x7fffa8000ed0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #7 0x0000000000440195 in connection_read_thread (ctx=0x7fffb2d3fab0, argv=<value optimized out>) at connection.c:1291 rc = <value optimized out> cri = {op = 0x7fffa8000960, func = 0, arg = 0x0, ctx = 0x7fffb2d3fab0, nullop = <value optimized out>} s = <value optimized out> #8 0x0000000000593d00 in ldap_int_thread_pool_wrapper (xpool=0x960c00) at tpool.c:688 pool = 0x960c00 task = 0x7fffac0008c0 work_list = <value optimized out> ctx = {ltu_id = 140736193627904, ltu_key = {{ltk_key = 0x43e7c0, ltk_data = 0x7fffa8000dc0, ltk_free = 0x43e890 <conn_counter_destroy>}, {ltk_key = 0x492d40, ltk_data = 0x7fffa8000ed0, ltk_free = 0x492d60 <slap_sl_mem_destroy>}, {ltk_key = 0xa6f810, ltk_data = 0x7fffa8100f80, ltk_free = 0x4f7280 <bdb_reader_free>}, {ltk_key = 0x452ba0, ltk_data = 0x0, ltk_free = 0x452970 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>, { ltk_key = 0x0, ltk_data = 0x349f607eea, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = <value optimized out> keyslot = 555 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #9 0x000000349f607851 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #10 0x000000349f2e890d in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) ---------------------------------------------- Please tell me if something else is needed in this bug report. Regards, Clement OUDOT.

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by quanah＠zimbra.com 11 Sep '13

11 Sep '13

--On Thursday, September 12, 2013 3:31 AM +0000 chewcs(a)bii.a-star.edu.sg wrote: > This is a multi-part message in MIME format. > --------------010103040709080503030708 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > One more thing: the ldap master version is > > Openldap 2.3.40 on sunOS Syncrepl in 2.3.40 is known to be broken. I would advise you to upgrade it to 2.4.36. This ITS will be closed as invalid. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by chewcs＠bii.a-star.edu.sg 11 Sep '13

11 Sep '13

This is a multi-part message in MIME format. --------------010103040709080503030708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One more thing: the ldap master version is Openldap 2.3.40 on sunOS While the ldap slave is : OpenLDAP: slapd 2.4.36 (Aug 21 2013 09:39:54) On 09/12/13 10:23, CHEW Chee Siang wrote: > One more thing. The entry with "cn=depth" name won't sync only when > adding entries to ou=mailinglist. Somehow it is ok with ou=people. > > > > "Master" LDAP configuration: > /Include /go/to/core.schema// > //Include /go/to/cosine.schema// > //Include /go/to/inetorgperson.schema// > //Include /go/to/nis.schema// > //Include /go/to/samba.schema// > //Include /go/to/test.schema// > //pidfile /go/to/slapd.pid// > //argsfile /go/to/slapd.args/ > > TLSCipherSuite HIGH:MEDIUM:+SSLv2 > /TLSCACertificateFile /go/to/ldap.pem// > //TLSCertificateFile /go/to/ldap.pem// > //TLSCertificateKeyFile /go/to/ldap.key/ > > access to attrs=userPassword > by self write > by users read > by peername.ip=127.0.0.1 read > by peername.ip=10.X.0.0%255.255.0.0 read > by peername.ip=172.X.129.132 read > by peername.ip=172.X.1.109 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=X.X.68.0%255.255.255.0 read > by anonymous auth > > access to attrs=cryptPassword,md5Password,shadowLastChange > by self write > by users read > by peername.ip=127.0.0.1 read > by peername.ip=10.217.0.0%255.255.0.0 read > by peername.ip=172.X.129.132 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=X.X.68.0%255.255.255.0 read > by anonymous none > > access to dn.subtree="ou=zgroups,dc=test,dc=com > by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write > by self read > by users read > by peername.ip=127.0.0.1 read > by peername.ip=10.X.0.0%255.255.0.0 read > by peername.ip=X.X.X.0%255.255.255.0 read > by peername.ip=172.X.129.132 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by anonymous none > > access to * > by self read > by users read > by peername.ip=127.0.0.1 read > by peername.ip=10.X.0.0%255.255.0.0 read > by peername.ip=172.X.129.132 read > by peername.ip=172.X.1.109 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=172.X.0.0%255.255.0.0 read > by peername.ip=X.X.68.0%255.255.255.0 read > by anonymous none > > # Database backend configuration. > > allow bind_v2 > database bdb > password-hash {CRYPT} > directory /go/to/ldap-master > suffix "dc=test,dc=com" > rootdn "cn=root,dc=test,dc=com" > rootpw secret > index objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq > > # Configure syncrepl (provider) > > overlay syncprov > syncprov-checkpoint 1 1 # <ops> <minutes> > syncprov-sessionlog 100 # <max number of session logs> > > > > > "Slave" LDAP configuration: > include /usr/local/openldap/etc/openldap/schema/core.schema > include //usr/local/openldap/etc/openldap/schema/test.schema/ > include /usr/local/openldap/etc/openldap/schema/cosine.schema > include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema > include /usr/local/openldap/etc/openldap/schema/nis.schema > include /usr/local/openldap/etc/openldap/schema/samba.schema > > > # Define global ACLs to disable default read access. > allow bind_v2 > > pidfile /usr/local/openldap/var/run/slapd.pid > argsfile /usr/local/openldap/var/run/slapd.args > loglevel 256 > moduleload back_hdb.la > moduleload syncprov.la > moduleload back_monitor.la > moduleload back_ldap.la > > access to * > by self write > by users read > by peername.ip=127.0.0.1 read > by peername.ip=172.20.201.0%255.255.255.0 read > by anonymous read > > ####################################################################### > # BDB database definitions > ####################################################################### > > database bdb > suffix /"dc=test,dc=com"/ > rootdn "cn=Manager,/dc=test,dc=com"/ > rootpw secret > directory /usr/local/openldap/var/openldap-data > > # Indices to maintain > index cn,sn,uid pres,eq,approx,sub > index objectClass eq > > > index entryCSN,entryUUID eq > syncrepl rid=1 > provider=/ldap://ldap-master.com/ > type=refreshOnly > interval=00:00:00:30 > searchbase=/"dc=test,dc=com"/ > scope=sub > schemachecking=off > bindmethod=simple > binddn=/"cn=ldaplogin,ou=people,dc=test,dc=com"/ > credentials=/secret/ > > > On 09/12/13 05:57, Quanah Gibson-Mount wrote: >> --On Wednesday, September 11, 2013 8:03 AM +0000 >> chewcs(a)bii.a-star.edu.sg wrote: >> >>> Full_Name: Chew Chee Siang >>> Version: slapd 2.4.36 >>> OS: CentOS 6.4 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (123.136.68.2) >>> >>> >>> The setup is a master-slave configuration >>> Whenever a new user with name starting with "depth" is created at >>> master, >>> the record will not be sync to slave using syncrepl. >>> The other records are ok. >>> For e.g. cn=depth-maker,ou=people,dc=tt,dc=com >>> or cn=depth,ou=people,dc=tt,dc=com >> >> Provide your configuration minus passwords. >> >> --Quanah >> >> >> >> -- >> >> Quanah Gibson-Mount >> Lead Engineer >> Zimbra, Inc >> -------------------- >> Zimbra :: the leader in open source messaging and collaboration >> > --------------010103040709080503030708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">One more thing: the ldap master version is <pre wrap="">Openldap 2.3.40 on sunOS </pre> <pre wrap="">While the ldap slave is : </pre> OpenLDAP: slapd 2.4.36 (Aug 21 2013 09:39:54) On 09/12/13 10:23, CHEW Chee Siang wrote: </div> <blockquote cite="mid:523125B9.2020004@bii.a-star.edu.sg" type="cite"> <meta http-equiv="Context-Type" content="text/html; charset=ISO-8859-1"> <div class="moz-cite-prefix">One more thing. The entry with "cn=depth" name won't sync only when adding entries to ou=mailinglist. Somehow it is ok with ou=people. "Master" LDAP configuration: Include        /go/to/core.schema Include     /go/to/cosine.schema Include     /go/to/inetorgperson.schema Include     /go/to/nis.schema Include     /go/to/samba.schema Include     /go/to/test.schema pidfile        /go/to/slapd.pid argsfile    /go/to/slapd.args TLSCipherSuite        HIGH:MEDIUM:+SSLv2 TLSCACertificateFile    /go/to/ldap.pem TLSCertificateFile      /go/to/ldap.pem TLSCertificateKeyFile   /go/to/ldap.key access to attrs=userPassword   by self write   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.1.109 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous auth access to attrs=cryptPassword,md5Password,shadowLastChange   by self write   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.217.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous none access to dn.subtree="ou=zgroups,dc=test,dc=com   by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write   by self read   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=X.X.X.0%255.255.255.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by anonymous none access to *   by self read   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.1.109 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous none # Database backend configuration. allow        bind_v2 database    bdb password-hash    {CRYPT} directory    /go/to/ldap-master suffix        "dc=test,dc=com" rootdn        "cn=root,dc=test,dc=com" rootpw        secret index        objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq # Configure syncrepl (provider) overlay            syncprov syncprov-checkpoint    1 1        # <ops> <minutes> syncprov-sessionlog    100        # <max number of session logs> "Slave" LDAP configuration: include        /usr/local/openldap/etc/openldap/schema/core.schema include     /usr/local/openldap/etc/openldap/schema/test.schema include     /usr/local/openldap/etc/openldap/schema/cosine.schema include     /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include     /usr/local/openldap/etc/openldap/schema/nis.schema include     /usr/local/openldap/etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. allow bind_v2 pidfile        /usr/local/openldap/var/run/slapd.pid argsfile    /usr/local/openldap/var/run/slapd.args loglevel 256 moduleload      back_hdb.la moduleload      syncprov.la moduleload      back_monitor.la moduleload      back_ldap.la access to *      by self write      by users read      by peername.ip=127.0.0.1 read      by peername.ip=172.20.201.0%255.255.255.0 read      by anonymous read ####################################################################### # BDB database definitions ####################################################################### database    bdb suffix        "dc=test,dc=com" rootdn        "cn=Manager,dc=test,dc=com" rootpw        secret directory    /usr/local/openldap/var/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub index    objectClass    eq index entryCSN,entryUUID eq syncrepl                rid=1                         provider=<a moz-do-not-send="true" class="moz-txt-link-freetext">ldap://ldap-master.com</a>                         type=refreshOnly                         interval=00:00:00:30                         searchbase="dc=test,dc=com"                         scope=sub                         schemachecking=off                         bindmethod=simple                         binddn="cn=ldaplogin,ou=people,dc=test,dc=com"                         credentials=secret On 09/12/13 05:57, Quanah Gibson-Mount wrote: </div> <blockquote cite="mid:75FEF2DB661402B3EB284EDD@%5B192.168.1.22%5D" type="cite">--On Wednesday, September 11, 2013 8:03 AM +0000 <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:chewcs@bii.a-star.edu.sg">chewcs(a)bii.a-star.edu.sg</a> wrote: <blockquote type="cite">Full_Name: Chew Chee Siang Version: slapd 2.4.36 OS: CentOS 6.4 URL: <a moz-do-not-send="true" class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (123.136.68.2) The setup is a master-slave configuration Whenever a new user with name starting with "depth" is created at master, the record will not be sync to slave using syncrepl. The other records are ok. For e.g. cn=depth-maker,ou=people,dc=tt,dc=com or cn=depth,ou=people,dc=tt,dc=com </blockquote> Provide your configuration minus passwords. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration </blockquote> </blockquote> </body> </html> --------------010103040709080503030708--

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by chewcs＠bii.a-star.edu.sg 11 Sep '13

11 Sep '13

This is a multi-part message in MIME format. --------------040706000700030201020504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One more thing. The entry with "cn=depth" name won't sync only when adding entries to ou=mailinglist. Somehow it is ok with ou=people. "Master" LDAP configuration: /Include /go/to/core.schema// //Include /go/to/cosine.schema// //Include /go/to/inetorgperson.schema// //Include /go/to/nis.schema// //Include /go/to/samba.schema// //Include /go/to/test.schema// //pidfile /go/to/slapd.pid// //argsfile /go/to/slapd.args/ TLSCipherSuite HIGH:MEDIUM:+SSLv2 /TLSCACertificateFile /go/to/ldap.pem// //TLSCertificateFile /go/to/ldap.pem// //TLSCertificateKeyFile /go/to/ldap.key/ access to attrs=userPassword by self write by users read by peername.ip=127.0.0.1 read by peername.ip=10.X.0.0%255.255.0.0 read by peername.ip=172.X.129.132 read by peername.ip=172.X.1.109 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=X.X.68.0%255.255.255.0 read by anonymous auth access to attrs=cryptPassword,md5Password,shadowLastChange by self write by users read by peername.ip=127.0.0.1 read by peername.ip=10.217.0.0%255.255.0.0 read by peername.ip=172.X.129.132 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=X.X.68.0%255.255.255.0 read by anonymous none access to dn.subtree="ou=zgroups,dc=test,dc=com by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write by self read by users read by peername.ip=127.0.0.1 read by peername.ip=10.X.0.0%255.255.0.0 read by peername.ip=X.X.X.0%255.255.255.0 read by peername.ip=172.X.129.132 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by anonymous none access to * by self read by users read by peername.ip=127.0.0.1 read by peername.ip=10.X.0.0%255.255.0.0 read by peername.ip=172.X.129.132 read by peername.ip=172.X.1.109 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=172.X.0.0%255.255.0.0 read by peername.ip=X.X.68.0%255.255.255.0 read by anonymous none # Database backend configuration. allow bind_v2 database bdb password-hash {CRYPT} directory /go/to/ldap-master suffix "dc=test,dc=com" rootdn "cn=root,dc=test,dc=com" rootpw secret index objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq # Configure syncrepl (provider) overlay syncprov syncprov-checkpoint 1 1 # <ops> <minutes> syncprov-sessionlog 100 # <max number of session logs> "Slave" LDAP configuration: include /usr/local/openldap/etc/openldap/schema/core.schema include //usr/local/openldap/etc/openldap/schema/test.schema/ include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. allow bind_v2 pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args loglevel 256 moduleload back_hdb.la moduleload syncprov.la moduleload back_monitor.la moduleload back_ldap.la access to * by self write by users read by peername.ip=127.0.0.1 read by peername.ip=172.20.201.0%255.255.255.0 read by anonymous read ####################################################################### # BDB database definitions ####################################################################### database bdb suffix /"dc=test,dc=com"/ rootdn "cn=Manager,/dc=test,dc=com"/ rootpw secret directory /usr/local/openldap/var/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub index objectClass eq index entryCSN,entryUUID eq syncrepl rid=1 provider=/ldap://ldap-master.com/ type=refreshOnly interval=00:00:00:30 searchbase=/"dc=test,dc=com"/ scope=sub schemachecking=off bindmethod=simple binddn=/"cn=ldaplogin,ou=people,dc=test,dc=com"/ credentials=/secret/ On 09/12/13 05:57, Quanah Gibson-Mount wrote: > --On Wednesday, September 11, 2013 8:03 AM +0000 > chewcs(a)bii.a-star.edu.sg wrote: > >> Full_Name: Chew Chee Siang >> Version: slapd 2.4.36 >> OS: CentOS 6.4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (123.136.68.2) >> >> >> The setup is a master-slave configuration >> Whenever a new user with name starting with "depth" is created at >> master, >> the record will not be sync to slave using syncrepl. >> The other records are ok. >> For e.g. cn=depth-maker,ou=people,dc=tt,dc=com >> or cn=depth,ou=people,dc=tt,dc=com > > Provide your configuration minus passwords. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Lead Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > --------------040706000700030201020504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">One more thing. The entry with "cn=depth" name won't sync only when adding entries to ou=mailinglist. Somehow it is ok with ou=people. "Master" LDAP configuration: Include        /go/to/core.schema Include     /go/to/cosine.schema Include     /go/to/inetorgperson.schema Include     /go/to/nis.schema Include     /go/to/samba.schema Include     /go/to/test.schema pidfile        /go/to/slapd.pid argsfile    /go/to/slapd.args TLSCipherSuite        HIGH:MEDIUM:+SSLv2 TLSCACertificateFile    /go/to/ldap.pem TLSCertificateFile      /go/to/ldap.pem TLSCertificateKeyFile   /go/to/ldap.key access to attrs=userPassword   by self write   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.1.109 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous auth access to attrs=cryptPassword,md5Password,shadowLastChange   by self write   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.217.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous none access to dn.subtree="ou=zgroups,dc=test,dc=com   by dn.base="cn=webXXX,ou=people,dc=test,dc=com" write   by self read   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=X.X.X.0%255.255.255.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by anonymous none access to *   by self read   by users read   by peername.ip=127.0.0.1 read   by peername.ip=10.X.0.0%255.255.0.0 read   by peername.ip=172.X.129.132 read   by peername.ip=172.X.1.109 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=172.X.0.0%255.255.0.0 read   by peername.ip=X.X.68.0%255.255.255.0 read   by anonymous none # Database backend configuration. allow        bind_v2 database    bdb password-hash    {CRYPT} directory    /go/to/ldap-master suffix        "dc=test,dc=com" rootdn        "cn=root,dc=test,dc=com" rootpw        secret index        objectClass,uid,uidNumber,entryCSN,entryUUID pres,eq # Configure syncrepl (provider) overlay            syncprov syncprov-checkpoint    1 1        # <ops> <minutes> syncprov-sessionlog    100        # <max number of session logs> "Slave" LDAP configuration: include        /usr/local/openldap/etc/openldap/schema/core.schema include     /usr/local/openldap/etc/openldap/schema/test.schema include     /usr/local/openldap/etc/openldap/schema/cosine.schema include     /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include     /usr/local/openldap/etc/openldap/schema/nis.schema include     /usr/local/openldap/etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. allow bind_v2 pidfile        /usr/local/openldap/var/run/slapd.pid argsfile    /usr/local/openldap/var/run/slapd.args loglevel 256 moduleload      back_hdb.la moduleload      syncprov.la moduleload      back_monitor.la moduleload      back_ldap.la access to *      by self write      by users read      by peername.ip=127.0.0.1 read      by peername.ip=172.20.201.0%255.255.255.0 read      by anonymous read ####################################################################### # BDB database definitions ####################################################################### database    bdb suffix        "dc=test,dc=com" rootdn        "cn=Manager,dc=test,dc=com" rootpw        secret directory    /usr/local/openldap/var/openldap-data # Indices to maintain index cn,sn,uid pres,eq,approx,sub index    objectClass    eq index entryCSN,entryUUID eq syncrepl                rid=1                         provider=<a class="moz-txt-link-freetext" href="ldap://ldap-master.com">ldap://ldap-master.com</a>                         type=refreshOnly                         interval=00:00:00:30                         searchbase="dc=test,dc=com"                         scope=sub                         schemachecking=off                         bindmethod=simple                         binddn="cn=ldaplogin,ou=people,dc=test,dc=com"                         credentials=secret On 09/12/13 05:57, Quanah Gibson-Mount wrote: </div> <blockquote cite="mid:75FEF2DB661402B3EB284EDD@%5B192.168.1.22%5D" type="cite">--On Wednesday, September 11, 2013 8:03 AM +0000 <a class="moz-txt-link-abbreviated" href="mailto:chewcs@bii.a-star.edu.sg">chewcs(a)bii.a-star.edu.sg</a> wrote: <blockquote type="cite">Full_Name: Chew Chee Siang Version: slapd 2.4.36 OS: CentOS 6.4 URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (123.136.68.2) The setup is a master-slave configuration Whenever a new user with name starting with "depth" is created at master, the record will not be sync to slave using syncrepl. The other records are ok. For e.g. cn=depth-maker,ou=people,dc=tt,dc=com or cn=depth,ou=people,dc=tt,dc=com </blockquote> Provide your configuration minus passwords. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra ::  the leader in open source messaging and collaboration </blockquote> </body> </html> --------------040706000700030201020504--

1 0

Re: (ITS#7691) syncrepl does not work with names start with depth
by quanah＠zimbra.com 11 Sep '13

11 Sep '13

--On Wednesday, September 11, 2013 8:03 AM +0000 chewcs(a)bii.a-star.edu.sg wrote: > Full_Name: Chew Chee Siang > Version: slapd 2.4.36 > OS: CentOS 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.136.68.2) > > > The setup is a master-slave configuration > Whenever a new user with name starting with "depth" is created at master, > the record will not be sync to slave using syncrepl. > The other records are ok. > For e.g. cn=depth-maker,ou=people,dc=tt,dc=com > or cn=depth,ou=people,dc=tt,dc=com Provide your configuration minus passwords. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7691) syncrepl does not work with names start with depth
by chewcs＠bii.a-star.edu.sg 11 Sep '13

11 Sep '13

Full_Name: Chew Chee Siang Version: slapd 2.4.36 OS: CentOS 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.136.68.2) The setup is a master-slave configuration Whenever a new user with name starting with "depth" is created at master, the record will not be sync to slave using syncrepl. The other records are ok. For e.g. cn=depth-maker,ou=people,dc=tt,dc=com or cn=depth,ou=people,dc=tt,dc=com

1 0

Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by pierangelo.masarati＠polimi.it 10 Sep '13

10 Sep '13

Thanks for the report; I have a quick fix, I'm testing it and will commit shortly. p. On 09/10/2013 09:14 PM, ck(a)cksoft.de wrote: > This message is in MIME format. The first part should be readable text, > while the remaining parts are likely unreadable without MIME-aware tools. > > --4178219828-1091139785-1378839346=:6609 > Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed > Content-Transfer-Encoding: 8BIT > Content-ID: <alpine.BSF.2.00.1309102056121.6609(a)pohjola.cksoft.de> > > Hi, > > On Tue, 10 Sep 2013, Michael Ströder wrote: > >> ck(a)cksoft.de wrote: >>> we have a java application using JNDI that uses the password modify extended >>> operation to change user passwords. >>> [..] >>> When running slapd with heavy logging we save the only difference to ldappasswd >>> which works fine against our masters is that JNDI sets the ManageDsaIT by >>> default. >> >> Of course slapd should never crash. > > yes of course not. This opens an attack vector for shooting down the slapd to at least anyone who has bind access which is concerning me. > > Apart from that the customers problem is solved. We just stopped sending the control. A bit like Dr. Dr. it hurts when I Do this. Then why don't you stop doing it. > >> But strictly speaking the semantics of using ManageDsaIT control along with >> password modify ext.op. is not specified - at least not in RFC 3062. > > yes. jndi sets the control by default. > >>From looking at the assert > > slapd: chain.c:199: chaining_control_remove: Assertion `op->o_ctrls != ((void *)0)' failed. > > the comment in chain.c seems to hint at an overly simple assumption. But in understand too little of slapd internals and code flow: > > 188 static int > 189 chaining_control_remove( > 190 Operation *op, > 191 LDAPControl ***oldctrlsp ) > 192 { > 193 LDAPControl **oldctrls = *oldctrlsp; > 194 > 195 /* we assume that the first control is the chaining control > 196 * added by the chain overlay, so it's the only one we explicitly > 197 * free */ > 198 if ( op->o_ctrls != oldctrls ) { > 199 assert( op->o_ctrls != NULL ); > 200 assert( op->o_ctrls[ 0 ] != NULL ); > 201 > 202 free( op->o_ctrls ); > 203 > 204 op->o_chaining = 0; > 205 op->o_ctrls = oldctrls; > 206 } > 207 > 208 *oldctrlsp = NULL; > 209 > 210 return 0; > 211 } > > > Could it be as simple as walking the linked list and just removing the chaining control. > > Of course another strategy might be to filter anything but the chaining control up front. > > Greetings > Christian > >> >> Ciao, Michael. >> >> > -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7687) slapd with chaining dies on ManageDsaIT control
by ck＠cksoft.de 10 Sep '13

10 Sep '13

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --4178219828-1091139785-1378839346=:6609 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: <alpine.BSF.2.00.1309102056121.6609(a)pohjola.cksoft.de> Hi, On Tue, 10 Sep 2013, Michael Ströder wrote: > ck(a)cksoft.de wrote: >> we have a java application using JNDI that uses the password modify extended >> operation to change user passwords. >> [..] >> When running slapd with heavy logging we save the only difference to ldappasswd >> which works fine against our masters is that JNDI sets the ManageDsaIT by >> default. > > Of course slapd should never crash. yes of course not. This opens an attack vector for shooting down the slapd to at least anyone who has bind access which is concerning me. Apart from that the customers problem is solved. We just stopped sending the control. A bit like Dr. Dr. it hurts when I Do this. Then why don't you stop doing it. > But strictly speaking the semantics of using ManageDsaIT control along with > password modify ext.op. is not specified - at least not in RFC 3062. yes. jndi sets the control by default. >From looking at the assert slapd: chain.c:199: chaining_control_remove: Assertion `op->o_ctrls != ((void *)0)' failed. the comment in chain.c seems to hint at an overly simple assumption. But in understand too little of slapd internals and code flow: 188 static int 189 chaining_control_remove( 190 Operation *op, 191 LDAPControl ***oldctrlsp ) 192 { 193 LDAPControl **oldctrls = *oldctrlsp; 194 195 /* we assume that the first control is the chaining control 196 * added by the chain overlay, so it's the only one we explicitly 197 * free */ 198 if ( op->o_ctrls != oldctrls ) { 199 assert( op->o_ctrls != NULL ); 200 assert( op->o_ctrls[ 0 ] != NULL ); 201 202 free( op->o_ctrls ); 203 204 op->o_chaining = 0; 205 op->o_ctrls = oldctrls; 206 } 207 208 *oldctrlsp = NULL; 209 210 return 0; 211 } Could it be as simple as walking the linked list and just removing the chaining control. Of course another strategy might be to filter anything but the chaining control up front. Greetings Christian > > Ciao, Michael. > > -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer --4178219828-1091139785-1378839346=:6609--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs