openldap-bugs March 2011

openldap-bugs@openldap.org

47 participants
119 discussions

Lib is not relocatable although --with-pic was used. Bug?
by Kristof Van Damme 02 Mar '11

02 Mar '11

Hi all, Platform is Sun Solaris x64 10 u8. Compiler used is Sun Studio 12u1. Version is openldap-2.4.23-stable-20100719. Configure was done with CFLAGS='-xO3 -KPIC -m64 -xtarget=generic' and CC="/usr/bin/cc" $ ./configure --prefix=/opt/app/damp64 --with-pic --with-tls=openssl Compilation in 64-bit (-m64) of libldap was succesfull and installed in /opt/app/damp64/lib. If I create a simple main.c file: int main(){ return 0; } I compile (also 64-bit) and link this main.c file with libldap as a test. $ /usr/bin/cc -o conftest -xO4 -m64 -KPIC -xtarget=generic -s -I/opt/app/damp64/include -L/opt/app/damp64/lib -R/opt/app/damp64/lib main.c -lldap When I try to run this exec linked to the newly build library libldap.so I get the following error: # ./conftest ld.so.1: conftest: fatal: relocation error: R_AMD64_32: file /opt/app/damp64/lib/libldap-2.4.so.2: symbol (unknown): value 0xfffffd7fff2542f0 does not fit This is a relocation error from the linker on the libldap. But I compiled everything with -KPIC (position independent code) and gave the --with-pic option to configure. This is a serious issue, as I cannot link the library to anything else and thus it is unusable. Can I file a bug report? If I have a look in the libldap shared object, I can see .text relocations... # elfdump -d /opt/app/damp64/lib/libldap-2.4.so.2 | fgrep TEXTREL [18] TEXTREL 0 [27] FLAGS 0x4 [ TEXTREL ] Kind regards, Kristof Van Damme.

1 1

