(ITS#4701) slapd crash using slapmodrdn
by andy.n.parker＠unilever.com
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)
16 years, 11 months
(ITS#4700) slapd crash using slapmodrdn
by andy.n.parker＠unilever.com
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
16 years, 11 months
Re: (ITS#4699) snacc-2.3.3beta doesn't compile
by Kurt＠OpenLDAP.org
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
16 years, 11 months
(ITS#4699) snacc-2.3.3beta doesn't compile
by dieter＠dkluenter.de
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
16 years, 11 months
Re: authz-regexp matches twice on same dse (ITS#4698)
by ap＠d-dt.de
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
--
16 years, 11 months
Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk
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
16 years, 11 months
(ITS#4698) authz-regexp matches twice on same dse
by adampordzik＠gmx.de
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.
16 years, 11 months
Re: (ITS#4697) core dump from acl.c regex
by quanah＠stanford.edu
--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
16 years, 11 months
Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk
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
16 years, 11 months
