openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5289) test028 failed
by dieter＠dkluenter.de 18 Dec '07

18 Dec '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.223.222) test 028 fails with segmentation fault gdb output Reading symbols from /work/ldap-src/servers/slapd/back-ldap/.libs/back_ldap-2-devel.so.0...done. Loaded symbols for ../servers/slapd/back-ldap/.libs/back_ldap-2-devel.so.0 Reading symbols from /work/ldap-src/servers/slapd/overlays/.libs/rwm-2-devel.so.0...done. Loaded symbols for ../servers/slapd/overlays/.libs/rwm-2-devel.so.0 Core was generated by `/work/ldap-src/servers/slapd/.libs/lt-slapd -Ta -d 0 -f /work/ldap-src/tests/te'. Program terminated with signal 11, Segmentation fault. #0 0xb78926d4 in rwm_cf_gen (c=0xbff812dc) at rwm.c:1771 1771 (struct ldaprwmap *)on->on_bi.bi_private; (gdb) bt #0 0xb78926d4 in rwm_cf_gen (c=0xbff812dc) at rwm.c:1771 #1 0x0806eb67 in config_set_vals (Conf=0xb789a228, c=0xbff812dc) at config.c:314 #2 0x0806f049 in config_add_vals (Conf=0xb789a228, c=0xbff812dc) at config.c:383 #3 0x080f05be in over_db_config (be=0x8275840, fname=0x822e008 "/work/ldap-src/tests/testrun/slapadd.conf", lineno=98, argc=2, argv=0x8255648) at backover.c:151 #4 0x0807035f in read_config_file (fname=0x822e008 "/work/ldap-src/tests/testrun/slapadd.conf", depth=0, cf=0x0, cft=0x81c88a0) at config.c:792 #5 0x080667c4 in read_config (fname=0x822e008 "/work/ldap-src/tests/testrun/slapadd.conf", dir=0x0) at bconfig.c:3455 #6 0x080f5d18 in slap_tool_init (progname=0x818a920 "slapadd", tool=1, argc=10, argv=0xbff8ac74) at slapcommon.c:523 #7 0x080f3acc in slapadd (argc=10, argv=0xbff8ac74) at slapadd.c:73 #8 0x0805d013 in main (argc=10, argv=0xbff8ac74) at main.c:645 (gdb) (gdb) down 0xb78926d4 #8 0x0805d013 in main (argc=10, argv=0xbff8ac74) at main.c:645 645 rc = tools[i].func( argc, argv ); (gdb) down 0x0806eb67 #0 0xb78926d4 in rwm_cf_gen (c=0xbff812dc) at rwm.c:1771 1771 (struct ldaprwmap *)on->on_bi.bi_private; (gdb) -Dieter

1 0

(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

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