openldap-bugs December 2007

openldap-bugs@openldap.org

45 participants
166 discussions

(ITS#5288) DB_CONFIG.example URL wrong in comments
by ghenry＠OpenLDAP.org 18 Dec '07

18 Dec '07

Full_Name: Gavin Henry Version: All OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Should be: http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_co… Correcting.

1 0

Re: (ITS#5287) lanman hashes break compiling with GnuTLS
by hyc＠symas.com 17 Dec '07

17 Dec '07

quanah(a)zimbra.com wrote: > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245341> > > has a patch for compiling against gcrypt, don't know it it needs work. That's all well and good, but we can't incorporate 3rd party code unless the author specifically grants us permission, with the same IPR declarations as any other submission. -- -- 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#5287) lanman hashes break compiling with GnuTLS
by quanah＠zimbra.com 17 Dec '07

17 Dec '07

<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245341> has a patch for compiling against gcrypt, don't know it it needs work. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5287) lanman hashes break compiling with GnuTLS
by quanah＠zimbra.com 17 Dec '07

17 Dec '07

Full_Name: Quanah Gibson-Mount Version: 2.4.7 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.92.25.194) If one enables lanman hashes while building OpenLDAP, and using GnuTLS instead of OpenSSL, the build will fail as the lanman code has OpenSSL specific assumptions. --Quanah

1 0

(ITS#5286) NULL value in sets
by raphael.ouazana＠linagora.com 17 Dec '07

17 Dec '07

Full_Name: Raphael Ouazana Version: HEAD, RE24, RE23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (164.2.255.244) Hi, I repost this here as I think the discussion was lost in a closed ITS (#4860). The two solutions (other operation or previous behavior) would be fine for us, but I have not really time to make a patch for the moment. Le Sam 10 novembre 2007 16:37, ando(a)sys-net.it a .crit : >> Below I represent sets in {element1, element2} notation, to describe the >> current behaviour (in HEAD) for slap_set_join on the '+' operation: >> - {"One", "Two"} + {"Three", "Four"} ==> {"OneThree", "OneFour", >> "TwoThree", "TwoFour"} >> - {"One", "Two"} + {""} ==> {"One", "Two"} >> - {"One", "Two"} + {NULL} ==> {"One", "Two"} > > Although sets lack a specification, I think this behavior is desirable > in many cases: adding NULL is equivalent to adding EMPTY (""). The problem is that {NULL} is equivalent to NULL, ie the empty set. >> Consider the following set: >> set="[ldap:///] + [ldap:///<searchbase>??<scope>?<filter1>] + >> [??<scope>?<filter2>]" >> >> Assuming [ldap:///<searchbase>??<scope>?<filter1>] returns a DN, this >> works. However, if [ldap:///<searchbase>??<scope>?<filter1>] returns no >> entries, this value is NULL. Therefore, the rest of the set becomes: >> "[ldap:///] + {NULL} + [??<scope>?<filter2>]" >> ...which is handed to the '+' operation in slap_set_join, to become: >> [ldap:///??<scope>?<filter2>] >> ...which obviously isn't valid. > > Well, it is valid: it's an URI with an EMPTY DN. In terms of LDAP, yes, but it can cause security issues here, as the EMPTY DN is at a higher level that any one which would have been returned by a normal result. >> The attached patch changes the last case of the current behaviour for >> slap_set_join on the '+' operation. This was already the behaviour >> before version 1.24.2.6 Thu Sep 13 20:43:29 2007 UTC: >> - {"One", "Two"} + {NULL} ==> {NULL} > > This is different from the above behavior, although it makes sense on > its own. Probably we need two different addition operators: one > inclusive (NULL is equivalent to "") and one exclusive (NULL nullifies > the concatenation). > > Comments? No problem in having the two operators. I just think the normal behavior is to return NULL, has in term of sets the cartesian product A x NULL returns NULL, not A. Regards, Raphael Ouazana.

1 0

Re: (ITS#5274) add search to online docs
by h.b.furuseth＠usit.uio.no 16 Dec '07

16 Dec '07

kurt(a)OpenLDAP.org writes: > Right, not everyone knows how to make the fullest of the tools > available to them, or even know what tools are available to them. I > don't see providing yet another tool as a solution to these problems. I thought I was suggesting (an interface to) an existing tool - and teaching a way to use that as an added bonus. A matter of semantics I guess. -- Regards, Hallvard

1 0

Re: (ITS#5274) add search to online docs
by kurt＠OpenLDAP.org 16 Dec '07

16 Dec '07

On Dec 13, 2007, at 4:47 AM, Hallvard B Furuseth wrote: > kurt(a)OpenLDAP.org writes: >> There are lots of existing ways of searching an admin guide. >> >> First, most web search engines can be told to localize their search >> to >> a set of pages. For instance: >> http://www.google.com/search?q=site:www.openldap.org/doc/ >> admin24+rwm > > Not everyone knows how to do that. Right, not everyone knows how to make the fullest of the tools available to them, or even know what tools are available to them. I don't see providing yet another tool as a solution to these problems. -- Kurt

1 0

Re: (ITS#5285) password policy checks userPassword hash even without policies
by hyc＠symas.com 15 Dec '07

15 Dec '07

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.3, 2.4, head, etc > OS: all > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (67.115.65.234) > > > When receiving a new userPassword, slapo-ppolicy checks to see if that password > matches the hash already present in userPassword, and disallows it if this is > the case. > > This is a sensible default for most circumstances, as otherwise the user could > reset their age counters by using the same password. > > Unfortunately, it also blocks arguably-legitimate password changes; e.g. when > migration to SSHA from CRYPT where the first 8 chars of the new password match > the old. > > This patch changes this userPassword-has-changed check to only apply if there is > a password policy defined which requires it; in particular, any of pwdInHistory, > pwdMinAge, pwdMaxAge, pwdCheckQuality, or pwdMustChange must apply for this > check to be enforced. Rereading draft-behera, it says 5.2.4 pwdInHistory This attribute specifies the maximum number of used passwords stored in the pwdHistory attribute. If this attribute is not present, or if the value is 0, used passwords are not stored in the pwdHistory attribute and thus may be reused. As such the test can be simplified. Committing to HEAD. -- -- 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

ITS#5145 Automatic groups overlay
by hyc＠symas.com 15 Dec '07

15 Dec '07

I did some minor cleanup and committed this. I think there may be other changes that could be made, to take advantage of sorted values and so cut down on the overhead of managing groups with large numbers of members. -- -- 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#3515 ACLs enhancements
by ando＠sys-net.it 15 Dec '07

15 Dec '07

hyc(a)symas.com wrote: > This looks mostly like ACI to me, with some special inheritance rules. Is it > still relevant? AFAIR that was a custom ACL checking development that I found interesting from a technical point of view but (I might be wrong) of limited usefulness outside the scope it was developed for. In the meanwhile, and probably triggered by that posting, I added several ways of customizing access checking: via overlays, using dynacl (that was added earlier, for the purpose of isolating ACIs, but it could have served the same purpose). In this sense, I don't think this contribution can be of any use right now; it coulr be turned into a dynacl for custom use by the posters, or by anyone who find it useful. 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

← Newer
1
2
3
4
5
6
7
8
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2007