openldap-bugs

openldap-bugs@openldap.org

1 participants
20995 discussions

Re: (ITS#4997) lmpasswd support using gcrypt
by kurt＠OpenLDAP.org 02 Jun '07

02 Jun '07

On Jun 2, 2007, at 6:31 AM, rra(a)stanford.edu wrote: > Full_Name: Russ Allbery > Version: 2.4 (HEAD) > OS: Debian > URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245341 > Submission from: (NULL) (171.66.157.14) > > > Now that 2.4 has native GnuTLS support, the patch that's been > sitting around in > Debian bug #245341 becomes potentially interesting (see the > associated URL). > This is a request to support LAN Manager password hashes when > OpenLDAP is built > with GnuTLS instead of OpenSSL, thus requiring using libgcrypt to > do the DES > work instead of OpenSSL's DES library. > > The patch in that bug almost certainly isn't okay in its current form, Note that 3rd party contributions are generally not acceptable (for IPR reasons). That is, we generally require the author(s) of the patch to contribute the patch. If you think this patch is useful, you might suggest to its authors that they contribute it to the Project. In doing so, it's good to provide a link to our contributing guidelines, http://www.openldap.org/devel/ contributing.html. > but I > wanted to get the ITS filed for this feature request so that > there's a record in > the database and just in case someone else feels inspired to bring > the patch up > to date and clean it up. (Unlikely, I know.) Otherwise, I will > probably clean > this patch up for further submission at some point near the 2.4 > release (on > which side of it, I'm not sure). Without involvement from the authors of this patch, it's better to simply rewrite the feature from scratch. -- Kurt

1 0

Re: (ITS#4951) [contrib] RADIUS password module fixes
by ando＠sys-net.it 02 Jun '07

02 Jun '07

richton(a)nbcs.rutgers.edu wrote: Committed. Cheers, 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

Re: (ITS#4989) Quirk in Dynlist overlay configuration
by ando＠sys-net.it 02 Jun '07

02 Jun '07

marg(a)rz.tu-clausthal.de wrote: > I found a behaviour issue with the dynlist overlay configuration: > > I tried the following configuration: > > overlay dynlist > dynlist-attrset posixGroup memberURL > dynlist-attrset groupOfURLs memberURL owner The reason of that check is that the same attribute "memberURL" could otherwise be used by both group classes to expand. > > but slaptest complains about it - and the slapd doesn't start with it: > > @(#) $OpenLDAP: slapd 2.3.34[...] > /usr/local/etc/openldap/slapd.conf: line 91: "dynlist-attrset <oc> > <URL-ad> [<member-ad>]": URL attributeDescription "memberURL" already > mapped. > slapd stopped. > > When I use multiple "overlay dynlist"-entries like: > > overlay dynlist > dynlist-attrset posixGroup memberURL > overlay dynlist > dynlist-attrset groupOfURLs memberURL owner > > it works as expected, but there is a warning: > > overlay_config(): warning, overlay "dynlist" already in list > > PS: Although the new Version 2.3.35 isn't available via FreeBSD Ports > yet, I don't think that it would change anything, because the source > file of the dynlist-overlay doesn't seem to have changed in any part > that matters to this issue. I think the documentation describes the intended behavior, but configuration parsing is not (no longer?) in agreement with the documentation. I think the real issue is that the behavior is no longer consistent for compares and searches: - for searches, only the first group that matches the entry's objectClass will be expanded - for compares, all groups that match will be expanded until a match is found I'm reworking the configuration test to be consistent with the documentation, and the code to be self-consistent: now all groups matching the entry are expanded. So now a configuration like dynlist-attrset groupOfURLs memberURL dynlist-attrset groupOfURLs memberURL member will simultaneously merge all attributes listed in a "memberURL", and add the expanded entries' DN as "member". However, I believe something like dynlist-attrset posixGroup memberURL dynlist-attrset groupOfURLs memberURL should still be forbiden, otherwise the same "memberURL" would expand twice. This, strictly speaking, is not an issue, as duplicates would simply be discarded, but it would cause unnecessary overhead. Right now, I have decided to turn this check into a config-time warning. Please test and report. 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

Re: (ITS#4994) Clarify -y option in man pages
by ando＠sys-net.it 02 Jun '07

02 Jun '07

rra(a)stanford.edu wrote: > A Debian user was confused by the -y option and its inclusion of whitespace in > the password. The current man page text does explain this, but it doesn't make > a point of it, and I think a bit more explanation would be useful. Here's a > patch for the ldapcompare.1 man page; if you think this is a good idea, similar > changes could be made to all the other command-line utilities that take the -y > option. I have committed a different clarification that provides a hint to a portable manner to generate appropriate password files. Please check and improve; afterwards I'll apply it to other command line tools man pages. 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

(ITS#4997) lmpasswd support using gcrypt
by rra＠stanford.edu 02 Jun '07

02 Jun '07

Full_Name: Russ Allbery Version: 2.4 (HEAD) OS: Debian URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245341 Submission from: (NULL) (171.66.157.14) Now that 2.4 has native GnuTLS support, the patch that's been sitting around in Debian bug #245341 becomes potentially interesting (see the associated URL). This is a request to support LAN Manager password hashes when OpenLDAP is built with GnuTLS instead of OpenSSL, thus requiring using libgcrypt to do the DES work instead of OpenSSL's DES library. The patch in that bug almost certainly isn't okay in its current form, but I wanted to get the ITS filed for this feature request so that there's a record in the database and just in case someone else feels inspired to bring the patch up to date and clean it up. (Unlikely, I know.) Otherwise, I will probably clean this patch up for further submission at some point near the 2.4 release (on which side of it, I'm not sure).

1 0

Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by kurt＠OpenLDAP.org 02 Jun '07

02 Jun '07

On Jun 2, 2007, at 5:31 AM, rra(a)stanford.edu wrote: > Full_Name: Russ Allbery > Version: 2.3.35 > OS: Debian > URL: > Submission from: (NULL) (171.66.157.14) > > > A user of the Debian OpenLDAP package requested support in the > command-line > utilities for using SRV entries to locate the local LDAP server. My > understanding of the suggestion is that if one didn't specify -h or > -H, a SRV > record lookup would be tried before falling back to localhost. > (You may not > want to change the default behavior, though, and add another switch.) One could use DNS SRV on the domain provided by -H, or by ldap.conf (5), and use it present, with (likely best) or without an option to enable the behavior. One could also use DNS SRV on the domain associated with the baseObject/target DN with an option to enable this behavior. That is, ldapsearch -b "dc=example,dc=org" would cause a DNS SRV lookup on example.org. This is what the DNSSRV backend does. Not sure adding to the command line tools would be especially useful. That is, I don't think DNS SRV fits well in the common use pattern of command line tools. But someone implements this behind an option, it shouldn't do any harm. Lastly I note that the domain to use DNS SRV should come from the user (or application entity), not the local host. Using the local resolver configuration is a really bad idea. -- Kurt > > For the full suggestion, see: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221173 > > It looks like much of the necessary code is already there in > libldap, and > looking at the libldap code, you could also intuit the correct > server based on > any search base provided. > >

1 0

(ITS#4996) Use SRV records to locate local server for command-line clients
by rra＠stanford.edu 02 Jun '07

02 Jun '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.66.157.14) A user of the Debian OpenLDAP package requested support in the command-line utilities for using SRV entries to locate the local LDAP server. My understanding of the suggestion is that if one didn't specify -h or -H, a SRV record lookup would be tried before falling back to localhost. (You may not want to change the default behavior, though, and add another switch.) For the full suggestion, see: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221173 It looks like much of the necessary code is already there in libldap, and looking at the libldap code, you could also intuit the correct server based on any search base provided.

1 0

slapd with wrong url causes "Error detected by libpthread: Invalid mutex"
by Jean-Luc Wasmer 02 Jun '07

02 Jun '07

Hi, When slapd is started with an invalid url, it looks like it's trying to destroy an uninitialized mutex: Program received signal SIGABRT, Aborted. 0xbb87dfff in kill () from /usr/lib/libc.so.12 (gdb) backtrace #0 0xbb87dfff in kill () from /usr/lib/libc.so.12 #1 0xbb94adb3 in pthread__errorfunc () from /usr/lib/libpthread.so.0 #2 0xbb9491fe in pthread_mutex_destroy () from /usr/lib/libpthread.so.0 #3 0xbbbbd1eb in ldap_pvt_thread_mutex_destroy () from /usr/pkg/lib/libldap_r-2.3.so.0 #4 0x0805a756 in ?? () #5 0x0819e4fc in __ps_strings () #6 0x00000002 in ?? () #7 0xbfbfe8e8 in ?? () #8 0x0805a713 in ?? () #9 0x00000286 in ?? () #10 0x00000001 in ?? () #11 0xbfbfe958 in ?? () #12 0x0804e2c1 in ?? () #13 0xbfa00000 in ?? () #14 0xbb92cdd0 in tzname () from /usr/lib/libc.so.12 #15 0x00000002 in ?? () #16 0x00000000 in ?? () This was triggered by calling slapd with an invalid URLlist argument: -h 'ldap://127.0.0.1 ldaps://<external ip>' with no interfaces on the system configured with <external ip>

4 6

(ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by rra＠stanford.edu 02 Jun '07

02 Jun '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.66.157.14) While investigating another issue with back_perl, I tried to use the SampleLDAP.pm module that comes with the OpenLDAP source. I added the following to my slapd.conf: moduleload back_perl # ... database perl suffix "o=AnyOrg,c=US" perlModulePath /home/eagle/SampleLDAP.pm perlModule SampleLDAP The result of slapd -d 1 is: ... WARNING: No dynamic config support for database perl. config_build_entry: "olcDatabase={2}perl" backend_startup_one: starting "dc=Stanford,dc=EDU" bdb_db_open: unclean shutdown detected; attempting recovery. bdb_db_open: dbenv_open(/var/lib/ldap) backend_startup_one: starting "o=AnyOrg,c=US" Can't call method "init" on an undefined value. I suspect the code in perl_back_db_open where it does: dSP; ENTER; SAVETMPS; PUSHMARK(sp); XPUSHs( perl_back->pb_obj_ref ); PUTBACK; #ifdef PERL_IS_5_6 count = call_method("init", G_SCALAR); #else count = perl_call_method("init", G_SCALAR); #endif The error message is consistent with perl_back->pb_obj_ref being an undefined value. Why it's undefined, though, I'm not sure. See also http://www.openldap.org/lists/openldap-software/200705/msg00126.html

1 0

(ITS#4994) Clarify -y option in man pages
by rra＠stanford.edu 01 Jun '07

01 Jun '07

Full_Name: Russ Allbery Version: 2.3.35 OS: Debian URL: Submission from: (NULL) (171.64.19.147) A Debian user was confused by the -y option and its inclusion of whitespace in the password. The current man page text does explain this, but it doesn't make a point of it, and I think a bit more explanation would be useful. Here's a patch for the ldapcompare.1 man page; if you think this is a good idea, similar changes could be made to all the other command-line utilities that take the -y option. --- ldapcompare.1 (revision 805) +++ ldapcompare.1 (working copy) @@ -106,8 +106,12 @@ Use \fIpasswd\fP as the password for simple authentication. .TP .BI \-y \ passwdfile -Use complete contents of \fIpasswdfile\fP as the password for -simple authentication. +Use complete contents of \fIpasswdfile\fP, including any leading or +trailing whitespace and any final newlines, as the password for +simple authentication. If the password does not contain a newline, +be careful when creating this file. Many editors and commands like +\fBecho\fP will add a trailing newline, which will then be taken as part +of the password. .TP .BI \-H \ ldapuri Specify URI(s) referring to the ldap server(s); only the protocol/host/port

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