Lib is not relocatable although --with-pic was used. Bug?
by Kristof Van Damme
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.
10 years, 9 months
Re: (ITS#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it
> 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.
10 years, 9 months
Re: (ITS#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it
> 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/
>
>
10 years, 9 months
Re: (ITS#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it
> 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/
>
>
10 years, 9 months
Re: (ITS#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it
> 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
You're passing both -W and -w, which are mutually exclusive. p.
10 years, 9 months
Re: (ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by ghenry＠OpenLDAP.org
----- 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/
10 years, 9 months
(ITS#6849) ldapsearch assertion failed
by gnuround＠gmail.com
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
10 years, 9 months
Re: (ITS#6848) wait timeout for slapd startup
by hyc＠symas.com
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/
10 years, 9 months
Re: (ITS#6848) wait timeout for slapd startup
by andrew.findlay＠skills-1st.co.uk
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 |
-----------------------------------------------------------------------
10 years, 9 months
