openldap-bugs

openldap-bugs@openldap.org

1 participants
20997 discussions

(ITS#4701) slapd crash using slapmodrdn
by andy.n.parker＠unilever.com 06 Oct '06

06 Oct '06

Full_Name: Andrew Neil Parker Version: 2.3.27 OS: RHEL 3.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.60.106.5) slapd crashed with an "assert failure" in lastmod.c line 593 when using slapmodrn command. Fault is reproducable. Get around is to remove lastmod overlay from config file. Trace output using -d 1 is provided on ftp site. 150 Opening BINARY mode data connection for 'andy.n.parker-061006.ext'. 226 Transfer complete (unique file name:andy.n.parker-061006.ext). 3036 bytes sent in 0.00025 seconds (1.2e+04 Kbytes/s)

1 0

(ITS#4700) slapd crash using slapmodrdn
by andy.n.parker＠unilever.com 06 Oct '06

06 Oct '06

1 0

Re: (ITS#4699) snacc-2.3.3beta doesn't compile
by Kurt＠OpenLDAP.org 05 Oct '06

05 Oct '06

I suggest that anyone wanting to toy with LDAP component matching in OpenLDAP Software use HEAD... the feature needs work. At 02:18 PM 10/5/2006, dieter(a)dkluenter.de wrote: >Full_Name: Dieter Kluenter >Version: openldap-snacc-2.3.3beta Not sure why you didn't try 2.3.6, but regardless, see above. Kurt

1 0

(ITS#4699) snacc-2.3.3beta doesn't compile
by dieter＠dkluenter.de 05 Oct '06

05 Oct '06

Full_Name: Dieter Kluenter Version: openldap-snacc-2.3.3beta OS: linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.210.55) Hi, This are the errors from my attempt to compile snacc /usr/include/c++/3.3.5/backward/backward_warning.h:32:2: Warnung: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated. vdatest.cpp: In function `void test_timingDoTestPrint(long int, long int, int, long int)': vdatest.cpp:1048: Warnung: int Format, anderer Typ Argument (Argument 4) vdatest.cpp: In function `void AsnIntTest()': vdatest.cpp:1283: error: no matching function for call to `SNACC::AsnInt:: getPadded(unsigned char*&, unsigned int&, int)' ../../c++-lib/inc/asn-incl.h:645: error: candidates are: void SNACC::AsnInt::getPadded(unsigned char*&, size_t&, long unsigned int) const vdatest.cpp:1335: error: no matching function for call to `SNACC::AsnInt:: getPadded(unsigned char*&, unsigned int&, int)' ../../c++-lib/inc/asn-incl.h:645: error: candidates are: void SNACC::AsnInt::getPadded(unsigned char*&, size_t&, long unsigned int) const make[3]: *** [vdatest.o] Fehler 1 make[3]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples/src' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples/src' make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples' make: *** [all] Fehler 2 -Dieter

1 0

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 05 Oct '06

05 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 05 Oct '06

05 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

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