X509_V_FLAG_PARTIAL_CHAIN support in OpenLDAP
by Doug Leavitt
Hi,
OpenSSL now has X509_V_FLAG_PARTIAL_CHAIN support in the code base as of
1.0.2a.
I would like to submit a patch to enable X509_V_FLAG_PARTIAL_CHAIN support
in OpenLDAP libldap, assuming it exists in the version of OpenSSL being
use to build
OpenLDAP.
Before I submit any patch I would like to know that would be acceptable
for integration.
Should support always be enabled if the version of OpenSSL has it
e.g. ifdef on X509_V_FLAG_PARTIAL_CHAIN
Should it be a config time option check and ifdef enable if found in
e.g. like the ifdef on HAVE_OPENSSL_CRL
Are there more requirements that is required in the patch, before it would
be accepted such as ldap_set_option support?
Thanks in advance,
Doug.
7 years, 10 months
back-sock: Format of RESULT
by Michael Ströder
HI!
I'm really confused by this part of slapd-sock(5):
----------------------------- snip -----------------------------
If the overlay is configured to send response messages to the
external program, they will appear as an extended RESULT message or
as an ENTRY message, defined below. The RESULT message is similar
to the one above, but also includes the msgid and any configured
extensions:
RESULT
msgid: <message id>
code: <integer>
matched: <matched DN>
info: <text>
<blank line>
Typically both the msgid and the connid will be needed to match a
result message to a request. The ENTRY message has the form
ENTRY
msgid: <message id>
<entry in LDIF format>
<blank line>
----------------------------- snip -----------------------------
Especially the wording "both the msgid and the connid will be needed" seems
logical to me but does not match any format description in the man-page.
I'd also appreciate if the back-sock protocol would be more robust:
Why not require connid and msgid consistently in *every* operation sock
request and result sock request and *all* responses returned by the external
listener even in CONTINUE?
Ciao, Michael.
7 years, 11 months
enhancements for back-sock, especially MONITOR
by Michael Ströder
HI!
I'm currently working on implementing a generic back-sock listener in Python
and two special instances of it. Mainly the current use-case is overlay usage
intercepting bind requests.
Of course I'd like to monitor the back-sock listeners (internal state like
counters etc.), probably via LDAP ideally with access control enforced by
slapd itself.
Accessing the monitoring data could be done via search operations but I'd like
to avoid mandating a generic "sockops search" overlay configuration just for
monitoring data because every search request would be passed to the external
listener even though the listener does not handle them (except for the
monitoring data).
I could add additional backends with own suffixes pointing to the same
back-sock listener. But having two or three separate listeners would require
configuring the same number of database sections. Also having to implement to
much access control in the database listeners is also not ideal.
It would be really nice if requests going to a back-sock listener configured
as overlay could be pre-filtered by slapd configuration.
Something like
sockops search
ldap:///cn=sock-listener-monitor,dc=example,dc=com??base?(objectClass=monitorSubEntry)
Would pass the search request only to the external listener of the search
operation matches all parameters in the given LDAP URL. This would be also
handy for other operations.
What do you think?
Ciao, Michael.
P.S.: These ITS would also improve back-sock (overlay) usage:
(ITS#8172) RFE: back-sock CONTINUE to get modified parameters
(ITS#8177) RFE: back-sock to receive controls
(ITS#8178) back-sock: Timeout to avoid locking
7 years, 11 months
Update/drop cruft: LDAP_DEPRECATED, CLDAP, C version
by Hallvard Breien Furuseth
Some wishes for RE25:
Expose most LDAP_DEPRECATED functions again. This code is not going
away, or it'd be gone by now after 16 years of deprecation. I usually
#define LDAP_DEPRECATED anyway. What's the point of trying to make me
pass 2 extra NULL args to a bunch of functions? And making a "SASL
bind" function the proper way to do Simple Bind is silly and confusing.
OTOH some depreciation make sense, like ldap_get_values() which returns
char** instead of berval**.
Add --enable-cldap as "experimental". Add tests and some fixes. The
CLDAP code isn't going away either, so i seems better to support it
properly. People are submitting libldap ITSes, but slapd and ldapsearch
usage remain broken. slapd looks easy to fix, ldapsearch depends on
vestiges of libldap code to ignore Bind requests. Dunno if I want to
bother tracking that down in libldap or just omit the Bind in
ldapsearch. Maybe RedHat has a fix.
...or do the opposite, kill LDAP_DEPRECATED and CLDAP. I hope not, but
that's better than eternally deprecated/code-rotting features.
Kill K&R1 support, i.e. the LDAP_P(()) stuff. Supposedly the headers
support K&R1, but OpenLDAP-2.0 broke this (ITS#6171). Nobody has cared
enough to fix it, and I refuse to fix it.
See if we can require C99 to build OpenLDAP, but keep the headers
C90-compliant. In particular, replace Debug() with a varargs macro,
initially without changing the calls to Debug(). If we get away with
that, we can kill the extra ,0,0,0 arguments to Debug() later so gcc
-Wformat will catch missing/spurious args.
--
Hallvard
7 years, 11 months
slapd-sock: extensions always UTF-8
by Michael Ströder
HI!
Are these extensions guaranteed to be always
sent by back-sock as raw UTF-8 in one line?
Or does the listener also has to handle
base64 encoding and line-folding like in LDIF for these extension lines?
binddn: <bound DN>
peername: IP=<address>:<port>
ssf: <SSF value>
connid: <connection ID>
Ciao, Michael.
7 years, 11 months
Relaxed mode for delta-sync MMR
by Quanah Gibson-Mount
After having deployed delta-sync MMR at several customer sites, the general
handling of conflict resolution in MMR mode is significantly sub optimal,
and routinely causes the MMR nodes to get further out of sync, worsening
things significantly (Mainly due to ITS#8125).
The main issues I see are the following:
a) Two masters get different change requests at approximately the same time
to add a value X to an attribute.
b) Two masters get different change requests at approximately the same time
to delete a value X from an attribute.
In these two specific cases, in relaxed mode, rather than falling back and
re-syncing the entire database, I think the conflict should be discarded
(skipped), and logged as such. I.e., there is no actual discrepancy in the
object. It still has X present in the add case, and X gone in the delete
case.
At best, if we're going to do fallback, then we should only see about
resyncing the specific entry. The overall behavior I'm seeing from
OpenLDAP is the masters get in an endless cycle of re-sync, and the more
they do so, the more out of sync they become, leading to a point at which
you have to stop all masters, export all their DBs, sort them, find missing
entries between all sets of masters, and build a brand new DB with which to
reload them, until they get massively out of sync again. I.e., the current
strategy of resync is doing no favors to anyone. It may work OK on very
small DBs, where a resync only takes seconds, but on larger dbs were such
syncs take 30+ minutes to hours, it is not a useful methodology.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
7 years, 11 months
Infinite loop with "mdb_search: 124xxxx1 scope not okay" while adding an entry
by Benjamin Dauvergne
Hi,
I'm using OpenLDAP debian package from wheezy-backports (version
2.4.31+really2.4.40+dfsg) which is a 2.4.40 but backported I think under
another version number to allow the jessie package to execute its migration
when upgrade time will come.
When trying to initialize a new DB by loading an LDIF file using ldapvi,
looking like that:
add dc=coin2,dc=fr
objectClass: organization
objectClass: dcObject
objectClass: eduOrg
objectClass: supannOrg
dc: coin2
o: whatever
supannEtablissement: {UAI}ccc
add ou=people,dc=coin2,dc=fr
objectClass: organizationalUnit
ou: people
add uid=admin,ou=people,dc=coin2,dc=fr
objectClass: inetOrgPerson
objectClass: eduPerson
objectClass: supannPerson
uid: admin
cn: Administrateur annuaire
displayName: Administrateur annuaire
givenName: Administrateur
sn: annuaire
supannListeRouge: TRUE
userPassword: xxxx
supannEtablissement: {UAI}COIN
It blocks on adding the ou=people. After setting loglever to 255 I got my
syslog filled with such messages, soon filling the virtual machine virtual
disk:
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 1 scope not okay
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 2 scope not okay
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 3 scope not okay
etc...
The log of the query finishing like that is:
Jun 2 02:34:26 ldap1-psl slapd[12159]: connection_get(15)
Jun 2 02:34:26 ldap1-psl slapd[12159]: connection_get(15): got connid=1001
Jun 2 02:34:26 ldap1-psl slapd[12159]: connection_read(15): checking for input on id=1001
Jun 2 02:34:26 ldap1-psl slapd[12159]: op tag 0x68, time 1433205266
Jun 2 02:34:26 ldap1-psl slapd[12159]: conn=1001 op=9 do_add
Jun 2 02:34:26 ldap1-psl slapd[12159]: conn=1001 op=9 do_add: dn (ou=people,dc=coin2,dc=fr)
Jun 2 02:34:26 ldap1-psl slapd[12159]: >>> dnPrettyNormal: <ou=people,dc=coin2,dc=fr>
Jun 2 02:34:26 ldap1-psl slapd[12159]: <<< dnPrettyNormal: <ou=people,dc=coin2,dc=fr>, <ou=people,dc=coin2,dc=fr>
Jun 2 02:34:26 ldap1-psl slapd[12159]: ==> unique_add <ou=people,dc=coin2,dc=fr>
Jun 2 02:34:26 ldap1-psl slapd[12159]: ==> unique_search (|(objectClass=organizationalUnit)(ou=people))
Jun 2 02:34:26 ldap1-psl slapd[12159]: str2filter "(|(objectClass=organizationalUnit)(ou=people))"
Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter
Jun 2 02:34:26 ldap1-psl slapd[12159]: OR
Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter_list
Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter
Jun 2 02:34:26 ldap1-psl slapd[12159]: EQUALITY
Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter 0
Jun 2 02:34:26 ldap1-psl slapd[12159]: begin get_filter
Jun 2 02:34:26 ldap1-psl slapd[12159]: EQUALITY
Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter 0
Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter_list
Jun 2 02:34:26 ldap1-psl slapd[12159]: end get_filter 0
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_search
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_dn2entry("dc=coin2,dc=fr")
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_dn2id("dc=coin2,dc=fr")
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_dn2id: got id=0x1
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_entry_decode:
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_entry_decode
Jun 2 02:34:26 ldap1-psl slapd[12159]: => access_allowed: search access to "dc=coin2,dc=fr" "entry" requested
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= root access granted
Jun 2 02:34:26 ldap1-psl slapd[12159]: => access_allowed: search access granted by manage(=mwrscxd)
Jun 2 02:34:26 ldap1-psl slapd[12159]: search_candidates: base="dc=coin2,dc=fr" (0x00000001) scope=-1
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates
Jun 2 02:34:26 ldap1-psl slapd[12159]: #011OR
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_list_candidates 0xa1
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates
Jun 2 02:34:26 ldap1-psl slapd[12159]: #011EQUALITY
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_equality_candidates (objectClass)
Jun 2 02:34:26 ldap1-psl slapd[12159]: => key_read
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_idl_fetch_key: [b49d1940]
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_index_read: failed (-30798)
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_equality_candidates: id=0, first=0, last=0
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=0 first=0 last=0
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates
Jun 2 02:34:26 ldap1-psl slapd[12159]: #011OR
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_list_candidates 0xa1
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates
Jun 2 02:34:26 ldap1-psl slapd[12159]: #011EQUALITY
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_equality_candidates (objectClass)
Jun 2 02:34:26 ldap1-psl slapd[12159]: => key_read
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_idl_fetch_key: [9bee355f]
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_index_read: failed (-30798)
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_equality_candidates: id=0, first=0, last=0
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=0 first=0 last=0
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_filter_candidates
Jun 2 02:34:26 ldap1-psl slapd[12159]: #011EQUALITY
Jun 2 02:34:26 ldap1-psl slapd[12159]: => mdb_equality_candidates (ou)
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_equality_candidates: (ou) not indexed
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=-1 first=1 last=-1
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_list_candidates: id=-1 first=1 last=-1
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=-1 first=1 last=-1
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_list_candidates: id=-1 first=1 last=-1
Jun 2 02:34:26 ldap1-psl slapd[12159]: <= mdb_filter_candidates: id=-1 first=1 last=-1
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search_candidates: id=-1 first=1 last=-1
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 1 scope not okay
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 2 scope not okay
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 3 scope not okay
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 4 scope not okay
Jun 2 02:34:26 ldap1-psl slapd[12159]: mdb_search: 5 scope not okay
etc...
I don't know why it's doing a search on an add but seeing the message "(ou) not
indexed" I though that maybe adding an equality index on this attribute would
help, and effectively it did. Now the add ou=people passed, but it started
looping again when adding the uid=admin entry.
The infinite loop happen in server/slapd/back-mdb/search.c in mdb_search(). If
you have any idea I can continue investigating or add debug logs.
The debian package has the following patches applied over openldap 2.4.40:
add-tlscacert-option-to-ldap-conf
autogroup-makefile
contrib-modules-use-dpkg-buildflags
do-not-second-guess-sonames
evolution-ntlm
fix-build-top-mk
getaddrinfo-is-threadsafe
heimdal-fix
index-files-created-as-root
ITS6035-olcauthzregex-needs-restart.patch
ITS7975-fix-mdb-onelevel-search.patch
ITS8027-deref-reject-empty-attr-list.patch
ITS8046-fix-vrFilter_free-crash.patch
lastbind-makefile
ldap-conf-tls-cacertdir
ldapi-socket-place
libldap-symbol-versions
man-slapd
no-AM_INIT_AUTOMAKE
no-bdb-ABI-second-guessing
pw-sha2-makefile
sasl-default-path
slapi-errorlog-file
smbk5pwd-makefile
switch-to-lt_dlopenadvise-to-get-RTLD_GLOBAL-set.diff
wrong-database-location
7 years, 12 months
