openldap-bugs

openldap-bugs@openldap.org

1 participants
20953 discussions

Re: authz-regexp matches twice on same dse (ITS#4698)
by ap＠d-dt.de 05 Oct '06

05 Oct '06

Pierangelo Masarati wrote: > I don't see an error in OpenLDAP software here. authz regexp matching is > designed to succeed only if the identity is univoquely resolved to exactly one > DN. I'm afraid but I cannot even imagine how slapd could decide to pick one out > of many DNs when authenticating a user; I guess noone else can. > > p. > Matched dn's are unique, as they describing the same Entry: dn: uid=works,dc=example,dc=org objectClass: extensibleObject uid: works dn: cn=worksalso,dc=example,dc=org objectClass: extensibleObject cn: worksalso dn: uid=fails,dc=example,dc=org objectClass: extensibleObject uid: fails cn: fails "(|(cn=works)(uid=works))" and "(|(cn=worksalso)(uid=worksalso))" matching either attribute, whereas "(|(cn=works)(uid=works))" matches twice, but describes the same object. ldapsearching for "(|(cn=fails)(uid=fails))" will also return only the one and unique entry "uid=fails,dc=example,dc=org" A --

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk 05 Oct '06

05 Oct '06

Howard Chu wrote: > tim(a)dcs.qmul.ac.uk wrote: >> Full_Name: Tim Kay >> Version: OS: Linux (Fedora core 5 RPM) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (138.37.95.144) >> >> >> Modifying a DN on the syncrepl provider fails to propogate to the >> consumer. The >> provider "sends" a valid modify but the consumer, having received the >> modify >> request walks the tree, returns the parent DN to the entry, >> determines that >> write access is permitted and the iterates, at this point >> newSuperior->bv_val is >> set to "*" !? bdb_dn2entry is now searching for "�UUU" which >> looks like >> some unicode screw up. > > Try the patch in CVS slapd/syncrepl.c 1.272 -> 1.273 > That appears to have nailed it. Thank you very much and bug closed I think. Seven hours between bug report and patch release is something to shout from the rooftops too. Best, Tim -- Tim Kay Systems Programmer Department of Computer Science Queen Mary, University of London. Tel: +44 (0) 207 882 7521 Fax: +44 (0) 208 980 6533

1 0

(ITS#4698) authz-regexp matches twice on same dse
by adampordzik＠gmx.de 05 Oct '06

05 Oct '06

Full_Name: Adam pordzik Version: 2.3.27 OS: FreeBSD 5-STABLE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.171.35.164) authz-regexp uid=([^,]+),cn=[^,]+,cn=auth ldap:///dc=example,dc=org??sub?(|(cn=$1)(uid=$1)) Below dc=example,dc=org there is a DSE with same value for uid and cn, which I can't bind to with SASL. Since Authentication against this entry works after its cn-attributes rename (or deletition of same-valued cn) works, as also agianst other found entries, I assueme this is due to twice matching the same entry.

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by hyc＠symas.com 04 Oct '06

04 Oct '06

tim(a)dcs.qmul.ac.uk wrote: > Full_Name: Tim Kay > Version: > OS: Linux (Fedora core 5 RPM) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.95.144) > > > Modifying a DN on the syncrepl provider fails to propogate to the consumer. The > provider "sends" a valid modify but the consumer, having received the modify > request walks the tree, returns the parent DN to the entry, determines that > write access is permitted and the iterates, at this point newSuperior->bv_val is > set to "*" !? bdb_dn2entry is now searching for "�UUU" which looks like > some unicode screw up. Try the patch in CVS slapd/syncrepl.c 1.272 -> 1.273 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4697) core dump from acl.c regex
by quanah＠stanford.edu 04 Oct '06

04 Oct '06