Re: (ITS#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> Full_Name: plop > Version: > OS: ubuntu last release > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.206.236.129) > > > This is what I got on a CLI: > > ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b > "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin > ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: > tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' > failed. > Abandon > > > > $ ldapsearch -V > ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 (Nov 19 2010 17:41:00) $ > buildd@allspice:/build/buildd/openldap-2.4.23/debian/build/clients/tools > (LDAP library: OpenLDAP 20423) > ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Fixed in HEAD. Tools will refuse to start if incompatible password options are passed. I chose this solution since handling of credentials is security-related, and one would not want credentials to be handled incorrectly by a misused client. Please test. p.

1 0

Re: (ITS#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> When idassert-bind is configured to use SASL bind, an "authcID" needs to >> be >> provided, while the "binddn" is not needed. However, if a "binddn" is >> not >> provided as well, in some cases the proxiedAuthz control may be used >> incorrectly. The need to configure the "binddn" is not documented, so >> this ITS >> is minimally addressed by documenting this requirement. > > I tripped over this change while investigating #6711. Adding this > requirement > is certainly not the right solution; SASL Binds ordinarily don't require a > BindDN and requiring it here just makes things confusing. I understand the fix I'm suggesting can sound counter-intuitive. The documentation should clearly indicate that the binddn in case of SASL is for *local* and *internal* issues, and will not be part of the authentication process. As an alternative, lc_bound_ndn could receive a dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive the actual identity from the remote server using the authid control along with the bind or performing a whoami extop later, as already implemented). p. > Also with the fixes that I made for #6711 I don't believe the issue exists > any > more. Please describe the conditions where the problem occurs. > >> If the "binddn" is provided, everything works as expected, with the only >> minor >> issue that the DN of the user as it is known to back-meta may not match >> the >> actual identity the "authcID" assumed on the remote server. The "right" >> way to >> address this problem consists in performing a "WhoAmI" (RFC 4532) right >> after >> the bind, or better use a "authorization identity control" (RFC 3829) >> along with >> the bind operation. Both approaches should be implemented, but they >> should not >> be used unless explicitly requested. > > -- > -- Howard Chu > CTO, 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#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> When idassert-bind is configured to use SASL bind, an "authcID" needs to >> be >> provided, while the "binddn" is not needed. However, if a "binddn" is >> not >> provided as well, in some cases the proxiedAuthz control may be used >> incorrectly. The need to configure the "binddn" is not documented, so >> this ITS >> is minimally addressed by documenting this requirement. > > I tripped over this change while investigating #6711. Adding this > requirement > is certainly not the right solution; SASL Binds ordinarily don't require a > BindDN and requiring it here just makes things confusing. > > Also with the fixes that I made for #6711 I don't believe the issue exists > any > more. Please describe the conditions where the problem occurs. At the time I looked at this issue, there were places in the code where after an idassert-bind the lc_bound_ndn would receive a copy of idassert's authcDN. In case of SASL, this is empty/null; then back-ldap (and meta) would fail from recognizing the connection as successfully bound. I understand there are better solutions; for example, ldapconn_t could have a "bound" flag, or so. I understand that code may need some reworking, but I can't work at that now, sorry. p. >> If the "binddn" is provided, everything works as expected, with the only >> minor >> issue that the DN of the user as it is known to back-meta may not match >> the >> actual identity the "authcID" assumed on the remote server. The "right" >> way to >> address this problem consists in performing a "WhoAmI" (RFC 4532) right >> after >> the bind, or better use a "authorization identity control" (RFC 3829) >> along with >> the bind operation. Both approaches should be implemented, but they >> should not >> be used unless explicitly requested. > > -- > -- Howard Chu > CTO, 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#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

1 0

Re: (ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by ghenry＠OpenLDAP.org 02 Mar '11

02 Mar '11

----- Original Message ----- > --GRPZ8SYKNexpdSJ7 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Fri, Feb 18, 2011 at 02:56:16PM -0800, Howard Chu wrote: > > > re: TLS Authentication Identity Format > > > > Strictly speaking, the order of components is not changed at all. > > The sequence of RDNs in the DN is what it is; just that the > > convention for *displaying* it is ass-backwards in LDAP. I'm afraid > > the wording here will confuse people into thinking that the > > *semantics* of the DN are changed, when it's only a display issue. > > Good point. Updated wording attached. > > Andrew Thanks for all this Andrew, much appreciated! -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6849) ldapsearch assertion failed
by gnuround＠gmail.com 01 Mar '11

01 Mar '11

Full_Name: plop Version: OS: ubuntu last release URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.206.236.129) This is what I got on a CLI: ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' failed. Abandon $ ldapsearch -V ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 (Nov 19 2010 17:41:00) $ buildd@allspice:/build/buildd/openldap-2.4.23/debian/build/clients/tools (LDAP library: OpenLDAP 20423) ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) $ apt-cache show ldap-utils Package: ldap-utils Priority: optional Section: net Installed-Size: 768 Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Architecture: amd64 Source: openldap Version: 2.4.23-0ubuntu3 Replaces: openldap-utils, openldapd, slapd (<< 2.2.23-0.pre6) Provides: ldap-client, openldap-utils Depends: libc6 (>= 2.4), libgnutls26 (>= 2.7.14-0), libgssapi-krb5-2 (>= 1.6.dfsg.2), libldap-2.4-2 (= 2.4.23-0ubuntu3), libsasl2-2 Recommends: libsasl2-modules Conflicts: ldap-client, openldap-utils, umich-ldap-utils Filename: pool/main/o/openldap/ldap-utils_2.4.23-0ubuntu3_amd64.deb Size: 343860 MD5sum: 5c7834714c933288181d660e34c0b3d6 SHA1: a18afe09abd61bcf6a722135bb82c308104fa15c SHA256: 1b2d43b4dc82843047d6930f8e1f4145a8cf40f9435d9d58389c7acd1a4d4b04 Description-fr: Utilitaires OpenLDAP

1 0

Re: (ITS#6848) wait timeout for slapd startup
by hyc＠symas.com 01 Mar '11

01 Mar '11

andrew.findlay(a)skills-1st.co.uk wrote: > On Mon, Feb 28, 2011 at 09:36:01PM +0000, quanah(a)OpenLDAP.org wrote: > >> When LDAP is used as a dependency for other software during the init process (as >> a kerberos backend, for example), the fact that slapd exits with success prior >> to it being ready to accept connections can cause problems for the later >> services that depend on it. It would be useful to have an (optional) flag "-w >> <seconds>" that if provided, would have slapd wait up until<seconds> amount of >> time has passed for the daemon to fully initialize. > > Some distros already deal with this in other ways - e.g. OpenSuSE waits > until an ldapsearch on the null DN succeeds. This is done in the init.d > script. This is still by far the best solution. The current patch simply shifts the slapd parent process' exit a little later, to after the databases are started up. The listener thread still has not yet been created by this time. On a lightly loaded system the time till that is running should be trivial, but on a heavily loaded system who knows. > One advantage of putting explicit support into OpenLDAP for this is > that it may be possible to have an option to delay starting the > listners on a replication consumer until a full refresh has been done > from the master (this would need a timeout option too). There are > obvious deadlock issues in multi-master configs, but admins would at > least have the option of using this on pure consumers. We've discussed this option many times in the past but it generally seems to come out being more bad than good. Also it implies an expectation for consistency that simply isn't offered by the syncrepl spec. Best to leave this alone for now. When we get to LDAP Transactions, and figuring out how to represent them in a syncrepl exchange, then it would be meaningful. -- -- Howard Chu CTO, 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#6848) wait timeout for slapd startup
by andrew.findlay＠skills-1st.co.uk 01 Mar '11

01 Mar '11

On Mon, Feb 28, 2011 at 09:36:01PM +0000, quanah(a)OpenLDAP.org wrote: > When LDAP is used as a dependency for other software during the init process (as > a kerberos backend, for example), the fact that slapd exits with success prior > to it being ready to accept connections can cause problems for the later > services that depend on it. It would be useful to have an (optional) flag "-w > <seconds>" that if provided, would have slapd wait up until <seconds> amount of > time has passed for the daemon to fully initialize. Some distros already deal with this in other ways - e.g. OpenSuSE waits until an ldapsearch on the null DN succeeds. This is done in the init.d script. One advantage of putting explicit support into OpenLDAP for this is that it may be possible to have an option to delay starting the listners on a replication consumer until a full refresh has been done from the master (this would need a timeout option too). There are obvious deadlock issues in multi-master configs, but admins would at least have the option of using this on pure consumers. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2011