February 2008 - openldap-bugs

(ITS#5389) Contribution: JLDAP support for password policy response control

by t2tre＠skyblue.eu.com

Full_Name: Raymond Edah Version: JLDAP CVS HEAD OS: Windows URL: http://www.cs.skyblue.eu.com/ray/code/LDAPPasswordPolicyResponse.tar.gz Submission from: (NULL) (81.3.106.202) Hi, I have written a class for handling the password policy response control as described in draft-behera-ldap-password-policy-09.txt. I would like to contribute it to the OpenLDAP project. A copy of the code can be found at http://www.cs.skyblue.eu.com/ray/code/LDAPPasswordPolicyResponse.tar.gz. Regards, Ray Edah

15 years, 7 months

1
0
0 / 0

(ITS#5388) NULL pointer dereference

by dhen42＠yahoo.co.uk

Full_Name: Dennis Henriksen Version: 2.4.8 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.10) In server/slapd/oc.c(oc_next) suffers from a potential NULL pointer dereference in the statement '*oc = LDAP_STAILQ_NEXT(*oc,soc_next);'. Perhaps this should read (if *oc != NULL) *oc = LDAP_STAILQ_NEXT(*oc,soc_next);'

15 years, 7 months

1
0
0 / 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)

by jclarke＠linagora.com

h.b.furuseth(a)usit.uio.no a écrit : > jclarke(a)linagora.com writes: >> When slapcat is writing it's output to disk, it ignores any errors >> (with slapcat -l output_file or slapcat > output_file). If an error is >> encountered, such as "No space left on device", slapcat then exits >> normally with a return code of 0. > > Eh. API design bug. ldif_tool_entry_first()/ldif_tool_entry_next() > have no way to return error. At best they can set an "error" flag > in the internal database structure, and API calls which are able > to return errors can react to that. Hmmm. I may have misunderstood, but it seems this concerns internal errors, whereas I was referring to the output (writing the data to stdout or to a file) errors. The patch I attached addresses this issue, is there any chance of seeing it included in OpenLDAP, or does it need some more work? Regards, Jonathan -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

15 years, 7 months

1
0
0 / 0

Re: (ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)

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

jclarke(a)linagora.com writes: > When slapcat is writing it's output to disk, it ignores any errors > (with slapcat -l output_file or slapcat > output_file). If an error is > encountered, such as "No space left on device", slapcat then exits > normally with a return code of 0. Eh. API design bug. ldif_tool_entry_first()/ldif_tool_entry_next() have no way to return error. At best they can set an "error" flag in the internal database structure, and API calls which are able to return errors can react to that. -- Hallvard

15 years, 7 months

1
0
0 / 0

(ITS#5387) slapcat ignores errors while writing output (no space left on device, etc)

by jclarke＠linagora.com

Full_Name: Jonathan Clarke Version: 2.3, HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-20080220.patch.3 Submission from: (NULL) (213.41.243.192) Hi all, When slapcat is writing it's output to disk, it ignores any errors (with slapcat -l output_file or slapcat > output_file). If an error is encountered, such as "No space left on device", slapcat then exits normally with a return code of 0. This seems pretty dangerous to me - if you back up your database with slapcat, but don't get an error on failure, it could easily lead to data loss. Please find at the address below a patch to stop on such errors. It may require some cleaning up - apologies if so. Regards, Jonathan

15 years, 7 months

1
0
0 / 0

Re: ITS#5375

by quanah＠zimbra.com

I suggest you download and build OpenLDAP 2.4.8. ;) <http://www.openldap.org/software/download/> --Quanah --On Monday, February 18, 2008 12:10 PM +0000 ecizaguirre(a)gmv.com wrote: > > Hi again Pierangelo and Quanah, I have tested the REL_ENG_2_4 version > with the fix under heavy worload and it seems to be working correctly so > the problem is fixed. > > I'm still not able to compile 2.4.7 version with the fix applied. > > Thanks for all and for this great software. > > Cheers. > > Eduardo > > ______________________ > Este mensaje, y en su caso, cualquier fichero anexo al mismo, > puede contener informacion clasificada por su emisor como confidencial > en el marco de su Sistema de Gestion de Seguridad de la > Informacion siendo para uso exclusivo del destinatario, quedando > prohibida su divulgacion copia o distribucion a terceros sin la > autorizacion expresa del remitente. Si Vd. ha recibido este mensaje > erroneamente, se ruega lo notifique al remitente y proceda a su borrado. > Gracias por su colaboracion. > ______________________ > This message including any attachments may contain confidential > information, according to our Information Security Management System, > and intended solely for a specific individual to whom they are addressed. > Any unauthorised copy, disclosure or distribution of this message > is strictly forbidden. If you have received this transmission in error, > please notify the sender immediately and delete it. > ______________________ > > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