--On Wednesday, October 04, 2006 8:21 PM +0000 quanah(a)stanford.edu wrote: The acl bits of "a" show: (gdb) thread 1 [Switching to thread 1 (process 28461)]#0 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 (gdb) frame 7 #7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) (gdb) print *a $1 = {acl_filter = 0x0, acl_dn_style = ACL_STYLE_CHILDREN, acl_dn_re = {buffer = 0x0, allocated = 0, used = 0, syntax = 0, fastmap = 0x0, translate = 0x0, re_nsub = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0, no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 0}, acl_dn_pat = {bv_len = 18, bv_val = 0x2b9d6e54e900 "dc=stanford,dc=edu"}, acl_attrs = 0x2b9d6e4c0080, acl_attrval_mr = 0x0, acl_attrval_style = ACL_STYLE_REGEX, acl_attrval_re = {buffer = 0x0, allocated = 0, used = 0, syntax = 0, fastmap = 0x0, translate = 0x0, re_nsub = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0, no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 0}, acl_attrval = {bv_len = 0, bv_val = 0x0}, acl_access = 0x2b9d6e969ae0, acl_next = 0x2b9d6e9455c0} It seems we should have never gotten to this section of the code: (gdb) l 855 /* Is this ACL only for a specific value? */ 856 if ( a->acl_attrval.bv_len ) { 857 if ( val == NULL ) { 858 continue; 859 } 860 861 if( state && !( state->as_recorded & ACL_STATE_RECORDED_VD )) { 862 state->as_recorded |= ACL_STATE_RECORDED_VD; 863 state->as_vd_acl = a; 864 state->as_vd_acl_count = *count; 865 state->as_vd_access = a->acl_access; 866 state->as_vd_access_count = 1; 867 ACL_INVALIDATE( state->as_vd_acl_mask ); 868 } 869 870 if ( a->acl_attrval_style == ACL_STYLE_REGEX ) { 871 Debug( LDAP_DEBUG_ACL, 872 "acl_get: valpat %s\n", 873 a->acl_attrval.bv_val, 0, 0 ); 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) Since a->acl_attrval.bv_len is 0. At the moment, Howard and I blame the compiler (gcc 3.4) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk 04 Oct '06

04 Oct '06

Quanah Gibson-Mount wrote: > > > --On Wednesday, October 04, 2006 6:06 PM +0000 tim(a)dcs.qmul.ac.uk wrote: > >> Full_Name: Tim Kay >> Version: >> OS: Linux (Fedora core 5 RPM) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (138.37.95.144) >> >> >> Modifying a DN on the syncrepl provider fails to propogate to the >> consumer. The provider "sends" a valid modify but the consumer, having >> received the modify request walks the tree, returns the parent DN to the >> entry, determines that write access is permitted and the iterates, at >> this point newSuperior->bv_val is set to "*" !? bdb_dn2entry is now >> searching for "�UUU" which looks like some unicode screw up. > > You didn't provide an OpenLDAP version. I'll note that if you intend to > use syncrepl, use OpenLDAP 2.3.27 (or later). > > --Quanah > Sorry Quanah (and everyone else), The identical problem is happening in both 2.3.27 and 2.3.19 with both the bdb and ldbm back ends. Tim > > -- > Quanah Gibson-Mount > Principal Software Developer > ITS/Shared Application Services > Stanford University > GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4697) core dump from acl.c regex
by quanah＠stanford.edu 04 Oct '06

