openldap-bugs

openldap-bugs@openldap.org

1 participants
20956 discussions

(ITS#4877) Patch to ldapmodrdn.1
by daveh＠ci.com.au 13 Mar '07

13 Mar '07

Full_Name: Dave Horsfall Version: HEAD OS: FreeBSD 6.2 URL: ftp://ftp.openldap.org/incoming/dave-horsfall-070314.patch Submission from: (NULL) (192.65.182.30) Trivial patch to ldapmodrdn.1 to document "-s newsup".

1 0

(ITS#4876) Multiple levels of uniqueness
by quanah＠stanford.edu 13 Mar '07

13 Mar '07

Full_Name: Quanah Gibson-Mount Version: 2.3.33 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In using the uniqueness overlay, I found there are times I want to apply uniqueness rules differently based on (sub)tree. For example, I might like something along these lines where the db starts at dc=stanford,dc=edu: overlay unique unique_base dc=stanford,dc=edu unique_attributes krb5PrincipalName suRegID overlay unique unique_base cn=people,dc=stanford,dc=edu unique_attributes suunivid suproxycardnumber sucardnumber suuniqueidentifier overlay unique unique_base cn=accounts,dc=stanford,dc=edu unique_attributes uid However, I found in testing this, that any instantiation of the uniqueness overlay past the first one is ignored (i.e., not applied to writes). I think being able to do this is useful, becase I only want the uniqueness overlay to intercede when the write applies to the particular (sub)tree where it is necessary to enforce it. It may be worthwhile to update the syntax for the uniqueness overlay to behave more like the valsort overlay, where each attribute defines which tree it is applying weights to, like: overlay valsort valsort-attr ou cn=people,dc=stanford,dc=edu weighted valsort-attr suAffiliation cn=people,dc=stanford,dc=edu weighted valsort-attr suDisplayAffiliation cn=people,dc=stanford,dc=edu weighted --Quanah

1 0

(ITS#4875) fix for bug in passfile.c -- infinite loop when password file is pipe/FIFO/tty/etc
by pzq_1＠jural.com 13 Mar '07

13 Mar '07

Full_Name: Mark Seecof Version: 2.3.34 OS: Linux URL: ftp://ftp.openldap.org/incoming/MARK-SEECOF-070313.patch Submission from: (NULL) (151.152.101.44) When you ask an OpenLDAP tool such as ldapsearch(1) to read a password from a file which is a pipe, FIFO, tty/pty, or other special file, the tool will go into an infinite loop in function lutil_get_filed_password() (from libraries/liblutil/passfile.c). The problem is a bug in lutil_get_filed_password(): it calls fstat() on the password file, then enters a loop attempting to read st_size bytes from the file until it reaches EOF. For pipes, FIFO's, tty's, etc. st_size is typically 0, so the loop never finishes--you may read 0 bytes from the file an infinite number of times without ever reaching the end! (Actually, fread(,,0,) is a no-op.) This bug only requires a one-line fix (though I actually propose to change two lines). We simply eliminate the check on st_size and attempt to read a buffer-full of bytes. The existing code cheerfully copes with that many bytes, fewer, or more... (My second change is to the default buffer size, to make it more efficient.) SIMPLE LINUX 2.6 TEST CASE echo -n "password" | ldapsearch -U user -Y Digest-MD5 -y /dev/stdin '(foo=bar)' GENERIC UNIX/LINUX TEST CASE mknod pw_fifo p echo -n "password" > pw_fifo & ldapsearch -U user -Y Digest-MD5 -y pw_fifo '(foo=bar)' Please retrieve my patch from MARK-SEECOF-070313.patch I, Mark Seecof, hereby place the modifications to OpenLDAP Software I supply in MARK-SEECOF-070313.patch (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#4874) Possible acl_set_cb_gather() bug
by rein＠basefarm.no 13 Mar '07

13 Mar '07

Full_Name: Rein Tollevik Version: 2.3.34 OS: Solaris8 URL: Submission from: (NULL) (81.93.160.250) While looking for a fix for the problem I reported in ITS#4873 I noticed what looks like a minor typo bug in acl_set_cb_gather() in servers/slapd/acl.c. Near the end there is a test for "if ( bvals )" which I suspect should have been "if ( bvalsp )". The bug shouldn't do any more harm than wasting a few cpu cycles though, as bvals should always be true and slap_set_join() with NULL bvalsp should return the same origninal set... Rein Tollevik Basefarm AS

1 0

(ITS#4873) ACL set memory corruption and leak
by rein＠basefarm.no 13 Mar '07

13 Mar '07

Full_Name: Rein Tollevik Version: 2.3.34 OS: Solaris 8 URL: Submission from: (NULL) (81.93.160.250) The fix for ITS#4780 seem to have introduced a memory corruption when ACL sets are used, it causes memory that is still in use to be freed after two sets are or'ed. Furthermore, the fix only frees the value in the first element of a multi-element set, i.e it still leaks memory when the values should be released. Our servers started to seg. faulting shortly after we upgraded from version 2.3.19 to 2.3.34, but have stayed alive after the patched included below was applied. Rein Tollevik Basefarm AS Index: servers/slapd/sets.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/sets.c,v retrieving revision 1.1.1.10 retrieving revision 1.13 diff -u -u -w -r1.1.1.10 -r1.13 --- servers/slapd/sets.c 5 Jan 2007 09:02:42 -0000 1.1.1.10 +++ servers/slapd/sets.c 13 Mar 2007 11:35:18 -0000 1.13 @@ -181,6 +181,12 @@ } } BER_BVZERO( &set[ last ] ); + + /* We have already copied, duplicated or freed + * the values in lset and rset, so don't free + * them again! + */ + op_flags |= SLAP_SET_LREFVAL|SLAP_SET_RREFVAL; } break; @@ -264,21 +270,14 @@ } done:; - if ( !( op_flags & SLAP_SET_LREFARR ) && lset != NULL ) { - if ( !( op_flags & SLAP_SET_LREFVAL )) - cp->set_op->o_tmpfree( lset->bv_val, cp->set_op->o_tmpmemctx ); - cp->set_op->o_tmpfree( lset, cp->set_op->o_tmpmemctx ); - } - - if ( !( op_flags & SLAP_SET_RREFARR ) && rset != NULL ) { - if ( !( op_flags & SLAP_SET_RREFVAL )) - cp->set_op->o_tmpfree( rset->bv_val, cp->set_op->o_tmpmemctx ); - cp->set_op->o_tmpfree( rset, cp->set_op->o_tmpmemctx ); - } + if ( lset != NULL ) + slap_set_dispose( cp, lset, SLAP_SET_LREF2REF( op_flags )); + if ( rset != NULL ) + slap_set_dispose( cp, rset, SLAP_SET_RREF2REF( op_flags )); return set; } static BerVarray set_chase( SLAP_SET_GATHER gatherer,

1 0

RE: (ITS#4864) -r option "redirects" to logfile, breaks replication
by Chris.Eubank＠gov.bc.ca 13 Mar '07

13 Mar '07

OK I understand if the -r switch (to slurpd, not slapd) redirects the output to a file for debugging purposes, this is just not apparent in the man pages. The man pages to not tell me that slurpd will be "redirecting" with the -r switch. It is just usual replication I was setting up originally. This is the variable I was using in an "openldaprc" file: # -r replication-log-file. Directory must be created. #SLURPD_REPL_LOG_FILE=/var/openldap-slurp/log When uncommenting this line, the result is that it does not open network connections to the replication slaves. _All_ data goes to the file, none to the slaves. This isn't documented correctly, it took me a long time to figure out why the replication was not happening. Chris -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: Sun, March 11, 2007 11:52 PM To: Eubank, Chris LCS:EX Cc: openldap-its(a)openldap.org Subject: Re: (ITS#4864) -r option "redirects" to logfile, breaks replication [please keep the ITS in CC] Eubank, Chris LCS:EX wrote: > Am running Solaris 10, and the version I stuck in the log. > > When I created an "openldaprc" and used the variable for the > replication log, What is the "variable for the replication log"? All one usually needs to do is define a replogfile in slapd.conf(5) > (which ends up obviously running the slurpd daemon with the -r > switch), Again: there's no need to use -r if replogfile is in slapd.conf(5); if there is no replogfile in slapd.conf(5), slapd(8) will not generate any log, so slurpd(8) will have nothing to do > it sent the replication data to the logfile and not to the replication > hosts being specified. Who sent the replication data to the logfile? slapd(8) is supposed to write replication data to the file specified in replogfile (sladp.conf(5)); slurpd(8) is supposed to read that file (whose existence and location is known by parsing slapd.conf(5)), copy the content it is able to process to its own replication log, which resides in slurpd's working directory (default or passed with -t) and is called slurpd.replog, send that content to the slaves, and remove the data that has been handled from slapd's replication log. This is how things are expected to work. As you may see, -r never comes into play; it's intended to be used to force slurpd processing of a different file, which may be required for special purposes. Do you have any special needs, or are you simply trying to set up usual replication? > Does that make more sense? See comments above. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 13 Mar '07

13 Mar '07

Le Lun 12 mars 2007 06:37, Pierangelo Masarati a écrit : > I don't see so much similarity: set_chase() is intended to use the > gatherer to fetch objects and extract a value from them, including > "closure" (recursion). Sublevel does not require fetching, and takes a > negative digit as extra argument, rather than an attribute type, so > you'd need to add an outer test before calling set_chase() anyway, > extend the interface of set_chase() to allow an AttributeDescription and > an integer, and so on, while you don't need any callback capability to > fetch an object or expand values or so. I'd keep it simple as it is now. OK. You'll find a new version here: ftp://ftp.openldap.org/incoming/raphael-ouazana-070313.patch It takes care of your notices. Regards, Raphael Ouazana.

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by vargok＠yahoo.com 13 Mar '07

13 Mar '07

>----- Original Message ---- >From: Pierangelo Masarati <ando(a)sys-net.it> >To: vargok(a)yahoo.com >Cc: openldap-its(a)openldap.org >Sent: Monday, March 12, 2007 4:52:04 PM >Subject: Re: (ITS#4868) Binary Attribute Patch(es) > > >> These address the use of Binary-valued attributes (#3113, #3386): >> >> For example, inetOrgPerson.userCertificate is usually transferred with the >> ";binary" directive. ";binary" is not handled by OpenLDAP/Back-SQL. > >Well, the solution you propose is not correct, since you are altering >schema data, which is supposed to be read-only. In any case, the point is: Yeah; I think the actual submission found the ";binary" and reset the reference to it, not actually doing anything to it. >- if we decide that back-sql should ignore tags, then the solution >consists in using the canonical name of the underlying AttributeType >when looking up data; > >- however, this would destroy the possibility to use different storages >for differently encoded data; for example, a column for "cn;lang-en" and >a column for "cn;lang-jp". I don't know how many users would prefer one >solution over another, but in any case either we find a solution that >preserves both capabilities or we choose one. I'd vote in favor of >ignoring ";binary" since it's obsolete and related to transport only, >but in favor of honoring language tags. Sounds great to me. I just want support for ";binary" both on storage and retrieval to be supported. I'll accept that it's obsolete -- I'll also put forth that a lot of things still use it (e.g. Lotus Domino v6). >> There remains an issue with selecting attributes using, e.g., >> "userCertificate;binary" -- nothing is returned. Someone with a better >> understanding of the attribute-processing method would be much more effective in >> terms of finding the correct place to remove the ";binary" from the >> "attribute-name." (i.e. "userCertificate;binary" is NOT the attribute-name; >> "userCertificate" is the attribute-name, ";binary" is a transport directive (see >> #3113). > >In fact, "userCertificate;binary" is the attribute description. The >attribute name is in ad_type->sat_cname. And, in fact, none of what I did appears to have been sufficient. I'm still looking at why selecting "userCertificate;binary" as part of an ldapsearch attribute-list doesn't pull the data. "userCertificate" does. The issue appears to be related to the ad_inlist verification on the search-supplied attribute -- "userCertificate;binary" doesn't resolve. If you know where I can look to figure this out, that would help. I've been through some areas and not found exactly where just yet. Thanks for your assistance. Kevin Vargo ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

1 0

Re: (ITS#4869) config creates base64 encoded rootdn
by hyc＠symas.com 13 Mar '07

13 Mar '07

dieter(a)dkluenter.de wrote: > Howard Chu <hyc(a)symas.com> writes: > >> What is the original rootdn? >> > cn=admin,o=avci,c=de > > -Dieter > I don't see anything like that here. You'll probably have to post your slapd.conf. Have you checked for extraneous white space in the original rootdn config? -- -- 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/

1 0

Re: (ITS#4869) config creates base64 encoded rootdn
by dieter＠dkluenter.de 13 Mar '07

13 Mar '07

Howard Chu <hyc(a)symas.com> writes: > What is the original rootdn? > cn=admin,o=avci,c=de -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

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