I've been trying to track a segmentation fault for a couple of days but I'm running out of ideas and need some help or
suggestion on how to proceed.
Perhaps this is the wrong forum and if so I apologize. It's also worth mentioning that I don't have any knowledge about the
openSSL library source code but I've been working with ldap libraries for quite some time (about 10 years).
What I have is shared object (.so) that is loaded from another program (nothing I have control of) using a public API. My
library loads openLDAP (libldap_r and liblber) using dlopen/dlsym. After some initialization code I try to bind to a ldap source
(ldaps://ldaphost:636) but I get a segmentation fault in s23_clnt.c at line 159:
else if (s->ctx->info_callback != NULL)
For some reason s->ctx is a null pointer. My first thoughts was that I do something I shouldn't prior to ldap_sasl_bind_s which
corrupts the LDAP handle but after days with gdb and valgrind I still can't find anything.
openLDAP version used is 2.4.40 built with openSSL 1.0.1i.
If I copy the ldap code to a test executable it works fine.
Is there anything special to consider when loading the libraries from a shared object?
I understand that it is almost impossible to give me any good answers but since I'm a bit frustrated I hope someone can give me
What is the proper way to de-initialize openLDAP library?
Let's assume I have
a couple of general ldap_set_option
some ldap_set_option for TLS
Is ldap_unbind_s all that's required?
My problem is that if I do it this way when using openLDAP from a shared object and the process unloads the shared object and
then loads it again (restarts my library) TLS won't work anymore. Probably there is one or more global variables in openLDAP
that needs to be reset before unload to make sure the initialization works.
I looked at the ldapsearch example provided, in common.c, and noticed a call to ldap_pvt_tls_destroy. I tried that but it
doesn't make any difference.
I've compiled openLDAP to use Mozilla NSS.
LMDB seems to be quite the right database I am looking for in order to speed up
my application. However, I still need to figure some things out. While I could
get many answers to my questions by skimming through the archive, the following
things are still unclear to me, and it would be quite nice if someone could
- in the documentation, I saw two limits: the key is limited to 511 bytes
(by default) and the data is limited to 16777215 bytes. Is this correct?
For larger data sizes, is the data still maintained in one contiguous
block, so that the application can still access it directly without any
need of copying within LMDB? Or it is better to split larger data into
multiple key/value pairs?
- I discovered the return code "MDB_TXN_FULL". By what means are transactions
limited? I might consider to use few, but quite large transactions dealing
with hundreds of thousands key/value pairs to be created, updated or deleted
in some circumstances.
- I saw the discussion about the predefined database size, and that it is
recommended to use a never-to-be-reached size and to rely on the sparse file
capabilities of the underlying OS. If I would not want to go this way:
Is it correct that if I encounter an "MDB_MAP_FULL" return code, it
would be sufficient to abort the current transaction, resize the database
using mdp_env_set_mapsize and repeat the transaction?
Thanks in advance and regards,
Von: Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de>
Gesendet: Do 16.10.2014 13:46
Betreff: Q: accesslog and sessions
> I have configured accesslog for modification (attempts) in a multi-master
> configuration. Comparing accesslogs after some changes, I find some issues
> (openLDAP 2.4.26 of SLES11 SP3):
> On the originating server the "reqSession" varies with the connection made,
> while on a replication consumer the "reqSession" seems fixed (always 2 in one
'cause of replication.
> Also on the originating server I see the authenticated DN in
> "reqAuthzID", while on the replication consumer it seems to be always
> "cn=Admin,dc=example,dc=org". "reqStart" and "reqEnd" are also local for the
> LDAP server.
'cause the repl consumer writes to the database as admin user.
> Now at least I have a problem with "reqSession": If you examine accesslog at
> some later time, those volatile session IDs don't tell you anything anymore
> (e.g. the host that opened the connection). Could acesslog be modified to add
> some details from the session (like monitorConnectionPeerAddress,
> Ulrich Windl
This woule be a very nice feature, indeed.
> >> Now at least I have a problem with "reqSession": If you examine accesslog at
> >> some later time, those volatile session IDs don't tell you anything anymore
> >> (e.g. the host that opened the connection). Could acesslog be modified to add
> >> some details from the session (like monitorConnectionPeerAddress,
> >> monitorConnectionStartTime)?
> RTFM and turn on session logging.
> > This woule be a very nice feature, indeed.
You mean that I'm then able to get the session ID and search them in log if I turn on loglevel conns?
I have configured accesslog for modification (attempts) in a multi-master configuration. Comparing accesslogs after some changes, I find some issues (openLDAP 2.4.26 of SLES11 SP3):
On the originating server the "reqSession" varies with the connection made, while on a replication consumer the "reqSession" seems fixed (always 2 in one case). Also on the originating server I see the authenticated DN in "reqAuthzID", while on the replication consumer it seems to be always "cn=Admin,dc=example,dc=org". "reqStart" and "reqEnd" are also local for the LDAP server.
Now at least I have a problem with "reqSession": If you examine accesslog at some later time, those volatile session IDs don't tell you anything anymore (e.g. the host that opened the connection). Could acesslog be modified to add some details from the session (like monitorConnectionPeerAddress, monitorConnectionStartTime)?
I'm reading about referrals in RFC4511, which says:
"Referrals can be returned in response to any operation request (except
Unbind and Abandon, which do not have responses)."
Can OpenLDAP slapd return referrals for bind operations?
I got them for searches but not for binds. I'm using "Subordinate Knowledge
Information" as described here"
If no, can you please tell me the reasoning behind it?
Although I suspect what the answer would be, I thought It might be a good
idea to confirm with the list.
Is the following <attrlist> clause in OpenLdap's ACLs syntax valid;
by <who> <what>
Goal: LDAP server in Internet facing DMZ to provide authentication for externally hosted applications using internal AD credentials.
I've done a LOT of reading and testing, and there is one thing I am still not 100% clear on:
Is it possible to do this WITHOUT having a local user database on the OpenLDAP proxy? We will have thousands of users that will need to authenticate, and I can't maintain another user database (adds, removes, etc..). Is there a way to make OpenLDAP just act more like a reverse proxy and forward anything that matches a specific domain on to the internal LDAP/AD server for password verification?