04 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27/HEAD OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) The following core happened today on one of my replicas: Core was generated by `/usr/local/lib/slapd -h ldap:///'. Program terminated with signal 11, Segmentation fault. (gdb) info threads 10 process 28453 0x00002b9d6da82e2c in pthread_join () from /lib/libpthread.so.0 9 process 28455 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6 8 process 28456 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 7 process 28457 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 6 process 28458 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 5 process 28459 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 4 process 28462 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 process 28463 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 2 process 28464 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * 1 process 28461 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 (gdb) thread 10 [Switching to thread 10 (process 28453)]#0 0x00002b9d6da82e2c in pthread_join () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da82e2c in pthread_join () from /lib/libpthread.so.0 #1 0x0000000000425d41 in slapd_daemon () at daemon.c:2261 #2 0x0000000000416254 in main (argc=3, argv=0x7fffffd3c4c8) at main.c:854 (gdb) thread 9 [Switching to thread 9 (process 28455)]#0 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6 (gdb) bt #0 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6 #1 0x0000000000425389 in slapd_daemon_task (ptr=0x6) at daemon.c:1859 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 8 [Switching to thread 8 (process 28456)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 (gdb) thread 7 [Switching to thread 7 (process 28457)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 6 [Switching to thread 6 (process 28458)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 (gdb) thread 5 [Switching to thread 5 (process 28459)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 4 [Switching to thread 4 (process 28462)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 (gdb) thread 3 [Switching to thread 3 (process 28463)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 2 [Switching to thread 2 (process 28464)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 1 [Switching to thread 1 (process 28461)]#0 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 (gdb) bt #0 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 #1 0x00002b9d6dc4dd22 in re_exec () from /lib/libc.so.6 #2 0x00002b9d6dc4b70b in re_exec () from /lib/libc.so.6 #3 0x00002b9d6dc49d83 in re_exec () from /lib/libc.so.6 #4 0x00002b9d6dc48526 in re_exec () from /lib/libc.so.6 #5 0x00002b9d6dc47e83 in re_exec () from /lib/libc.so.6 #6 0x00002b9d6dc474a6 in regexec () from /lib/libc.so.6 #7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874 #8 0x0000000000448521 in fe_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x0) at acl.c:318 #9 0x0000000000443df3 in access_allowed_mask (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x0) at acl.c:429 #10 0x0000000000436e1b in slap_send_search_entry (op=0x2aaaafd40080, rs=0x42ffeeb0) at result.c:894 #11 0x00002b9d6f7342dc in hdb_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at search.c:878 #12 0x000000000042a30a in fe_op_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at search.c:355 #13 0x0000000000429c45 in do_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at search.c:217 #14 0x000000000042837d in connection_operation (ctx=0x42fff020, arg_v=0x2aaaafd40080) at connection.c:1100 #15 0x0000000000428a33 in connection_read_thread (ctx=0x42fff020, argv=0x0) at connection.c:1227 #16 0x00002b9d6d03f522 in ldap_int_thread_pool_wrapper (xpool=0x1) at tpool.c:478 #17 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #18 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 Given that all threads except thread 1 appear to be in the same spot, I'm guessing the problem is in thread 1. Code is: (gdb) frame 7 #7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) (gdb) l 869 870 if ( a->acl_attrval_style == ACL_STYLE_REGEX ) { 871 Debug( LDAP_DEBUG_ACL, 872 "acl_get: valpat %s\n", 873 a->acl_attrval.bv_val, 0, 0 ); 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) 875 { 876 continue; 877 } 878 --Quanah

1 0

(ITS#4696) Assert core in connection.c
by quanah＠stanford.edu 04 Oct '06

04 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27/HEAD OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) The following core occurred on one of my replica systems today: (gdb) info threads 10 process 22650 0x00002b41c03a1e2c in pthread_join () from /lib/libpthread.so.0 9 process 22652 0x00002b41c0581b2c in epoll_wait () from /lib/libc.so.6 8 process 22653 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 7 process 22654 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 6 process 22655 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 5 process 22663 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 4 process 22706 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 process 22707 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 2 process 22708 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * 1 process 22705 0x00002b41c04de545 in raise () from /lib/libc.so.6 In particular: [Switching to thread 1 (process 22705)]#3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at connection.c:655 655 assert( c->c_writewaiter == 0); (gdb) bt #0 0x00002b41c04de545 in raise () from /lib/libc.so.6 #1 0x00002b41c04dfcce in abort () from /lib/libc.so.6 #2 0x00002b41c04d8362 in __assert_fail () from /lib/libc.so.6 #3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at connection.c:655 #4 0x0000000000428a6c in connection_read_thread (ctx=0x42fff020, argv=0x68) at connection.c:1391 #5 0x00002b41bf95e522 in ldap_int_thread_pool_wrapper (xpool=0x587a) at tpool.c:478 #6 0x00002b41bf66fc93 in startMeUp () from /usr/local/lib/libhoard.so #7 0x00002b41c03a0b55 in start_thread () from /lib/libpthread.so.0 #8 0x00002b41c05817f0 in clone () from /lib/libc.so.6 (gdb) frame 3 #3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at connection.c:655 655 assert( c->c_writewaiter == 0); (gdb) l 650 assert( connections != NULL ); 651 assert( c != NULL ); 652 assert( c->c_struct_state != SLAP_C_UNUSED ); 653 assert( c->c_conn_state != SLAP_C_INVALID ); 654 assert( LDAP_STAILQ_EMPTY(&c->c_ops) ); 655 assert( c->c_writewaiter == 0); 656 657 /* only for stats (print -1 as "%lu" may give unexpected results ;) */ 658 connid = c->c_connid; 659 close_reason = c->c_close_reason; --Quanah

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by quanah＠stanford.edu 04 Oct '06

04 Oct '06

--On Wednesday, October 04, 2006 6:06 PM +0000 tim(a)dcs.qmul.ac.uk wrote: > Full_Name: Tim Kay > Version: > OS: Linux (Fedora core 5 RPM) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.95.144) > > > Modifying a DN on the syncrepl provider fails to propogate to the > consumer. The provider "sends" a valid modify but the consumer, having > received the modify request walks the tree, returns the parent DN to the > entry, determines that write access is permitted and the iterates, at > this point newSuperior->bv_val is set to "*" !? bdb_dn2entry is now > searching for "�UUU" which looks like some unicode screw up. You didn't provide an OpenLDAP version. I'll note that if you intend to use syncrepl, use OpenLDAP 2.3.27 (or later). --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk 04 Oct '06

04 Oct '06

Full_Name: Tim Kay Version: OS: Linux (Fedora core 5 RPM) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (138.37.95.144) Modifying a DN on the syncrepl provider fails to propogate to the consumer. The provider "sends" a valid modify but the consumer, having received the modify request walks the tree, returns the parent DN to the entry, determines that write access is permitted and the iterates, at this point newSuperior->bv_val is set to "*" !? bdb_dn2entry is now searching for "�UUU" which looks like some unicode screw up. Oct 4 17:38:37 auth1 slapd[2975]: syncrepl_entry: be_search (0) Oct 4 17:38:37 auth1 slapd[2975]: syncrepl_entry: cn=laptT5,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk Oct 4 17:38:37 auth1 slapd[2975]: ==>bdb_modrdn(cn=laptT2,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk,cn=laptT5,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk,*) Oct 4 17:38:37 auth1 slapd[2975]: bdb_dn2entry("cn=laptt2,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk") Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: wr to children of entry ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk OK Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: parent dn=ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: new parent "*" requested... Oct 4 17:38:37 auth1 slapd[2975]: bdb_dn2entry("�UUU") Oct 4 17:38:37 auth1 slapd[2975]: => bdb_dn2id("") Oct 4 17:38:37 auth1 slapd[2975]: <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: newSup(ndn=�UUU) not here! Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: err=32 matched="" text="new superior not found" Oct 4 17:38:37 auth1 slapd[2975]: syncrepl_entry: be_modrdn (32) Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify: dc=dcs,dc=qmul,dc=ac,dc=uk Oct 4 17:38:37 auth1 slapd[2975]: bdb_dn2entry("dc=dcs,dc=qmul,dc=ac,dc=uk") Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify_internal: 0x00000001: dc=dcs,dc=qmul,dc=ac,dc=uk Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify_internal: replace contextCSN Oct 4 17:38:37 auth1 slapd[2975]: => entry_encode(0x00000001): dc=dcs,dc=qmul,dc=ac,dc=uk Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify: updated id=00000001 dn="dc=dcs,dc=qmul,dc=ac,dc=uk" Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: err=0 matched="" text=""

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