15 years, 7 months

1
0
0 / 0

Re: [JunkMail] Re: (ITS#5383) olc* not present in subschema subentry

by michael＠stroeder.com

Howard Chu wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> In RE24 the config schema are only exposed for DEVEL builds. >> >> Why that? Especially why was it changed compared to RE23? > > They were probably exposed in RE23 by mistake. Another option would be to completely disable the subschema subentry for back-config. In this case users of web2ldap could work around it by using a locally stored schema LDIF file for back-config. Ciao, Michael.

15 years, 7 months

1
0
0 / 0

Re: (ITS#5386) Bad value of entryUUID in filter crashes slapd

by ando＠sys-net.it

silk(a)boktor.net wrote: > If client sends a filter that lookups entries based on entryUUID, and the value > of entryUUID is invalid (eg. not properly formed) slapd dies with an assertion. Fixed in HEAD (servers/slapd/filter.c 1.148->1.149) Please test. 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 ---------------------------------------

15 years, 7 months

1
0
0 / 0

Re: (ITS#5385) contextCSN not propagated in cascading syncrepl refreshAndPersist

by hyc＠symas.com

bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: OPENLDAP_REL_ENG_2_3 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.15.129.131) > > > One of our environments does cascading replication of one database (the master > for the other databases in this environment is a syncrepl refreshAndPersist > syncrepl client to a database in another environment). > > We monitor the replication status of all our slaves by comparing the contextCSN > on each database with the contextCSN of the updateref, and I have noticed that > the contextCSN on the cascaded replicas is not being updated, even though the > entries have been replicated (according to logging at sync level on these > slaves). All other replication (including non-cascaded refreshAndPersist > databases) works fine. All the servers in question are currently on 2.3.40. > > It seems that the issue can be reproduced with current REL_ENG_2_3, with a > slight modification to test019 (see patch below) to include the contextCSN in > the comparison, which will then fail as follows: I've reproduced this issue in RE23 as well. I note that there's no such problem with RE24. If we can't track this down easily I'm inclined to just ignore it. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

15 years, 7 months

1
0
0 / 0

(ITS#5386) Bad value of entryUUID in filter crashes slapd

by silk＠boktor.net

Full_Name: Grzegorz Sobanski Version: 2.4.7(-5) OS: Debain unstable URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (150.254.130.134) If client sends a filter that lookups entries based on entryUUID, and the value of entryUUID is invalid (eg. not properly formed) slapd dies with an assertion. Example filter: (entryUUID=baka) Steps to reproduce: ldapsearch -x "(entryUUID=baka)" Reproducible: always Error logged by slapd: slapd: /home/devel/openldap/build-area/openldap2.3-2.4.7/servers/slapd/schema_init.c:2537: UUIDNormalize: Assertion `val->bv_len == 16' failed. Expected behaviour: Server does not dies, and: - backwards compatible: filter on entryUUID is skipped - not backward compatible: client is informed about malformed search filter If any more information or tests are needed, please ask.

15 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 February 2008