openldap-bugs May 2008

openldap-bugs@openldap.org

54 participants
208 discussions

Re: (ITS#5524) Additions to the Security section of the Admin Guide
by ghenry＠OpenLDAP.org 26 May '08

26 May '08

> I've patched security.sdf and I'm abotu to clean up some typos and > formating. Hmm, maybe I should do the same to the e-mails I write ;-)

1 0

Re: (ITS#5521) Can't change indexing of an attribute within a single modification
by rhafer＠suse.de 26 May '08

26 May '08

On Sonntag, 25. Mai 2008, Pierangelo Masarati wrote: > rhafer(a)suse.de wrote: > > The following modification to add an additional index an attribute > > fails with the error messages pasted below: > > > > -------------------------- > > dn: olcDatabase={1}bdb,cn=config > > changetype: modify > > delete: olcdbindex > > olcDbIndex: cn pres,eq > > - > > add: olcdbindex > > olcDbIndex: cn pres,eq,sub > > -------------------------- > > > > modifying entry "olcDatabase={1}bdb,cn=config" > > ldap_modify: Other (e.g., implementation specific) error (80) > > additional info: <olcDbIndex> handler exited with 1 > > > > As far as I can see it fails because the old indexmask hat not yet > > been deleted from the bdb-struct. The ainfo_insert()-call in > > back-bdb/attr.c(bdb_attr_index_config()) returns with -1. > > > > Splitting the above modification in two separate operations works > > around that problem. > > What about using replace instead? That causes the same behavior as the modification pasted above. So it doesn't work as well. -- Ralf

1 0

Re: (ITS#5524) Additions to the Security section of the Admin Guide
by ghenry＠OpenLDAP.org 26 May '08

26 May '08

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.9 > OS: Linux > URL: http://www.skills-1st.co.uk/pub/code/openldap-guide-patch-20080522 > Submission from: (NULL) (88.97.25.132) > > > This patch adds text to the Security chapter in the Admin Guide. It describes > the password storage schemes, including the {SASL} scheme that triggers > pass-through authentication. The latter facility has existed since version 2.0 > but has never been mentioned in the docs, so I have included a section with an > example of its use. > > I've patched security.sdf and I'm abotu to clean up some typos and formating. Should we also mention that CRYPT is platform specific? Lastly, should I also put: Portions Copyright 2008 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk> into doc/guide/COPYRIGHT ? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5244) Problem configuring openldap 2.4.6
by h.b.furuseth＠usit.uio.no 25 May '08

25 May '08

pierre42d(a)9online.fr writes: > Ok i agree it's an enhancement request rather than a bug. I know this > environment variables, but my point of view is that /usr/local should > be considered part of default/standard system locations. I don't think we should suddenly mess with these defaults now, but there could be an option to add them to CPPFLAGS and LDFLAGS. Or rather, add $includedir (default /usr/local/include) and $libdir (default /usr/local/lib). -- Hallvard

1 0

(ITS#5528) Problem compiling openldap 2.4.9
by pierre42d＠9online.fr 25 May '08

25 May '08

Full_Name: Pierre Version: 2.4.9 OS: GNU/Linux URL: Submission from: (NULL) (79.82.49.83) # make Making all in /tmp/openldap-2.4.9 Entering subdirectory include make[1]: Entering directory `/tmp/openldap-2.4.9/include' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/tmp/openldap-2.4.9/include' Entering subdirectory libraries make[1]: Entering directory `/tmp/openldap-2.4.9/libraries' Making all in /tmp/openldap-2.4.9/libraries Entering subdirectory liblutil make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblutil' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblutil' Entering subdirectory liblber make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblber' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblber' Entering subdirectory liblunicode make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/liblunicode' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/liblunicode' Entering subdirectory libldap make[2]: Entering directory `/tmp/openldap-2.4.9/libraries/libldap' /bin/sh ../..//libtool --mode=link gcc -s -O3 -march=i686 -L/usr/local/BerkeleyDB.4.6/lib -o apitest apitest.o libldap.la ../../libraries/liblber/liblber.la ../../libraries/liblutil/liblutil.a -lsasl2 -lgnutls -lcrypt -lresolv gcc -s -O3 -march=i686 -o .libs/apitest apitest.o -L/usr/local/BerkeleyDB.4.6/lib ./.libs/libldap.so /tmp/openldap-2.4.9/libraries/liblber/.libs/liblber.so -L/usr/local/lib ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/local/lib/libsasl2.so -ldl /usr/local/lib/libgnutls.so /usr/local/lib/libtasn1.so /usr/local/lib/libgcrypt.so -lnsl -lcap /usr/local/lib/libgpg-error.so -lz -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_cipher_suite_info' collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 make[2]: Leaving directory `/tmp/openldap-2.4.9/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/tmp/openldap-2.4.9/libraries' make: *** [all-common] Error 1

1 0

Re: (ITS#5244) Problem configuring openldap 2.4.6
by pierre42d＠9online.fr 25 May '08

25 May '08

Ok i agree it's an enhancement request rather than a bug. I know this environment variables, but my point of view is that /usr/local should be considered part of default/standard system locations. Regards,

1 0

Re: (ITS#5521) Can't change indexing of an attribute within a single modification
by ando＠sys-net.it 25 May '08

25 May '08

rhafer(a)suse.de wrote: > The following modification to add an additional index an attribute fails with > the error messages pasted below: > > -------------------------- > dn: olcDatabase={1}bdb,cn=config > changetype: modify > delete: olcdbindex > olcDbIndex: cn pres,eq > - > add: olcdbindex > olcDbIndex: cn pres,eq,sub > -------------------------- > > modifying entry "olcDatabase={1}bdb,cn=config" > ldap_modify: Other (e.g., implementation specific) error (80) > additional info: <olcDbIndex> handler exited with 1 > > As far as I can see it fails because the old indexmask hat not yet been deleted > from the bdb-struct. The ainfo_insert()-call in > back-bdb/attr.c(bdb_attr_index_config()) returns with -1. > > Splitting the above modification in two separate operations works around that > problem. What about using replace instead? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5517) add superclass of existing class fails
by ando＠sys-net.it 25 May '08

25 May '08

Kurt Zeilenga wrote: > > On May 24, 2008, at 2:18 AM, ando(a)sys-net.it wrote: > >> I believe the actual implementation should be... implementation >> dependent :), provided it is consistent. > > I agree there is a slight inconsistency. > > A client can delete a listed superclass but not add an superclass of a > listed attribute. > > One could argue that both be considered invalid operations. However, it > would be reasonable to consider an add of an unlisted superclass and a > delete of a listed superclass to be valid. However, a add of an already > listed class should be invalid and a delete of a unlisted class should > always be invalid. Agreed. With respect to the current implementation, we're back to square one, since the issue is related to using objectSubClassMatch() to check for the presence of a value. Any superclass is returned as present no matter if it is actually present or just implied. From your answers, it seems that treating objectClass specially should be the solution, and the fix I'm proposing goes in this direction. Should I commit it, or does anyone see any side effect? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org 24 May '08

24 May '08

On May 24, 2008, at 2:18 AM, ando(a)sys-net.it wrote: > I believe the actual implementation should be... implementation > dependent :), provided it is consistent. I agree there is a slight inconsistency. A client can delete a listed superclass but not add an superclass of a listed attribute. One could argue that both be considered invalid operations. However, it would be reasonable to consider an add of an unlisted superclass and a delete of a listed superclass to be valid. However, a add of an already listed class should be invalid and a delete of a unlisted class should always be invalid. -- Kurt

1 0

Re: (ITS#5517) add superclass of existing class fails
by Kurt＠OpenLDAP.org 24 May '08

24 May '08

On May 24, 2008, at 2:37 PM, h.b.furuseth(a)usit.uio.no wrote: > ando(a)sys-net.it writes: >> The issue right now is caused by the fact that comparing present >> values with the asserted one causes objectSubClassMatch() to check >> for >> match including superiors. > > This looks like a bug to me. Maybe in the RFCs. > objectClass has EQUALITY matching rule > objectIdentifierMatch, which does not follow the object class > inheritance chain. Yes, but objectClass is quite special (despite being a userApplications attribute). For instance, (objectClass=*) is to match DSEs which don't have an objectClass attribute. Likewise, objectClass=foo can match objectClass attributes which don't explicitly contain foo. > See RFC 4517 section 4.2.26. RFC 4512 section 3.3 > (the 'objectClass' attribute) does not special-case this. > > What makes slapd work is that it also disobeys RFC 4512 section 3.3: > "When creating an entry or adding an 'objectClass' value to an > entry, > all superclasses of the named classes SHALL be implicitly added as > well if not already present." > This doesn't say the classes shall be considered to be implicitly > present, like slapd does. You are reading 3.3 as if it said "SHALL be added (by the server)". It doesn't say "SHALL be added (by the server). It says "SHALL be implicitly added" (presumedly by the server). This was discussed during LDAPbis discussions. As the Editor of RFC 4512, I can say that it was my intent to allow servers to merely treat superclasses as being present. > Instead slapd should add the missing classes to the actual object, Doing so is problematic. A client which adds B then deletes B would be surprised by non-net-zero result of the operation(s). > just like it adds some other attribute/values > implicitly (createTimestamp, subschemaSubentry, etc). These are operational attributes. ObjectClass is an userApplications attribute. Servers should not muck with the values of userApplication attributes. > I don't know what to do about it now though. Will replication work > between current servers and servers which obeys the RFCs? Is this a > RE25 > fix, so we should stay with fixed like previously suggested in > RE24? Or > yet another thing to do with the last RE23, for the sake of > replication? > > -- > Hallvard > >

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
21
Older →

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 May 2008