August 2008 - openldap-bugs

(ITS#5668) Invalid entryCSN generated, and slapd will not restart

by emmanuel.duru＠atosorigin.com

Full_Name: Emmanuel Duru Version: 2.4.11 OS: Windows URL: Submission from: (NULL) (80.78.0.137) On Windows, slapd generates entryCSN values such as: 20080822124130.-657205Z#000000#000#000000 (the problem is the minus sign). This is also the case when generating the cn=config branch from a slapd.conf file. Following this, slapd will not restart, because it checks the validity of entryCSN values on cn=config branch at startup. I believe that the problem comes from non initialized static variables in lutil_gettime() function. Do notice that initializations are also missing in non WIN32 section.

14 years, 7 months

1
0
0 / 0

(ITS#5665)

by toby＠inf.ed.ac.uk

Hi there, I've patched pcache.c and it seems fine. I'll put it through some more testing and confirm. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

14 years, 7 months

1
0
0 / 0

Re: (ITS#5665) slapd crashing with slapo-pcache when using attrset "*"

by ando＠sys-net.it

Should be fixed in HEAD; please test. 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

14 years, 7 months

1
0
0 / 0

Re: (ITS#5667) Problem in the startTLS Command processing

by Kurt＠OpenLDAP.org

On Aug 22, 2008, at 2:53 PM, john.w.clark(a)hp.com wrote: > Full_Name: > Version: 2.3.36 and earlier and I assume also later > OS: Red Hat Enterprise Linux 4.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (15.203.233.75) > > > This problem was previously described one the openLDAP websiste at: > > http://www.openldap.org/lists/openldap-bugs/200405/msg00096.html > > The described fix is not included in release 2.3.36 and I assume > that it has not > been included in later releases either. > > The probem is with the response to the 'startTLS' command in the > 'slapd' server. > > > Here is an excerpt from the write up at the above URL: > > ************************************************************** > Having fixed described above we came across another issues which > concerns > TLS extended operation response. > > As RFC2830 states: RFC 2830 has been replaced by RFC 4510, 4511, and RFC 4513. > ... > A Start TLS extended response MUST contain a responseName field > which > MUST be set to the same string as that in the responseName field > present in the Start TLS extended request. > ... This MUST was purposely removed from the revised LDAP specifications by the IETF. > Unfortunately OpenLDAP server doesn't return the 'responseName' > field. This > defect may prevent other LDAP APIs from understanding the response of > OpenLDAP servers. Clients are suppose to message-ids to match up responses with requests. > For instance, Microsoft LDAP API doesn't accept the > response without this field. Sounds like a bug in Microsoft LDAP, especially given the current Start TLS specification. I suggest you report this to them. > We suggest to add the responseName field to the > response. This is also a trivial one: > > rs->sr_rspoid = SLAP_STRDUP(LDAP_EXOP_START_TLS); > > before 'rc = LDAP_SUCCESS;' in starttls_extop() function (starttls.c). See my comments in my response to ITS#3037 as to why I think such should not be done. > > > 3. Patch > > Unfortunately didn't manage to get access to the /incoming FTP folder > despite the fact I used my email as password. So here is a patch for > both > problems: > > ============= > --- orig/starttls.c 2004-01-01 21:15:32.000000000 +0200 > +++ fixed/starttls.c 2004-05-27 14:14:54.000000000 +0300 > @@ -94,6 +94,8 @@ > op->o_conn->c_is_tls = 1; > op->o_conn->c_needs_tls_accept = 1; > > + rs->sr_rspoid = SLAP_STRDUP(LDAP_EXOP_START_TLS); > + > rc = LDAP_SUCCESS; > > done: > ============= > > Looking forward for your comments... > > Sincerely yours, > > Kirill Kovalenko > Softerra LLC > ************************************************************ > > > Thanks and Regards, > John Clark > > john.w.clark(a)hp.com > Sr. Software Engineer > Hewlett-Packard > Atalla Security Products > >

14 years, 7 months

1
0
0 / 0

(ITS#5667) Problem in the startTLS Command processing

by john.w.clark＠hp.com

Full_Name: Version: 2.3.36 and earlier and I assume also later OS: Red Hat Enterprise Linux 4.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (15.203.233.75) This problem was previously described one the openLDAP websiste at: http://www.openldap.org/lists/openldap-bugs/200405/msg00096.html The described fix is not included in release 2.3.36 and I assume that it has not been included in later releases either. The probem is with the response to the 'startTLS' command in the 'slapd' server. Here is an excerpt from the write up at the above URL: ************************************************************** Having fixed described above we came across another issues which concerns TLS extended operation response. As RFC2830 states: ... A Start TLS extended response MUST contain a responseName field which MUST be set to the same string as that in the responseName field present in the Start TLS extended request. ... Unfortunately OpenLDAP server doesn't return the 'responseName' field. This defect may prevent other LDAP APIs from understanding the response of OpenLDAP servers. For instance, Microsoft LDAP API doesn't accept the response without this field. We suggest to add the responseName field to the response. This is also a trivial one: rs->sr_rspoid = SLAP_STRDUP(LDAP_EXOP_START_TLS); before 'rc = LDAP_SUCCESS;' in starttls_extop() function (starttls.c). 3. Patch Unfortunately didn't manage to get access to the /incoming FTP folder despite the fact I used my email as password. So here is a patch for both problems: ============= --- orig/starttls.c 2004-01-01 21:15:32.000000000 +0200 +++ fixed/starttls.c 2004-05-27 14:14:54.000000000 +0300 @@ -94,6 +94,8 @@ op->o_conn->c_is_tls = 1; op->o_conn->c_needs_tls_accept = 1; + rs->sr_rspoid = SLAP_STRDUP(LDAP_EXOP_START_TLS); + rc = LDAP_SUCCESS; done: ============= Looking forward for your comments... Sincerely yours, Kirill Kovalenko Softerra LLC ************************************************************ Thanks and Regards, John Clark john.w.clark(a)hp.com Sr. Software Engineer Hewlett-Packard Atalla Security Products

14 years, 7 months

1
0
0 / 0

Re: (ITS#5662) Comments in schema declarations separated by semicolon

by michael＠stroeder.com

Kurt Zeilenga wrote: > > On Aug 21, 2008, at 9:57 AM, michael(a)stroeder.com wrote: > >> Hallvard B Furuseth wrote: >>> michael(a)stroeder.com writes: >>>> hyc(a)symas.com wrote: >>>>> Who benefits from this feature? >>>> An admin copying&pasting a schema from an standard document which uses >>>> this format. I'm currently looking at such a document with ~500 >>>> occurences of OIDs used in declarations instead of NAMEs. >>> >>> Which one? It's not RFC 4512 format. RFC 4512 uses ';' for comments >>> _about_ the syntax of schema elements, not _in_ their syntax. >> >> http://tools.ietf.org/draft/draft-dally-acp133-and-ldap/ > > There is a lot of crap in I-Ds, and even some crap in RFCs. Yes. :-/ That's why I was asking whether it's feasible to be liberal in what you receive (read from config) but to be strict in what you send (add to the schema). Ciao, Michael.

14 years, 7 months

1
0
0 / 0

Re: (ITS#5666) getpeereid.c:65: error: storage size of peercred isnt known

by ghenry＠OpenLDAP.org

----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: > Presumably a dup of ITS#5464. > Workaround: Compile with CPPFLAGS=-D_GNU_SOURCE. Yeah, that's compiling now. Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

14 years, 7 months

1
0
0 / 0

Re: (ITS#5666) getpeereid.c:65: error: storage size of peercred isnt known

by h.b.furuseth＠usit.uio.no

Presumably a dup of ITS#5464. Workaround: Compile with CPPFLAGS=-D_GNU_SOURCE. -- Hallvard

14 years, 7 months

1
0
0 / 0

(ITS#5666) getpeereid.c:65: error: storage size of peercred isnt known

by ghenry＠OpenLDAP.org

Full_Name: Gavin Henry Version: 2.4.11 OS: Fedora 9 i386 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.229.93.1) Submitted by: ghenry gcc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB.4.2/include -c -o fetch.o fetch.c gcc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB.4.2/include -c -o setproctitle.o setproctitle.c gcc -g -O2 -I../../include -I../../include -I/usr/local/BerkeleyDB.4.2/include -c -o getpeereid.o getpeereid.c getpeereid.c: In function lutil_getpeereid: getpeereid.c:65: error: storage size of peercred isnt known make[2]: *** [getpeereid.o] Error 1 Hi all, For some reason this is dieing on my laptop at above, but I haven't tested this on Fedora 9 i386 before, sorry. Any ideas?

14 years, 7 months

1
0
0 / 0

Re: (ITS#5661) contextCSN gets corrupted on the stand by mirror

by ghenry＠OpenLDAP.org

> The fact that the two servers scan the whole database is a side effect > > of the incorrect contextCSN; I wouldn't bother, as soon as the > corruption gets tracked and fixed. Is there anything that should be updated for the MirrorMode docs here? -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

14 years, 7 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2008