[Issue 10080] New: refreshAndPersist synchronization problem with glue + rwm
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=10080
Issue ID: 10080
Summary: refreshAndPersist synchronization problem with glue +
rwm
Product: OpenLDAP
Version: 2.6.2
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: homma(a)allworks.co.jp
Target Milestone: ---
Created attachment 972
--> https://bugs.openldap.org/attachment.cgi?id=972&action=edit
Stack trace of segfault
I have an openldap 2.6.2 server "ldap1" with the following DIT:
dc=example,dc=com (back-mdb)
ou=users
ou=local
cn=admin
cn=sync
...
ou=remote (back-ldap -> ldaps://dc1.example.com)
...
Local user entries are created under subtree
"ou=local,ou=users,dc=example,dc=com", and the subtree
"ou=remote,ou=users,dc=example,dc=com" is a proxy to an Active Directory server
"dc1.example.com" (subtree "ou=users,dc=ad,dc=example,dc=com").
The concrete configuration is as follows:
----------------
dn: olcDatabase={2}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {2}ldap
olcSuffix: ou=remote,ou=users,dc=example,dc=com
olcSubordinate: TRUE
olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
olcDbURI: ldaps://dc1.example.com
olcDbIDAssertBind: bindmethod=simple
binddn="cn=aduser,ou=users,dc=ad,dc=example,dc=com"
credentials=secret
tls_reqcert=demand
mode=none
olcDbIDAssertAuthzFrom:
{0}dn.exact:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
olcDbIDAssertAuthzFrom:
{1}dn.exact:cn=admin,ou=local,ou=users,dc=example,dc=com
dn: olcOverlay={0}rwm,olcDatabase={2}ldap,cn=config
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
olcOverlay: {0}rwm
olcRwmRewrite: {0}rwm-suffixmassage "ou=users,dc=ad,dc=example,dc=com"
olcRwmMap: {0}objectclass inetOrgPerson organizationalPerson
olcRwmMap: {1}objectclass posixAccount user
olcRwmMap: {2}attribute uid sAMAccountName
olcRwmMap: {3}attribute homeDirectory unixHomeDirectory
olcRwmMap: {4}attribute ou *
olcRwmMap: {5}attribute cn *
olcRwmMap: {6}attribute sn *
olcRwmMap: {7}attribute givenName *
olcRwmMap: {8}attribute mail *
olcRwmMap: {9}attribute uidNumber *
olcRwmMap: {10}attribute gidNumber *
olcRwmMap: {11}attribute *
dn: olcDatabase={3}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {3}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=example,dc=com
olcRootDN: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
olcAccess: {0}to *
by dn.exact="cn=admin,ou=local,ou=users,dc=example,dc=com" write
by dn.exact="cn=sync,ou=local,ou=users,dc=example,dc=com" write
by * break
olcAccess: {1}to attrs=userPassword
by anonymous auth
by self write
by * none
olcAccess: {2}to *
by * read
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
----------------
So far, so good. A subtree search on "ou=users,dc=example,dc=com" returns both
local and remote users.
But when I create the second server "ldap2" with similar configuration and
configure refreshAndPersist replication, I run into a problem.
(1) When I configure on "ldap1" server,
----------------
dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
----------------
and on "ldap2" server,
----------------
dn: olcDatabase={3}mdb,cn=config
changeType: modify
replace: olcSyncrepl
olcSyncrepl: {0}rid=301
provider="ldap://ldap1/"
bindmethod=simple
binddn="cn=sync,ou=local,ou=users,dc=example,dc=com"
credentials=secret
searchbase="dc=example,dc=com"
type=refreshAndPersist
retry="5 12 60 +" timeout=1
----------------
the initial refresh stage fails.
(a) Whith the above configuration, the refresh failes with "(48) Inappropriate
authentication", because the bind DN
"cn=sync,ou=local,ou=users,dc=example,dc=com" does not have access to the
subordinate database.
(b) When I add "cn=sync,ou=local,ou=users,dc=example,dc=com" to the ID
assertion list on "ldap1" server,
----------------
dn: olcDatabase={2}ldap,cn=config
changeType: modify
add: olcDbIDAssertAuthzFrom
olcDbIDAssertAuthzFrom: {2}dn.exact:cn=sync,ou=local,ou=users,dc=example,dc=com
----------------
the refresh fails with "(12) Critical extension is unavailable", because Active
Directory does not support Sync Request Control.
(c) Even if the remote server supports Sync Request Control, the refresh fails
with the message "server sent multiple refreshDone messages? Ending session".
The refreshDone messages are sent twice, one for the sperior databese and the
other for the subordinate database.
(d) If I delete olcSubordinate attribute and restart slapd on "ldap1" server,
----------------
dn: olcDatabase={2}ldap,cn=config
changeType: modify
delete: olcSubordinate
----------------
then the refresh stage completes successfully.
Once the persistent session is established, I can add olcSubordinate attribute
again.
----------------
dn: olcDatabase={2}ldap,cn=config
changeType: modify
add: olcSubordinate
olcSubordinate: TRUE
----------------
When I modify entries in the subordinate database on "ldap1" server, no change
notification is sent to "ldap2" server.
This is the desired behavior, but if I restart slapd on "ldap1" server, the
refresh starts failing again.
(2) When I configure the glue overlay explicitly before the syncprov overlay,
as described in "man slapd-config",
----------------
dn: olcOverlay={0}glue,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcConfig
olcOverlay: {0}glue
dn: olcOverlay={1}syncprov,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
----------------
the refresh stage completes successfully without attempting to search the
subordinate database.
This is fine because I do not need to synchronize the subordinate database
between "ldap1" and "ldap2" servers.
However, when I modify an entry in the subordinate database on "ldap1" server,
slapd crashes by segmentation fault. See the attached file for stack trace.
After some research, I found that the cause of the crash is as follows:
In syncprov_matchops(), it attempts to get the modified entry with DN =
op->o_req_ndn.
But since op->o_req_ndn has been rewritten in the rmw overlay,
glue_back_select() incorrectly selects the mdb backend, which should be the
ldap backend.
At this point, op->o_bd->be_private holds a value of type ldapinfo_t, but
mdb_entry_get() tries to interpret it as type struct mdb_info, causing a
segfault.
In summary, the problem is:
When I configure refreshAndPersist synchronization for a database with a
subordinate ldap backend using DN rewriting,
(1) The subordinate database cannot be excluded from both refresh and
persistent stage of the synchronization:
When the glue overlay is not explicitly configured:
- In the refresh stage, the subordinate database is included in the search.
- In the persist stage, the subordinate database is excluded from the
synchronization.
When the glue overlay is explicitly configured before the syncprov overlay:
- In the refresh stage, the subordinate database is excluded from the
search.
- In the persist stage, the subordinate database is included in the
synchronization.
This seems to be inconsistent.
(2) If the subordinate database is included in the refresh stage, the refresh
fails for one of the following reasons:
- the syncrepl user is not allowed to access the subordinate database
- the remote server does not support Sync Request Control
- multiple refreshDone messages are returned
The refresh stage completes successfully if olcSubordinate attribute is deleted
from the subordinate database.
olcSubordinate attribute can be added again once the persistent session is
established, but the refresh stage starts failing again if slapd is restarted.
(3) If the subordinate database is included in the persist stage, modifying
entries in the subordinate database causes slapd to crash.
--
You are receiving this mail because:
You are on the CC list for the issue.
6 days, 12 hours
[Issue 9378] New: Crash in mdb_put() / mdb_page_dirty()
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9378
Issue ID: 9378
Summary: Crash in mdb_put() / mdb_page_dirty()
Product: LMDB
Version: 0.9.26
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: nate(a)kde.org
Target Milestone: ---
The KDE Baloo file indexer uses lmdb as its database (source code available at
https://invent.kde.org/frameworks/baloo). Our most common crash, with over 100
duplicate bug reports, is in lmdb. Here's the bug report tracking it:
https://bugs.kde.org/show_bug.cgi?id=389848.
The version of lmdb does not seem to matter much. We have bug reports from Arch
users with lmdb 0.9.26 as well as bug reports from people using many earlier
versions.
Here's an example backtrace, taken from
https://bugs.kde.org/show_bug.cgi?id=426195:
#6 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#7 0x00007f3c0bbb9859 in __GI_abort () at abort.c:79
#8 0x00007f3c0b23ba83 in mdb_assert_fail (env=0x55e2ad710600,
expr_txt=expr_txt@entry=0x7f3c0b23e02f "rc == 0",
func=func@entry=0x7f3c0b23e978 <__func__.7221> "mdb_page_dirty",
line=line@entry=2127, file=0x7f3c0b23e010 "mdb.c") at mdb.c:1542
#9 0x00007f3c0b2306d5 in mdb_page_dirty (mp=<optimized out>,
txn=0x55e2ad7109f0) at mdb.c:2114
#10 mdb_page_dirty (txn=0x55e2ad7109f0, mp=<optimized out>) at mdb.c:2114
#11 0x00007f3c0b231966 in mdb_page_alloc (num=num@entry=1,
mp=mp@entry=0x7f3c0727aee8, mc=<optimized out>) at mdb.c:2308
#12 0x00007f3c0b231ba3 in mdb_page_touch (mc=mc@entry=0x7f3c0727b420) at
mdb.c:2495
#13 0x00007f3c0b2337c7 in mdb_cursor_touch (mc=mc@entry=0x7f3c0727b420) at
mdb.c:6523
#14 0x00007f3c0b2368f9 in mdb_cursor_put (mc=mc@entry=0x7f3c0727b420,
key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820,
flags=flags@entry=0) at mdb.c:6657
#15 0x00007f3c0b23976b in mdb_put (txn=0x55e2ad7109f0, dbi=5,
key=key@entry=0x7f3c0727b810, data=data@entry=0x7f3c0727b820,
flags=flags@entry=0) at mdb.c:9022
#16 0x00007f3c0c7124c5 in Baloo::DocumentDB::put
(this=this@entry=0x7f3c0727b960, docId=<optimized out>,
docId@entry=27041423333263366, list=...) at ./src/engine/documentdb.cpp:79
#17 0x00007f3c0c743da7 in Baloo::WriteTransaction::replaceDocument
(this=0x55e2ad7ea340, doc=..., operations=operations@entry=...) at
./src/engine/writetransaction.cpp:232
#18 0x00007f3c0c736b16 in Baloo::Transaction::replaceDocument
(this=this@entry=0x7f3c0727bc10, doc=..., operations=operations@entry=...) at
./src/engine/transaction.cpp:295
#19 0x000055e2ac5d6cbc in Baloo::UnindexedFileIndexer::run
(this=0x55e2ad79ca20) at
/usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:60
#20 0x00007f3c0c177f82 in QThreadPoolThread::run (this=0x55e2ad717f20) at
thread/qthreadpool.cpp:99
#21 0x00007f3c0c1749d2 in QThreadPrivate::start (arg=0x55e2ad717f20) at
thread/qthread_unix.cpp:361
#22 0x00007f3c0b29d609 in start_thread (arg=<optimized out>) at
pthread_create.c:477
#23 0x00007f3c0bcb6103 in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
--
You are receiving this mail because:
You are on the CC list for the issue.
1 week
[Issue 9719] New: refreshOnly sends empty cookie when client up to date
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9719
Issue ID: 9719
Summary: refreshOnly sends empty cookie when client up to date
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Syncprov will send an empty cookie if the consumer has the same cookie as
provider. To the best of my knowledge this is not in line with RFC4533 and
consumers would effectively drop their cookie when the search finishes.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 week, 5 days
[Issue 9795] New: Remove memberof overlay
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9795
Issue ID: 9795
Summary: Remove memberof overlay
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The memberof overlay was deprecated with the release of OpenLDAP 2.5. It
should be removed prior for the next minor release (i.e., 2.7)
--
You are receiving this mail because:
You are on the CC list for the issue.
2 weeks
[Issue 10065] New: slapd needs a config option for the ssf of an external security proxy using "proxy protocol v2"
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=10065
Issue ID: 10065
Summary: slapd needs a config option for the ssf of an external
security proxy using "proxy protocol v2"
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: sean(a)teletech.com.au
Target Milestone: ---
Commit 146889f introduced support for the haproxy "proxy protocol v2". A very
welcome addition that allows an external security layer to be implemented. This
implementation is however somewhat hobbled.
Cyrus SASL uses "Security Strength Factors" or "ssf" to determine what
Authentication mechanisms to offer. slapd conveys the implicit security of UNIX
domain sockets to the SASL layer by specifying a non-zero ssf for these
connections. This can be configured with the "olcLocalSSF" config setting.
For implicit/explicit TLS connections, the "olcSecurity: tls=<n>" provides the
cryptographic strength of the TLS layer to the SASL layer.
For an external TLS-terminating proxy, there does not appear to be any way to
inform Cyrus SASL of the presence of TLS security on these proxied connections.
The outcome of this is that PLAIN and EXTERNAL authentication mechanisms are
not offered to clients connecting through the secure proxy.
This can be overcome by weakening the security properties of the SASL layer
with the olcSaslSecProps configuration option, but this weakening will apply to
all clients, not just clients connecting via the secure proxy.
What is required is some way to tell slapd and it's integrated SASL layer about
the presence of TLS encryption on the proxy's input. As a precaution, this
might be restricted to slapd connections in the 127.0.0.0/8 [IPv6:::] address
ranges.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 weeks
[Issue 9786] New: liblber: missing export of ber_pvt_wsa_err2string
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9786
Issue ID: 9786
Summary: liblber: missing export of ber_pvt_wsa_err2string
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: tobias.junghans(a)veyon.io
Target Milestone: ---
When building (cross-compiling) OpenLDAP via GCC/mingw-w64, an undefined
reference to ber_pvt_wsa_err2string() is reported when libldap.dll is linked.
This can be fixed easily by adding ber_pvt_wsa_err2string() to
libraries/liblber/lber.map
--
You are receiving this mail because:
You are on the CC list for the issue.
2 weeks
[Issue 9902] New: Make max index DBs for back-mdb configurable
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9902
Issue ID: 9902
Summary: Make max index DBs for back-mdb configurable
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
From ITS#9895:
Currently there is a hardcoded limit of 128 index DBs in back-mdb. Some sites
want more than this (although there's no evidence they actually use more than
128 attributes in all of their applications' search filters).
For 2.5/2.6 we can simply double the constant. For 2.7 consider making it
configurable.
Note that increasing the number increases the size of an LMDB transaction
structure, and also increases the time needed to initialize it whenever
creating a transaction, so it's a bad idea to just set this to an arbitrarily
large number.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 weeks
[Issue 9881] New: Ability to track last authentication for database objects
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9881
Issue ID: 9881
Summary: Ability to track last authentication for database
objects
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For simple binds, we have the ability to track the last success via the
lastbind functionality (pwdLastSuccess attribute). However this doesn't allow
one to see when an object that exists in a database last authenticated via
SASL.
It would be useful to add similar functionality for SASL binds.
This can be useful information that allows one to tell if an object is being
actively authenticated to (generally, users and system accounts, etc).
Obviously if something is directly mapped to an identity that doesn't exist in
the underlying DB, that cannot be tracked.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 weeks