openldap-bugs April 2010

openldap-bugs@openldap.org

45 participants
233 discussions

(ITS#6520) ACL bug with various .expand styles
by kean.johnston＠gmail.com 13 Apr '10

13 Apr '10

Full_Name: Kean Johnston Version: 2.4.21 OS: Linux (Debian Lenny) URL: ftp://ftp.openldap.org/incoming/kean-johnston-100413.patch Submission from: (NULL) (41.133.19.25) Assumption: the following ACL should result in $0 being expanded for the set: access to dn.one="ou=hosts,dc=example,dc=com" attrs=authorizedService by set.expand="[cn=access,$0]/member* & user" compare by * =rsdx break Reason for assumption: man slapd.access states: Forms of the <what> clause other than regex may provide submatches as well. The base(object), the sub(tree), the one(level), and the chil- dren forms provide $0 as the match of the entire string. The sub(tree), the one(level), and the children forms also provide $1 as the match of the rightmost part of the DN as defined in the <what> clause. Bug: does not work as expected. The reason is that in slap.h slap_style_t starts with ACL_STYLE_REGEX = 0, so any structure that uses slap_style_t and uses memset to null out the structure will have its default style be ACL_STYLE_REGEX. In acl.c there are 4 places where you test for ACL_STYLE_REGEX on a->acl_attrval_style without checking if an actual attribute value was supplied. The patch below fixes those cases. The better (arguably) fix would be to change slap_style_t to start with ACL_STYLE_NONE = 0, and then explicitly set the style when it is encountered in aclparse.c. However, I did not want to change slap.h in case it changes some ABI and the change to aclparse.c is larger. As things currently stand, dn.expand, set.expand and group.expand will not expand $0 and $1 as documented if you use dn.{base,one,sub,children} in the what clause. I have attached a patch, and as per instruction: I, James Kean Johnston, 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. ftp://ftp.openldap.org/incoming/kean-johnston-100413.patch

1 0

Re: (ITS#6519) syncprov sends bogus cookie on accesslog purge
by quanah＠zimbra.com 13 Apr '10

13 Apr '10

--On Tuesday, April 13, 2010 9:07 PM +0000 openldap-its(a)OpenLDAP.org wrote: Here is the -d -1 output from the provider during this time period. You can clearly see part way through where the empty cookie is sent after a delete operation is completed. 01c0: 69 6c 31 24 04 22 75 73 65 72 2e 32 37 36 40 66 il1$."user.276@f 01d0: 72 65 65 6c 61 6e 63 65 72 2e 6c 61 62 2e 7a 69 reelancer.lab.zi 01e0: 6d 62 72 61 2e 63 6f 6d 30 11 04 03 75 69 64 31 mbra.com0...uid1 01f0: 0a 04 08 75 73 65 72 2e 32 37 36 30 43 04 0b 6f ...user.2760C..o 0200: 62 6a 65 63 74 43 6c 61 73 73 31 34 04 14 6f 72 bjectClass14..or 0210: 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 50 65 72 73 ganizationalPers 0220: 6f 6e 04 0d 7a 69 6d 62 72 61 41 63 63 6f 75 6e on..zimbraAccoun 0230: 74 04 0d 61 6d 61 76 69 73 41 63 63 6f 75 6e 74 t..amavisAccount 0240: 30 2f 04 1a 7a 69 6d 62 72 61 50 61 73 73 77 6f 0/..zimbraPasswo 0250: 72 64 4d 6f 64 69 66 69 65 64 54 69 6d 65 31 11 rdModifiedTime1. 0260: 04 0f 32 30 31 30 30 34 31 33 32 30 34 35 35 34 ..20100413204554 0270: 5a 30 10 04 02 63 6e 31 0a 04 08 75 73 65 72 2e Z0...cn1...user. 0280: 32 37 36 30 2d 04 0e 7a 69 6d 62 72 61 4d 61 69 2760-..zimbraMai 0290: 6c 48 6f 73 74 31 1b 04 19 66 72 65 65 6c 61 6e lHost1...freelan 02a0: 63 65 72 2e 6c 61 62 2e 7a 69 6d 62 72 61 2e 63 cer.lab.zimbra.c 02b0: 6f 6d om <= send_search_entry: conn 2605 exit. send_ldap_result: conn=2605 op=3 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=4 tag=101 err=0 ber_flush2: 14 bytes to sd 20 0000: 30 0c 02 01 04 65 07 0a 01 00 04 00 04 00 0....e........ tls_write: want=35, written=35 0000: 17 03 01 00 1e 59 2c c6 87 d7 64 fe a5 b5 74 e9 .....Y,...d...t. 0010: ff cf e6 00 22 30 dc 8b ed 0f c2 c9 aa d7 64 43 ...."0........dC 0020: 9a d2 3a ..: ldap_write: want=14, written=14 0000: 30 0c 02 01 04 65 07 0a 01 00 04 00 04 00 0....e........ conn=2605 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= daemon: activity on 1 descriptor daemon: activity on: 20r daemon: read active on 20 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(20) connection_get(20): got connid=2605 connection_read(20): checking for input on id=2605 ber_get_next tls_read: want=5, got=5 0000: 15 03 01 00 12 ..... tls_read: want=18, got=18 0000: 07 3e f1 34 3c 74 48 e4 2d 64 da bf 16 b2 f0 e3 .>.4<tH.-d...... 0010: 82 1f .. TLS trace: SSL3 alert read:warning:close notify ldap_read: want=8, got=0 ber_get_next on fd 20 failed errno=0 (Success) connection_read(20): input error=-2 id=2605, closing. connection_closing: readying conn=2605 sd=20 for close connection_close: conn=2605 sd=20 daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: removing 20 tls_write: want=23, written=23 0000: 15 03 01 00 12 d7 55 9d 59 8c 18 96 64 bf e7 f9 ......U.Y...d... 0010: 9e 2c 0a 91 c4 9d ba .,..... TLS trace: SSL3 alert write:warning:close notify conn=2605 fd=20 closed (connection lost) daemon: activity on 1 descriptor daemon: activity on: 38r daemon: read active on 38 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(38) connection_get(38): got connid=2603 connection_read(38): checking for input on id=2603 ber_get_next tls_read: want=5, got=5 0000: 15 03 01 00 12 ..... tls_read: want=18, got=18 0000: 81 9f e4 91 64 6e bc c8 ba 53 be e0 5e 5e 75 f9 ....dn...S..^^u. 0010: ac e4 .. TLS trace: SSL3 alert read:warning:close notify ldap_read: want=8, got=0 ber_get_next on fd 38 failed errno=0 (Success) connection_read(38): input error=-2 id=2603, closing. connection_closing: readying conn=2603 sd=38 for close connection_close: conn=2603 sd=38 daemon: removing 38 tls_write: want=23, written=23 0000: 15 03 01 00 12 50 be 29 9e e3 e6 b8 88 55 46 64 .....P.).....UFd 0010: 08 d4 83 45 e4 df b1 ...E... TLS trace: SSL3 alert write:warning:close notify conn=2603 fd=38 closed (connection lost) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: activity on 1 descriptor daemon: activity on: 37r daemon: read active on 37 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(37) connection_get(37): got connid=2602 connection_read(37): checking for input on id=2602 ber_get_next tls_read: want=5, got=5 0000: 15 03 01 00 12 ..... tls_read: want=18, got=18 0000: b8 e7 6e 24 27 de cc 33 fd 77 b9 29 8a a4 5e 79 ..n$'..3.w.)..^y 0010: 53 7c S| TLS trace: SSL3 alert read:warning:close notify ldap_read: want=8, got=0 ber_get_next on fd 37 failed errno=0 (Success) connection_read(37): input error=-2 id=2602, closing. connection_closing: readying conn=2602 sd=37 for close connection_close: conn=2602 sd=37 daemon: removing 37 tls_write: want=23, written=23 0000: 15 03 01 00 12 7c e4 28 fb 15 b4 f9 dc 69 44 4d .....|.(.....iDM 0010: 40 21 1b 78 7f 41 35 @!.x.A5 TLS trace: SSL3 alert write:warning:close notify conn=2602 fd=37 closed (connection lost) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero => hdb_search bdb_dn2entry("cn=accesslog") => access_allowed: search access to "cn=accesslog" "entry" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) search_candidates: base="cn=accesslog" (0x00000001) scope=1 => hdb_dn2idl("cn=accesslog") => bdb_filter_candidates AND => bdb_list_candidates 0xa0 => bdb_filter_candidates OR => bdb_list_candidates 0xa1 => bdb_filter_candidates EQUALITY => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30988) <= bdb_equality_candidates: id=0, first=0, last=0 <= bdb_filter_candidates: id=0 first=0 last=0 => bdb_filter_candidates LE => bdb_inequality_candidates (reqStart) => key_read bdb_idl_fetch_key: <= bdb_index_read 2 candidates => key_read bdb_idl_fetch_key: <= bdb_index_read: failed (-30988) <= bdb_inequality_candidates: id=2, first=9, last=10 <= bdb_filter_candidates: id=2 first=9 last=10 <= bdb_list_candidates: id=2 first=9 last=10 <= bdb_filter_candidates: id=2 first=9 last=10 <= bdb_list_candidates: id=2 first=9 last=10 <= bdb_filter_candidates: id=2 first=9 last=10 bdb_search_candidates: id=2 first=9 last=10 entry_decode: "" <= entry_decode() => test_filter LE => access_allowed: search access to "reqStart=20100413191807.000004Z,cn=accesslog" "reqStart" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 entry_decode: "" <= entry_decode() => test_filter LE => access_allowed: search access to "reqStart=20100413191807.000009Z,cn=accesslog" "reqStart" requested <= root access granted => access_allowed: search access granted by manage(=mwrscxd) <= test_filter 6 send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" => bdb_entry_get: ndn: "reqStart=20100413191807.000004Z,cn=accesslog" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("reqStart=20100413191807.000004Z,cn=accesslog") => bdb_entry_get: found entry: "reqStart=20100413191807.000004Z,cn=accesslog" bdb_entry_get: rc=0 => test_filter AND => test_filter_and => test_filter EQUALITY => access_allowed: search access to "reqStart=20100413191807.000004Z,cn=accesslog" "objectClass" requested => dn: [1] cn=accesslog => acl_get: [1] matched => acl_get: [1] attr objectClass => acl_mask: access to entry "reqStart=20100413191807.000004Z,cn=accesslog", attr "objectClass" requested => acl_mask: to value by "uid=zmreplica,cn=admins,cn=zimbra", (=0) <= check a_dn_pat: uid=zimbra,cn=admins,cn=zimbra <= check a_dn_pat: cn=config <= check a_dn_pat: uid=zmreplica,cn=admins,cn=zimbra <= acl_mask: [3] applying read(=rscxd) (stop) <= acl_mask: [3] mask: read(=rscxd) => slap_access_allowed: search access granted by read(=rscxd) => access_allowed: search access granted by read(=rscxd) <= test_filter 6 => test_filter EQUALITY => access_allowed: search access to "reqStart=20100413191807.000004Z,cn=accesslog" "reqResult" requested => dn: [1] cn=accesslog => acl_get: [1] matched => acl_get: [1] attr reqResult => acl_mask: access to entry "reqStart=20100413191807.000004Z,cn=accesslog", attr "reqResult" requested => acl_mask: to value by "uid=zmreplica,cn=admins,cn=zimbra", (=0) <= check a_dn_pat: uid=zimbra,cn=admins,cn=zimbra <= check a_dn_pat: cn=config <= check a_dn_pat: uid=zmreplica,cn=admins,cn=zimbra <= acl_mask: [3] applying read(=rscxd) (stop) <= acl_mask: [3] mask: read(=rscxd) => slap_access_allowed: search access granted by read(=rscxd) => access_allowed: search access granted by read(=rscxd) <= test_filter 6 <= test_filter_and 6 <= test_filter 6 syncprov_matchops: sid ffffffff fscope 1 rc 6 ==> hdb_delete: reqStart=20100413191807.000004Z,cn=accesslog bdb_dn2entry("reqStart=20100413191807.000004Z,cn=accesslog") => access_allowed: delete access to "cn=accesslog" "children" requested <= root access granted => access_allowed: delete access granted by manage(=mwrscxd) => access_allowed: delete access to "reqStart=20100413191807.000004Z,cn=accesslog" "entry" requested <= root access granted => access_allowed: delete access granted by manage(=mwrscxd) => hdb_dn2id_delete 0x9: "reqStart=20100413191807.000004Z,cn=accesslog" <= hdb_dn2id_delete 0x9: 0 => index_entry_del( 9, "reqStart=20100413191807.000004Z,cn=accesslog" ) => key_change(DELETE,9) bdb_idl_delete_key: 9 [66ec5701] <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 [98599c51] <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 [61e2b421] <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 [0096defd] <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 [80000000] <= key_change 0 => key_change(DELETE,9) bdb_idl_delete_key: 9 <= key_change 0 <= index_entry_del( 9, "reqStart=20100413191807.000004Z,cn=accesslog" ) success ====> bdb_cache_delete( 9 ) hdb_delete: deleted id=00000009 dn="reqStart=20100413191807.000004Z,cn=accesslog" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" syncprov_sendresp: cookie= => send_search_entry: conn 1013 dn="reqStart=20100413191807.000004Z,cn=accesslog" => access_allowed: read access to "reqStart=20100413191807.000004Z,cn=accesslog" "entry" requested => dn: [1] cn=accesslog => acl_get: [1] matched => acl_get: [1] attr entry => acl_mask: access to entry "reqStart=20100413191807.000004Z,cn=accesslog", attr "entry" requested => acl_mask: to all values by "uid=zmreplica,cn=admins,cn=zimbra", (=0) <= check a_dn_pat: uid=zimbra,cn=admins,cn=zimbra <= check a_dn_pat: cn=config <= check a_dn_pat: uid=zmreplica,cn=admins,cn=zimbra <= acl_mask: [3] applying read(=rscxd) (stop) <= acl_mask: [3] mask: read(=rscxd) => slap_access_allowed: read access granted by read(=rscxd) => access_allowed: read access granted by read(=rscxd) conn=1013 op=2 ENTRY dn="reqStart=20100413191807.000004Z,cn=accesslog" ber_flush2: 112 bytes to sd 18 0000: 30 6e 02 01 03 64 30 04 2c 72 65 71 53 74 61 72 0n...d0.,reqStar 0010: 74 3d 32 30 31 30 30 34 31 33 31 39 31 38 30 37 t=20100413191807 0020: 2e 30 30 30 30 30 34 5a 2c 63 6e 3d 61 63 63 65 .000004Z,cn=acce 0030: 73 73 6c 6f 67 30 00 a0 37 30 35 04 18 31 2e 33 sslog0..705..1.3 0040: 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e .6.1.4.1.4203.1. 0050: 39 2e 31 2e 32 04 19 30 17 0a 01 03 04 10 43 30 9.1.2..0......C0 0060: b3 35 9f 63 47 af b6 f3 66 1b e4 76 6c 54 04 00 .5.cG...f..vlT.. tls_write: want=186, written=186 0000: 17 03 01 00 20 77 40 e5 e4 99 b3 f0 07 5a 3d c9 .... w@......Z=. 0010: 11 4b 1d c2 97 45 d2 d1 d6 52 c9 89 74 37 b7 c9 .K...E...R..t7.. 0020: fd 72 3d cf 8d 17 03 01 00 90 f3 dc 6b 91 cd f5 .r=.........k... 0030: 6a 87 21 7c 61 fa 8e 69 ea f8 21 9e ec ea 85 a2 j.!|a..i..!..... 0040: 9d f0 8a 32 82 66 62 9c bf 15 00 02 ef c0 d0 34 ...2.fb........4 0050: 16 4e 2d a6 25 e3 5f 0d 95 68 2d 7b 74 8f 41 a8 .N-.%._..h-{t.A. 0060: 4b 51 93 78 46 d6 8e 44 33 12 44 05 6c 37 09 03 KQ.xF..D3.D.l7.. 0070: b5 d3 13 58 c2 7a 82 9e 3e 0e 4d 6f f0 90 a7 3d ...X.z..>.Mo...= 0080: 4b 5f 44 5f 7d 3a cc 28 93 b6 3f 37 05 c8 c6 77 K_D_}:.(..?7...w 0090: f4 40 72 97 ea a9 0e a0 ab 98 09 5c b8 08 54 a7 .@r........\..T. 00a0: 7d 2e 72 6f 5f 14 db e4 0b bc 0b ca 1f 3e ae 83 }.ro_........>.. 00b0: 37 51 c5 82 44 b7 b4 00 9a 35 7Q..D....5 ldap_write: want=112, written=112 0000: 30 6e 02 01 03 64 30 04 2c 72 65 71 53 74 61 72 0n...d0.,reqStar 0010: 74 3d 32 30 31 30 30 34 31 33 31 39 31 38 30 37 t=20100413191807 0020: 2e 30 30 30 30 30 34 5a 2c 63 6e 3d 61 63 63 65 .000004Z,cn=acce 0030: 73 73 6c 6f 67 30 00 a0 37 30 35 04 18 31 2e 33 sslog0..705..1.3 0040: 2e 36 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e .6.1.4.1.4203.1. 0050: 39 2e 31 2e 32 04 19 30 17 0a 01 03 04 10 43 30 9.1.2..0......C0 0060: b3 35 9f 63 47 af b6 f3 66 1b e4 76 6c 54 04 00 .5.cG...f..vlT.. <= send_search_entry: conn 1013 exit. => bdb_entry_get: ndn: "reqStart=20100413191807.000009Z,cn=accesslog" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("reqStart=20100413191807.000009Z,cn=accesslog") => bdb_entry_get: found entry: "reqStart=20100413191807.000009Z,cn=accesslog" bdb_entry_get: rc=0 => test_filter AND => test_filter_and => test_filter EQUALITY => access_allowed: search access to "reqStart=20100413191807.000009Z,cn=accesslog" "objectClass" requested => dn: [1] cn=accesslog => acl_get: [1] matched => acl_get: [1] attr objectClass => acl_mask: access to entry "reqStart=20100413191807.000009Z,cn=accesslog", attr "objectClass" requested => acl_mask: to value by "uid=zmreplica,cn=admins,cn=zimbra", (=0) <= check a_dn_pat: uid=zimbra,cn=admins,cn=zimbra <= check a_dn_pat: cn=config <= check a_dn_pat: uid=zmreplica,cn=admins,cn=zimbra <= acl_mask: [3] applying read(=rscxd) (stop) <= acl_mask: [3] mask: read(=rscxd) => slap_access_allowed: search access granted by read(=rscxd) => access_allowed: search access granted by read(=rscxd) <= test_filter 6 => test_filter EQUALITY => access_allowed: search access to "reqStart=20100413191807.000009Z,cn=accesslog" "reqResult" requested => dn: [1] cn=accesslog => acl_get: [1] matched => acl_get: [1] attr reqResult => acl_mask: access to entry "reqStart=20100413191807.000009Z,cn=accesslog", attr "reqResult" requested => acl_mask: to value by "uid=zmreplica,cn=admins,cn=zimbra", (=0) <= check a_dn_pat: uid=zimbra,cn=admins,cn=zimbra <= check a_dn_pat: cn=config <= check a_dn_pat: uid=zmreplica,cn=admins,cn=zimbra <= acl_mask: [3] applying read(=rscxd) (stop) <= acl_mask: [3] mask: read(=rscxd) => slap_access_allowed: search access granted by read(=rscxd) => access_allowed: search access granted by read(=rscxd) <= test_filter 6 <= test_filter_and 6 <= test_filter 6 syncprov_matchops: sid ffffffff fscope 1 rc 6 ==> hdb_delete: reqStart=20100413191807.000009Z,cn=accesslog bdb_dn2entry("reqStart=20100413191807.000009Z,cn=accesslog") => access_allowed: delete access to "cn=accesslog" "children" requested <= root access granted => access_allowed: delete access granted by manage(=mwrscxd) => access_allowed: delete access to "reqStart=20100413191807.000009Z,cn=accesslog" "entry" requested <= root access granted => access_allowed: delete access granted by manage(=mwrscxd) => hdb_dn2id_delete 0xa: "reqStart=20100413191807.000009Z,cn=accesslog" <= hdb_dn2id_delete 0xa: 0 => index_entry_del( 10, "reqStart=20100413191807.000009Z,cn=accesslog" ) => key_change(DELETE,a) bdb_idl_delete_key: a [66ec5701] <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a [98599c51] <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a [61e2b421] <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a [0096defd] <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a [80000000] <= key_change 0 => key_change(DELETE,a) bdb_idl_delete_key: a <= key_change 0 <= index_entry_del( 10, "reqStart=20100413191807.000009Z,cn=accesslog" ) success ====> bdb_cache_delete( 10 ) daemon: activity on 1 descriptor daemon: activity on: 18r daemon: read active on 18 daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero connection_get(18) connection_get(18): got connid=1013 connection_read(18): checking for input on id=1013 ber_get_next tls_read: want=5, got=5 0000: 17 03 01 00 20 .... tls_read: want=32, got=32 0000: d7 e0 2b 7c 92 57 a1 11 a4 0b d8 76 81 f5 15 e7 ..+|.W.....v.... 0010: b3 58 97 b6 10 65 aa 30 9d 38 e3 2c 90 63 a5 9d .X...e.0.8.,.c.. tls_read: want=5, got=5 0000: 17 03 01 00 20 .... tls_read: want=32, got=32 0000: 2a bd 8d 49 d2 58 87 51 8f b4 32 e7 70 07 8c 13 *..I.X.Q..2.p... 0010: 1d d2 19 c8 43 a1 fb 28 89 4f cf df a8 58 6c 2a ....C..(.O...Xl* ldap_read: want=8, got=7 0000: 30 05 02 01 04 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0x3f69170 ptr=0x3f69170 end=0x3f69175 len=5 0000: 02 01 04 42 00 ...B. op tag 0x42, time 1271191556 ber_get_next tls_read: want=5, got=5 0000: 15 03 01 00 20 .... tls_read: want=32, got=32 0000: 04 7f 9e 27 41 7e af b2 de ec b2 b5 e9 b5 15 d7 ...'A~.......... 0010: 5f 1a 9a 5f 64 8e cf d5 8e a6 d4 e2 8b 4e 27 6e _.._d........N'n TLS trace: SSL3 alert read:warning:close notify ldap_read: want=8, got=0 ber_get_next on fd 18 failed errno=0 (Success) connection_read(18): input error=-2 id=1013, closing. connection_closing: readying conn=1013 sd=18 for close hdb_delete: deleted id=0000000a dn="reqStart=20100413191807.000009Z,cn=accesslog" daemon: activity on 1 descriptor daemon: activity on: send_ldap_result: conn=-1 op=0 p=0 connection_close: deferring conn=1013 sd=18 send_ldap_result: err=0 matched="" text="" daemon: epoll: listen=7 active_threads=0 tvp=zero daemon: epoll: listen=8 active_threads=0 tvp=zero conn=1013 op=3 do_unbind conn=1013 op=3 UNBIND hdb_modify: cn=accesslog bdb_dn2entry("cn=accesslog") bdb_modify_internal: 0x00000001: cn=accesslog <= acl_access_allowed: granted to database root bdb_modify_internal: replace entryCSN connection_resched: attempting closing conn=1013 sd=18 connection_close: conn=1013 sd=18 => key_change(DELETE,1) bdb_idl_delete_key: 1 daemon: removing 18 <= key_change 0 tls_write: want=37, written=37 0000: 15 03 01 00 20 32 b4 ef e6 42 1b 72 80 46 e6 b5 .... 2...B.r.F.. 0010: d5 f4 ad 44 4f 37 eb c5 03 75 69 29 17 f3 be ac ...DO7...ui).... 0020: 4e 60 80 e2 4e N`..N => key_change(ADD,1) bdb_idl_insert_key: 1 TLS trace: SSL3 alert write:warning:close notify <= key_change 0 => entry_encode(0x00000001): <= entry_encode(0x00000001): conn=1013 fd=18 closed --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6519) syncprov sends bogus cookie on accesslog purge
by quanah＠zimbra.com 13 Apr '10

13 Apr '10

Full_Name: Quanah Gibson-Mount Version: 2.4.21 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When the accesslog database is purged, the syncprov overlay sends a bogus cookie response to open syncrepl clients, causing them to drop connection. This bogus cookie should never have been sent. >From the slapd log on the provider, we have the initial connection: Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 fd=18 ACCEPT from IP=10.18.97.26:60034 (IP=10.18.97.79:389) Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=0 STARTTLS Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=0 RESULT oid= err=0 text= Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 fd=18 TLS established tls_ssf=256 ssf=256 Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=1 RESULT tag=97 err=0 text= Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Apr 13 13:16:43 freelancer slapd[4276]: conn=1013 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Approximately 30 minutes later (which is my setting), the purge takes place: Apr 13 13:45:54 freelancer slapd[4276]: slap_queue_csn: queing 0x446a7200 20100413204554.501961Z#000000#000#000000 Apr 13 13:45:54 freelancer slapd[4276]: slap_queue_csn: queing 0x395e788 20100413204554.501961Z#000000#000#000000 Apr 13 13:45:54 freelancer slapd[4276]: slap_graduate_commit_csn: removing 0x3f94690 20100413204554.501961Z#000000#000#000000 Apr 13 13:45:54 freelancer slapd[4276]: syncprov_sendresp: cookie=rid=100,csn=20100413204554.501961Z#000000#000#000000 Apr 13 13:45:54 freelancer slapd[4276]: conn=2605 op=2 RESULT tag=105 err=0 text= Apr 13 13:45:54 freelancer slapd[4276]: slap_graduate_commit_csn: removing 0x3f80030 20100413204554.501961Z#000000#000#000000 Apr 13 13:45:54 freelancer slapd[4276]: conn=2605 op=3 SRCH base="" scope=2 deref=3 filter="(&(zimbraId=58a68771-fded-4aa2-baab-e1ac349e0028)(objectClass=zimbraAccount))" Apr 13 13:45:54 freelancer slapd[4276]: conn=2605 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 13 13:45:54 freelancer slapd[4276]: conn=2605 fd=20 closed (connection lost) Apr 13 13:45:54 freelancer slapd[4276]: conn=2603 fd=38 closed (connection lost) Apr 13 13:45:54 freelancer slapd[4276]: conn=2602 fd=37 closed (connection lost) Apr 13 13:45:56 freelancer slapd[4276]: syncprov_sendresp: cookie= Apr 13 13:45:56 freelancer slapd[4276]: conn=1013 op=3 UNBIND Apr 13 13:45:56 freelancer slapd[4276]: conn=1013 fd=18 closed As you can see, an empty cookie is sent, and the consumer immediately closes connection, re-establishing it shortly thereafter: Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 fd=18 ACCEPT from IP=10.18.97.26:36796 (IP=10.18.97.79:389) Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=0 STARTTLS Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=0 RESULT oid= err=0 text= Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 fd=18 TLS established tls_ssf=256 ssf=256 Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" method=128 Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=1 RESULT tag=97 err=0 text= Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Apr 13 13:46:56 freelancer slapd[4276]: conn=2671 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Apr 13 13:46:56 freelancer slapd[4276]: Entry reqStart=20100413204554.000009Z,cn=accesslog CSN 20100413204554.501961Z#000000#000#000000 older or equal to ctx 20100413204554.501961Z#000000#000#000000 Apr 13 13:46:56 freelancer slapd[4276]: syncprov_search_response: cookie=rid=100,csn=20100413204656.794873Z#000000#000#000000

1 0

Re: (ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by hyc＠symas.com 13 Apr '10

13 Apr '10

h.b.furuseth(a)usit.uio.no wrote: >> There is no real buffer overflow here AFAICS but the real problem is, >> that the destination of the strcpy() is defined as char[1] in this >> case (it's the nrdn member of a struct diskNode). The additional >> runtime check when compiling with -D_FORTIFY_SOURCE=2 sees that the >> destination data will not fit in there and aborts. > > This is similar to the struct hack, except nrdn is not the last struct > member. IIRC it actually is invalid to use nrdn as an accessor for the > following struct members (from the compiler's point of view). > > Another case of "not quite the Struct Hack" broke last year: ITS#6303. > If _FORTIFY_SOURCE is warning us that gcc might break this code, the > memcpy patch might merely shut up the warning without fixing the > problem. In that case, the simplest change would be to do away with > struct diskNode - or keep it for reference but not actually use it. > > I'm reopening the ITS for someone else to decide if they care, I have > other things on my mind currently. > Nope, we don't care. The purpose and usage of diskNode is thoroughly documented in the comments and all of the uses are correct. Marking this Test again. -- -- 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#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by h.b.furuseth＠usit.uio.no 13 Apr '10

13 Apr '10

> There is no real buffer overflow here AFAICS but the real problem is, > that the destination of the strcpy() is defined as char[1] in this > case (it's the nrdn member of a struct diskNode). The additional > runtime check when compiling with -D_FORTIFY_SOURCE=2 sees that the > destination data will not fit in there and aborts. This is similar to the struct hack, except nrdn is not the last struct member. IIRC it actually is invalid to use nrdn as an accessor for the following struct members (from the compiler's point of view). Another case of "not quite the Struct Hack" broke last year: ITS#6303. If _FORTIFY_SOURCE is warning us that gcc might break this code, the memcpy patch might merely shut up the warning without fixing the problem. In that case, the simplest change would be to do away with struct diskNode - or keep it for reference but not actually use it. I'm reopening the ITS for someone else to decide if they care, I have other things on my mind currently. -- Hallvard

1 0

Re: (ITS#6517) undefined references to ldif_*
by michael＠stroeder.com 13 Apr '10

13 Apr '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: > >>> Actually it's not that; Michael routinely builds with --enable-dynamic, >>> and libldap now (dynamically) depends on liblutil for the LDIF part. >>> >> I did not want to introduce any new dependencies nor break any existing >> code with the new LDIF library. Ideally, you would only have to link >> with -lldif for external code that wants to use the LDIF API (such as >> ldif_get_entry or ldif_parse_line). Any existing code, or code that >> just wants to use the new higher level api ldap_parse_ldif_record_x >> would only have to link with -lldap. >> >> Is --enable-dynamic the only additional build flag I need to use? > > In fact, you did not introduce any further dependence, as ldif_* functions > (those provided in liblutil/ldif.c) are present in liblutil. I fixed the > issue by reversing the link order of libraries. > > It used to be liblutil, liblber, libldap (I think that was because earlier > there used to be dependencies of liblutil on the others, please correct > me). Now it's libldap, liblber, liblutil, and it builds fine with > --enable-dynamic=yes/no. Please check whether my fix is appropriate. It seems to work for me now. Ciao, Michael.

1 0

Re: (ITS#6517) undefined references to ldif_*
by richm＠stanfordalumni.org 13 Apr '10

13 Apr '10

masarati(a)aero.polimi.it wrote: >> masarati(a)aero.polimi.it wrote: >> > > >>> Actually it's not that; Michael routinely builds with --enable-dynamic, >>> and libldap now (dynamically) depends on liblutil for the LDIF part. >>> >>> >> I did not want to introduce any new dependencies nor break any existing >> code with the new LDIF library. Ideally, you would only have to link >> with -lldif for external code that wants to use the LDIF API (such as >> ldif_get_entry or ldif_parse_line). Any existing code, or code that >> just wants to use the new higher level api ldap_parse_ldif_record_x >> would only have to link with -lldap. >> >> Is --enable-dynamic the only additional build flag I need to use? >> > > In fact, you did not introduce any further dependence, as ldif_* functions > (those provided in liblutil/ldif.c) are present in liblutil. I fixed the > issue by reversing the link order of libraries. > > It used to be liblutil, liblber, libldap (I think that was because earlier > there used to be dependencies of liblutil on the others, please correct > me). Now it's libldap, liblber, liblutil, and it builds fine with > --enable-dynamic=yes/no. Please check whether my fix is appropriate. > I just pulled the latest code from anonymous(a)cvs.openldap.org - started from a clean directory - ran configure with --enable-dynamic --disable-static - make depend and make install - build completed successfully - server works fine, ldapmodify works fine > p. > > > > >

1 0

Re: (ITS#6517) undefined references to ldif_*
by masarati＠aero.polimi.it 13 Apr '10

13 Apr '10

> masarati(a)aero.polimi.it wrote: >> Actually it's not that; Michael routinely builds with --enable-dynamic, >> and libldap now (dynamically) depends on liblutil for the LDIF part. >> > I did not want to introduce any new dependencies nor break any existing > code with the new LDIF library. Ideally, you would only have to link > with -lldif for external code that wants to use the LDIF API (such as > ldif_get_entry or ldif_parse_line). Any existing code, or code that > just wants to use the new higher level api ldap_parse_ldif_record_x > would only have to link with -lldap. > > Is --enable-dynamic the only additional build flag I need to use? In fact, you did not introduce any further dependence, as ldif_* functions (those provided in liblutil/ldif.c) are present in liblutil. I fixed the issue by reversing the link order of libraries. It used to be liblutil, liblber, libldap (I think that was because earlier there used to be dependencies of liblutil on the others, please correct me). Now it's libldap, liblber, liblutil, and it builds fine with --enable-dynamic=yes/no. Please check whether my fix is appropriate. p.

1 0

Re: (ITS#6517) undefined references to ldif_*
by richm＠stanfordalumni.org 13 Apr '10

13 Apr '10

masarati(a)aero.polimi.it wrote: >> Michael Ströder wrote: >> >>> hyc(a)symas.com wrote: >>> >>>> richm(a)stanfordalumni.org wrote: >>>> >>>>> This is most likely related to my recent LDIF changes. But I didn't >>>>> see >>>>> this problem. What platform is this? What build flags are you using? >>>>> >>>> Built fine here too, looks like an inconsistent build tree over there. >>>> >>> The build with the same build flags on the very same system worked right >>> before the recent libldif check-ins. I'm using anon CVS pserver for cvs >>> up. >>> >> The anon CVS server has some lag in receiving updates from the master >> server. >> Don't you have an account on the master? >> > > Actually it's not that; Michael routinely builds with --enable-dynamic, > and libldap now (dynamically) depends on liblutil for the LDIF part. > I did not want to introduce any new dependencies nor break any existing code with the new LDIF library. Ideally, you would only have to link with -lldif for external code that wants to use the LDIF API (such as ldif_get_entry or ldif_parse_line). Any existing code, or code that just wants to use the new higher level api ldap_parse_ldif_record_x would only have to link with -lldap. Is --enable-dynamic the only additional build flag I need to use? > p. > > > > > >

1 0

Re: (ITS#6513) dynacl/aci fails on searches with attributes
by peter＠adpm.de 13 Apr '10

13 Apr '10

--Boundary-00=_glFxL04kLcJl7l6 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Thanks for your quick answer Pierangelo, On Monday, 12. April 2010, masarati(a)aero.polimi.it wrote: > > [...] > > My guess is that you're trying to use ACIs with a non-local storage. In > > that case your analysis is correct. Can you provide your (sanitized) > > configuration? I am using a local hdb backend. In order to generate a minimal test case I found out, that it seems to be=20 related to the rwm overlay. Although I have set rwm-rewriteEngine to off, rwm seems to be partially=20 active. Commenting out the rwm directives completely makes the searches work as=20 expected. Please find attached a testcase with slapd.conf and ldif data. To experience the issue simply perform a search with e.g. attribute 1.1 as = one=20 of the users in the data. Then comment the rwm-... lines in slapd.conf, restart slapd and try again. Voil=E0 the difference. > > [...] >=20 > Automatically detecting what attributes need to be added to requests for > proxying sounds like an overkill. Probably, a reasonable workaround could > be to add a configuration directive that lists what attributes need to be > added to requests. This directive should be honored by proxy backends and > in general by all those backends that do not pass back complete entries to > the frontend. In the case of proxy backends its use would be > straightforward, since requested attrs need to be mapped anyway in the > request. Adding some more would not be a big deal. =20 That would be absolutely sufficient for me. > Things might be a bit > more complicated in case of, say, special configurations like proxycache, > where ACIs would need to be added to all attribute templates, and so. Yet > another reason to avoid ACIs :) As much as I'd like to, but I fear I can't. I am trying to migrate from a non-OpenLDAP directory solution with a comple= x=20 permission structure in in-tree ACLs to OpenLDAP. Unfortunately the permissions are set up in a way that do not let them writ= e=20 as a short list of ACLs. Changing the permission structure is not possible as lots of applications=20 depend on it. =2D-=20 Peter Marschall peter(a)adpm.de --Boundary-00=_glFxL04kLcJl7l6 Content-Type: application/x-compressed-tar; name="testcase.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="testcase.tgz" H4sIAOZWxEsAA+1YbW/jNgzuV/tXCMkBa3duXtz0CqQItq7JDTcc0sOKfjp0gyzJiTZH8iS5Sfbr R8mOm+SSJn1bN8AEAtsUxYekSJqOTnBKG0SK+ODVqAX0odOy1/bZqbsCI8yvrVYHFg/a7ZMP7dZp q3MG/HZ42jo9QK3XM+meMm2wQuhggpUmY5xukwOx+BVj9FZUR01mSDOhOG3qMhfQ8TG6Spn43L/4 giaYC6SZumMK2UU+yhQ2XAoU84T5fh1xQZKMsg2riM0MExoedYAgvmyC4abRaPjFHm8J3i03iVSs kd8/JKS52C0GMkaqUcqUlmIhDQZPx0wxRCUyY4ZUJgyfMGevRiPpp5zae89r3mHVhOU8MkV8YNXH aqSdyEYJu2pREjkacTFChzVIHqNriGsUS4XsE9eGE33kg0zC7ljiORF0cfnZ7lQMU4QJYTrfgcU8 knSOjERKStO/HgCLouvcoVzQM9KjosFmmJhereZ70dz73mnaKEBEL4/HiqTD1kZxYvgdhIaPxmAV wMroD0bMZYLBImxAIMoMQzJGOEmKRb2EY0V0b2mTA1lBv6ATLgLZM4BXgyQTeMScVAa5pnNz7CMW UswnMgPczIy3W2i3fQGkqVR0l2HLsg5EsyRGvensEWau2ZUHEXiuItYDp6FG0OBq2OgPVk9DZ5FR jPVqBcIjDKBzgUnSxISjqeKGrZkQYfInE7QpoW4TPEcTSTOb4Hmo/PwxxWbsNTOtmgmP8tIpVhKJ qWd1/D6m0TJPTSc+6H8ZAjspNjjCGsqRxVxw2zr0i6n3F9o964WrfGyg8G0coPT7P9meZWyDOzQy RZHCAopC2/yx6/ZojnydxTGfeV55RusdpHRh0UJAm2VzBUcvFcQe3jLQCqHoj/ySmzePMu5WtdWM 7XmDJHRRqb7ToAVahRhlXI8ZRQJDp7K1ny7S1zYEKsC69VxxK+nU80pR0P5JUE7yLLB93boO7ZOy mZcnKrHFGjBh1Pzyepjf3Nx86nse+6sQJCLQIhhB9YkhWBOAniSQgcycjKtPl4+oyLwuIKUIyaz3 9bfg9n1hHrImoPzeLyQ9l1zwOy5UDAQ0UObJOF7mXsKRwXvFg4TBWWKWl37NbN+uHTbeB0c/AOKh gzwK1sDf1VDtXRuY78Kysmrd2iYQzbAi4488MUxtXx/YOPWHD5myAX8f5AtoWP0hdDOONdoKttgz wQbyl+6/QbGYKYWTHOYhCViFsx1cffTfemap6OXItq5GQvlrjrb5/N/ZOv93OmeL+T/sdNp2/j9p n1Tz/79Bdei8djzvoja8LOGy6Mj3b4MudOp0lQEzNRb8bzfn+xIE7JbFBwMMJF3UqrtXR30Eb1Rz rgIS6IAGs/Ovjn1bT7Mo4aReYGY9mPrTdvBocJxkMDL4Musip+H5RoTPNiJ8nhE3dvwNXiQkTtW6 NcXEuc2e/HVuB2TClOExJ9iw0sg9dS3mA1HOBwnIyCytw5Byaf0qvfzZsr/1d1+jYcq/PZ8G95wc LUglFGxCJGWBtjtNANPQZJhNIqbqdtrfEvDnHf9/N+DhloCHbxDwLUf+pIjnup5XcVsi8jb2wHmR RYEET2wH+f8dq7yVv0J8IoqGadX7y5/D3fsvC3uyS2I/uug0HL6G/WUd+2XqddEvkq34EW70Y88Y 7+9HuJ8f4TY/wl1+7GxYD3viavEqtt9LejX42p8wWyP7nvxjMmu1Th1MPf/34ZjT+n543xzmQ03k CUEINwZhR9q8eBB24FWfPBVVVFFFFVVUUUUVVVRRRRVVVNH/l/4B1nCcvQAoAAA= --Boundary-00=_glFxL04kLcJl7l6--

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
24
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2010