Segmentation fault in s23_clnt.c when used in a library
by Tobias Ljunggren
Hello,
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
some hints.
Best regards,
Tobias
6 years, 5 months
Proper way to de initialize library
by Tobias Ljunggren
Hello,
What is the proper way to de-initialize openLDAP library?
Let's assume I have
ldap_initialize (ldaps://....)
a couple of general ldap_set_option
some ldap_set_option for TLS
ldap_sasl_bind_s
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.
Best regards,
Tobias
6 years, 5 months
[LMDB] some few questions
by Klaus Malorny
Hi,
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
clarify them:
- 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,
Klaus
6 years, 5 months
AW: Q: accesslog and sessions
by Uwe Werler
-----Ursprüngliche Nachricht-----
Von: Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de>
Gesendet: Do 16.10.2014 13:46
Betreff: Q: accesslog and sessions
An: openldap-technical(a)openldap.org;
> Hi!
>
> 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).
'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,
> monitorConnectionStartTime)?
>
> Regards,
> Ulrich Windl
>
This woule be a very nice feature, indeed.
>
>
6 years, 5 months
WG: (ITS#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
by Uwe Werler
FYI - last week I filed an ITS regarding overlay rwm:
-----Ursprüngliche Nachricht-----
Von: Uwe Werler <uwe.werler(a)retiolum.eu>
Gesendet: Mo 13.10.2014 08:46
Betreff: (ITS#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
An: openldap-its(a)OpenLDAP.org;
Full_Name: Uwe Werler
Version: 2.4.40
OS: Linux / SLES 11 SP3
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (155.56.68.214)
If I have rewrite rules like this:
23 olcOverlay={1}rwm,olcDatabase={3}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: {1}rwm
olcRwmRewrite: {0}rwm-rewriteEngine on
olcRwmRewrite: {1}rwm-rewriteContext searchFilter
olcRwmRewrite: {2}rwm-rewriteRule "(.*\\()uid=sapr3(\\).*)" "$1uid=dlmsapr3$2"
olcRwmRewrite: {3}rwm-rewriteRule "(.*\\()uid=sdb(\\).*)" "$1uid=sdb$2"
olcRwmRewrite: {4}rwm-rewriteRule "(.*\\()uid=sapadm(\\).*) "$1uid=dlmsapadm$2"
olcRwmRewrite: {5}rwm-rewriteRule "(.*\\()uid=sapmnt(\\).*)" "$1uid=sapmnt$2"
olcRwmRewrite: {6}rwm-rewriteRule "(.*\\()uid=[a-z0-9]{3}adm(\\).*)" "$1uid=dlmsidadm$2"
olcRwmRewrite: {7}rwm-rewriteRule "(.*\\()uid=sqd[a-z0-9]%3%3}(\\).*)" "$1uid=dlmsqdsid$2"
olcRwmRewrite: {8}rwm-rewriteRule "(.*\\()uid=ora[a-z0-9]{3}(\\).*)" "$1uid=dlmorasid$2"
olcRwmRewrite: {9}rwm-rewriteRule "(.*\\()uid=sap[a-z0-9]{3}(\\).*)" "$1uid=dlmsapr3$2"
olcRwmRewrite: {10}rwm-rewriteRule "(.*\\()uid=sap[a-z0-9]{3}db(\\).*)" "$1uid=dlmsapr3db$2"
olcRwmRewrite: {11}rwm-rewriteRule "(.*\\()uid=db2[a-z0-9]{3}(\\).*)" "$1uid=dlmdb2sid$2"
olcRwmRewrite: {12}rwm-rewriteRule "(.*\\()uid=db2[a-z0-9]{3}ap(\\).*)" "$1uid=dlmdb2sid$2"
then the 7. rule / 9. statement failes to escape. In this example ora*** get's not correctly rewritten to dlmora***: See loglevel trace:
543b711d ==> rewrite_rule_apply rule='(.*\()uid=sapr3(\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
543b711d ==> rewrite_rule_apply rule='(.*\()uid=sdb(\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
543b711d ==> rewrite_rule_apply rule='(.*\()uid=sapadm(\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
543b711d ==> rewrite_rule_apply rule='(.*\()uid=sapmnt(\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
543b711d ==> rewrite_rule_apply rule='(.*\()uid=[a-z0-9]{3}adm(\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
543b711d ==> rewrite_rule_apply rule='(.*\()uid=sqd[a-z0-9]{3}(\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
543b711d ==> rewrite_rule_apply rule='(.*\\()uid=ora[a-z0-9]{3}(\\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
543b711d ==> rewrite_rule_apply rule='(.*\()uid=sap[a-z0-9]{3}(\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
543b711d ==> rewrite_rule_apply rule='(.*\()uid=sap[a-z0-9]{3}db(\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
543b711d ==> rewrite_rule_apply rule='(.*\()uid=db2[a-z0-9]{3}(\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
543b711d ==> rewrite_rule_apply rule='(.*\()uid=db2[a-z0-9]{3}ap(\).*)' string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))'
[1 pass(es)]
If I insert a dummy statement like this:
olcRwmRewrite: {0}rwm-rewriteEngine on
olcRwmRewrite: {1}rwm-rewriteContext searchFilter
olcRwmRewrite: {2}rwm-rewriteRule "(.*\\()uid=sapr3(\\).*)" "$1uid=dlmsapr3$2"
olcRwmRewrite: {3}rwm-rewriteRule "(.*\\()uid=sdb(\\).*)" "$1uid=sdb$2"
olcRwmRewrite: {4}rwm-rewriteRule "(.*\\()uid=sapadm(\\).*)" "$1uid=dlmsapadm$2"
olcRwmRewrite: {5}rwm-rewriteRule "(.*\\()uid=sapmnt(\\).*)" "$1uid=sapmnt$2"
olcRwmRewrite: {6}rwm-rewriteRule "(.*\\()uid=[a-z0-9]{3}adm(\\).*)" "$1uid=dlmsidadm$2"
olcRwmRewrite: {7}rwm-rewriteRule "(.*\\()uid=sqd[a-z0-9]{3}(\\).*)" "$1uid=dlmsqdsid$2"
olcRwmRewrite: {8}rwm-rewriteRule "(.*\\()uid=ora[a-z0-9]{3}(\\).*)" "$1uid=dlmorasid$2"
olcRwmRewrite: {9}rwm-rewriteContext placeHolder alias searchFilter
olcRwmRewrite: {10}rwm-rewriteRule "(.*\\()uid=sap[a-z0-9]{3}(\\).*)" "$1uid=dlmsapr3$2"
olcRwmRewrite: {11}rwm-rewriteRule "(.*\\()uid=sap[a-z0-9]{3}db(\\).*)" "$1uid=dlmsapr3db$2"
olcRwmRewrite: {12}rwm-rewriteRule "(.*\\()uid=db2[a-z0-9]{3}(\\).*)" "$1uid=dlmdb2sid$2"
olcRwmRewrite: {13}rwm-rewriteRule "(.*\\()uid=db2[a-z0-9]{3}ap(\\).*)" "$1uid=dlmdb2sid$2"
then the escapes are working properly.
Sometimes this occurs with the last rule too.
I first tried with 2.4.26 (standard version in SLES11 SP3) and now with 2.4.40.
Regards Uwe
6 years, 5 months
AW: Q: accesslog and sessions
by Uwe Werler
> >> 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?
6 years, 5 months
Q: accesslog and sessions
by Ulrich Windl
Hi!
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)?
Regards,
Ulrich Windl
6 years, 6 months
referrals
by Balazs Kovacs
Hi,
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"
http://www.openldap.org/doc/admin24/referrals.html
If no, can you please tell me the reasoning behind it?
Best Regards,
Balazs
6 years, 6 months
<attrlist> syntax in ACLs
by Nikos Voutsinas
Hi all,
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;
<attr1> [val[.<basic-style>]=<regex>],<attr2>
e.g.
to dn.subtree="ou=People,dc=foo,dc=com"
attrs=entry,objectClass val.regex="objvalue1|objvalue2",attr1,attr2
by <who> <what>
Thanks
6 years, 6 months
OpenLDAP as proxy to Active Directory backend
by Jeff Lebo
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?
6 years, 6 months
