openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5266) "authorization failure: invalid authcid" during SASL auto_transition
by dwhite＠olp.net 23 Dec '07

23 Dec '07

Howard Chu wrote: > This is a bug in Cyrus SASL; the setpass function is zeroing out the > connection state when it should be leaving it intact. The attached patch > will fix the problem. (Verified using saslauthd and most of the above > components.) Thanks Howard. This patch works for me. - Dan

1 0

Re: (ITS#5266) "authorization failure: invalid authcid" during SASL auto_transition
by hyc＠symas.com 23 Dec '07

23 Dec '07

This is a multi-part message in MIME format. --------------040002000303080307090101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit dwhite(a)olp.net wrote: > Full_Name: Dan White > Version: 2.3.39 > OS: Linux > URL: http://support.olp.net/ldap/log2.txt > Submission from: (NULL) (65.161.252.42) > > > If I enable SASL auto_transition, I receive the following error during > authentication: > > SASL(-14): authorization failure: invalid authcid > > I'm using openldap version 2.3.39 for both slapd and my ldap utils > (ldapsearch). > I'm using the bdb backend. > > I'm also using Debian Etch with the following versions of software: > > Cyrus SASL 2.1.22(.dfsg1-8) > libdb 4.2.52(+dfsg-2) > libc6 2.3.6(.ds1-13etch2) > PAM 0.79(-4) > pam_ldap 184(-2) > > I'm using saslauthd's PAM backend, and in turn using pam_ldap for > authentication, although I don't believe the problem is related to the > saslauthd/pam configuration. > > Here's the client side output from the attempted bind: > > hiro:~# ldapsearch -LLL -Y PLAIN -U abrown(a)olp.net uid=n/a > SASL/PLAIN authentication started > Please enter your password: > ldap_sasl_interactive_bind_s: Insufficient access (50) > additional info: SASL(-14): authorization failure: invalid authcid > > If I turn off auto_transition, it works: > > hiro:~# ldapsearch -LLL -Y PLAIN -U abrown(a)olp.net uid=n/a > SASL/PLAIN authentication started > Please enter your password: > SASL username: abrown(a)olp.net > SASL SSF: 0 > hiro:~# > > My slapd.conf SASL service file looks like: > > hiro:~# cat /usr/lib/sasl2/slapd.conf > keytab: /etc/krb5.keytab-ldap > pwcheck_method: saslauthd > auxprop_plugin: slapd > auto_transition: yes > log_level: 7 > > And the server log (loglevel -1) is located at: > > http://support.olp.net/ldap/log2.txt > > The error appears to be occurring while transitioning the password to the > auxprop store, in the slap_sasl_authorize function: > > /* Skip SLAP_SASL_PROP_CONN */ > prop_getnames( props, slap_propnames+1, auxvals ); > > /* Should not happen */ > if ( !auxvals[0].values ) { > sasl_seterror( sconn, 0, "invalid authcid" ); > return SASL_NOAUTHZ; > } > > What I'm expecting to happen during the bind, is to have SASL overwrite my > userPassword and cmusaslsecretOTP attributes, via the slapd auxprop plugin. > > I have a lot of passwords in crypted form (which PAM authenticates), and I'm > aiming towards a clear-text password store by using this functionality. This is a bug in Cyrus SASL; the setpass function is zeroing out the connection state when it should be leaving it intact. The attached patch will fix the problem. (Verified using saslauthd and most of the above components.) -- -- 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/ --------------040002000303080307090101 Content-Type: text/plain; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dif.txt" Index: server.c =================================================================== RCS file: /cvs/src/sasl/lib/server.c,v retrieving revision 1.147 diff -u -r1.147 server.c --- server.c 3 Jul 2006 14:43:16 -0000 1.147 +++ server.c 23 Dec 2007 01:52:25 -0000 @@ -129,6 +129,7 @@ int result = SASL_OK, tmpresult; sasl_server_conn_t *s_conn = (sasl_server_conn_t *) conn; const char *password_request[] = { SASL_AUX_PASSWORD_PROP, NULL }; + struct propctx *propctx = NULL; sasl_server_userdb_setpass_t *setpass_cb = NULL; void *context = NULL; int tried_setpass = 0; @@ -172,14 +173,18 @@ pass = NULL; passlen = 0; } - - result = prop_request(s_conn->sparams->propctx, password_request); + + propctx = prop_new(0); + if ( !propctx ) { + RETURN(conn, SASL_NOMEM); + } + result = prop_request(propctx, password_request); if (result == SASL_OK) { - result = prop_set(s_conn->sparams->propctx, SASL_AUX_PASSWORD_PROP, + result = prop_set(propctx, SASL_AUX_PASSWORD_PROP, pass, passlen); } if (result == SASL_OK) { - result = sasl_auxprop_store(conn, s_conn->sparams->propctx, user); + result = sasl_auxprop_store(conn, propctx, user); } if (result != SASL_OK) { _sasl_log(conn, SASL_LOG_ERR, @@ -189,6 +194,7 @@ _sasl_log(conn, SASL_LOG_NOTE, "setpass succeeded for %s", user); } + prop_dispose(&propctx); } /* We want to preserve the current value of result, so we use tmpresult below */ --------------040002000303080307090101--

1 0

(ITS#5298) multi-step SASL binds are unsafe
by hyc＠OpenLDAP.org 23 Dec '07

23 Dec '07

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc While testing the fix for ITS#5259 I realized that the SASL DN is being allocated on the Operation's slab, but may be referenced by a different Operation if a Bind requires multiple steps. For OTP there are 2 operations - the identities are canonicalized and saved in step 1, when the challenge is generated for the client, and then the OTP is sent and validated in a subsequent operation. (DIGEST-MD5 also occurs in 2 steps, but no usernames are provided in step 1, all canonicalization and validation occurs in step 2 so it's all within a single operation.) To avoid this problem, the DNs probably should be dup'd using the SASL allocator, so they can be cleaned up automatically when SASL completes.

1 0

Re: (ITS#5259) SIGSEGV in slap_auxprop_store during SASL/OTP bind
by hyc＠symas.com 22 Dec '07

22 Dec '07

hyc(a)symas.com wrote: > dwhite(a)olp.net wrote: >> Full_Name: Dan White >> Version: 2.3.39 >> OS: Linux >> URL: http://support.olp.net/ldap/log.txt >> Submission from: (NULL) (65.161.252.42) > > Nice bit of debugging there. This could be a bit tricky because the slapd > auxprop code assumes it's always executing on behalf of an LDAP operation > (usually a Bind request). In this case, there is no active request; it's the > cleanup action on a closed connection, and most of the state that slapd needed > has already been torn down. It may take some restructuring to allow this to > work, we never expected sasl_dispose() to be anything other than a pure > destructor. Fixed in CVS 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

Re: (ITS#5295) option to allow slapd bind to any available port
by h.b.furuseth＠usit.uio.no 22 Dec '07

22 Dec '07

If the clients and servers are on the same machine, the servers could listen to 'ldapi://<URL-escaped unique socket path>' instead of to 'ldap://host:unique port/'. E.g. the users could use 'ldapi://<escape $HOME/ldapi>' or '%2Ftmp%2Fldapi%2F<escape $USER>'. However you'd need to upgrade OpenLDAP first, due to a security issue in "ldapi://" implementations before 2.3.35. (In particular, ensure your users won't use ldapi: with pre-2.3.35 clients against someone else's server.) -- Regards, Hallvard

1 0

Re: (ITS#5295) option to allow slapd bind to any available port
by hyc＠symas.com 22 Dec '07

22 Dec '07

chitrav(a)us.ibm.com wrote: > Full_Name: Chitra Vemkatramani > Version: 2.3.27 > OS: Redhat > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (162.83.178.28) > For a project that we are using openldap in, we would like to allow multiple > users to start up ldap servers on the same machine. We would like an option on > the slapd command line asking the server to pick any available port to bind to. > We can then do netstat, find the port and pass that on to the client. Here is > the patch we put in, to allow us to specify -1 for the port, so that the server > will pick any available port. Can you please consider adding this to the server > options ? Hacking the server code to support your peculiar disorganization doesn't seem like a good idea. Just have your users agree on the port numbers they'll each use. -- -- 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#5296) Search netgroup by triple don't report existing entry
by hyc＠symas.com 22 Dec '07

22 Dec '07

rochette_jean-louis(a)emc.com wrote: > Full_Name: Jean-Louis ROCHETTE > Version: 2.3.39 > OS: Linux Fedora > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (152.62.109.163) > > > Brief description of the problem > -------------------------------- > Lookup of a netgroup by triple doesn't work in last stable release slapd 2.3.39, > though it worked well with slapd 2.3.27. > This looks like a regression in slapd. > This should be easy to reproduce. > The problem was first noticed in slapd 2.3.30. > The lookup by triple succeeds with a iPlanet server. There are no matching rules defined for nisNetgroupTriple in nis.schema. There have never been, since RFC2307 doesn't define any. As such, filtering by nisNetgroupTriple is totally undefined. Any server that returns your expected result using the search filter you provide is broken. There is no regression here. Your distro vendor may have hacked their own schema files to provide one, that's an issue for you to discuss with your vendor. This ITS will be closed. -- -- 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#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 22 Dec '07

22 Dec '07

Andrew Bartlett wrote: > On Fri, 2007-12-21 at 19:55 -0800, Howard Chu wrote: >> Fixed in CVS HEAD. Happy New Year! ;) > > While I still have other issues (probably in Samba), we are past this > one. Thankyou very much! Great, thanks for the confirmation. > > Andrew Bartlett > -- -- 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#4982) link libldap_r explicitly with the threading libraries
by quanah＠zimbra.com 21 Dec '07

21 Dec '07

--On December 21, 2007 8:17:40 PM +0000 rra(a)stanford.edu wrote: > Is there any further thoughts on this ITS? It's still open and it doesn't > look like the patch has been applied, but it seemed like we'd reached a > conclusion that it was the right thing to do. This is now fixed in HEAD and 2.4. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#4982) link libldap_r explicitly with the threading libraries
by rra＠stanford.edu 21 Dec '07

21 Dec '07

Is there any further thoughts on this ITS? It's still open and it doesn't look like the patch has been applied, but it seemed like we'd reached a conclusion that it was the right thing to do. To recap, the problem is that libldap_r isn't being linked with the threading libraries, which means that when the linker builds the shared library, it doesn't have symbol versioning information available for the pthread functions and creates unversioned references. If the current ABI of the functions ever changes (as has happened in the past with glibc on Alpha), segfaults and other unpleasantness result. The patch adds the threading libraries to the link command for libldap_r so that the linker has the symbol versioning information available and can bind the pthread functions to the appropriate symbol versions in glibc, allowing the library to keep working using glibc's backwards compatibility support even if the current ABI changes again. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

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