https://bugs.openldap.org/show_bug.cgi?id=9471
Issue ID: 9471
Summary: Add RBAC overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its RBAC overlay to core
The slapo-…
[View More]rbac overlay is an implementation of the ANSI INCITS 359 Role-Based
Access Control (RBAC) Core.
When instantiated, it intercepts, decodes and enforces specific RBAC policies
per the Apache Fortress RBAC data formats.
The overlay provides a set of extended operations.
They include session create/delete, checkAccess, addActiveRole, dropActiveRole
and sessionRoles.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=9472
Issue ID: 9472
Summary: Add datamorph overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its datamorph overlay to core
The …
[View More]datamorph overlay to slapd allows attributes with a few predefined values
to be saved more space-efficiently as well as signed or unsigned integer
attributes.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=9473
Issue ID: 9473
Summary: Add variant overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its variant overlay to OpenLDAP core
…
[View More]
The variant overlay to slapd allows attributes/values to be shared between
several entries. In some ways this is similar to slapo-collect with the
exception that the source and target attributes can be different.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10087
Issue ID: 10087
Summary: slapd crashes with core dump Assertion
`!LDAP_BACK_CONN_TAINTED( lc )
Product: OpenLDAP
Version: 2.5.15
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: …
[View More]rajko(a)albrecht.jetzt
Target Milestone: ---
The slapd daemon crashes every ten minutes with
slapd: ../../../../../servers/slapd/back-ldap/bind.c:181:
ldap_back_conn_delete: Assertion `!LDAP_BACK_CONN_TAINTED( lc )' failed.
Aborted (core dumped)
I searched around for multiple days but didn't find any solution to this
problem.
I have the same problem with 2.6.x versions.
It is configured to act as caching ldap, while multiple hundred systems contact
it.
The error message is completely useless for sysadmins because they don't
understand what this means for them (as said, asking search engines gives no
answers) nor I don't know if - and if so how - I can fix this with
configuration.
I don't see if this message is talking about the connection to the upstream
ldap server or if this is the connection from a client to the caching (and
crashing) daemon.
First setup was plain on a linux machine, now runnig inside docker environment
so the service is restarted after the crash. This is of course not a nice
solution.
And it looks like the same like #4390 which is marked as "not solved".
At least a description what this error messages means would be very helpful
incl. how a workaround could look like (increasing timeouts, increase/decrease
a socket pool or whatever).
Currently the slapd is nearly useless when using it as a caching ldap with high
load.
Any hints?
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10058
Issue ID: 10058
Summary: destroying robust mutexes leads to use of an
uninitialized mutex
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: jiri.…
[View More]novosad(a)gmail.com
Target Milestone: ---
Created attachment 966
--> https://bugs.openldap.org/attachment.cgi?id=966&action=edit
an example program to reproduce the bug
This is a regression introduced in
https://bugs.openldap.org/show_bug.cgi?id=9278 .
The issue is that mdb_env_setup_locks initializes the mutex only when it gets
an exclusive fcntl file lock. But there is this possible order of operations:
1. Process A opens the DB, gets an exclusive file lock, initializes the mutex,
downgrades the file lock to shared and does its thing
2. Process A closes the env: it gets an exclusive lock and destroys the mutex
3. Process B opens the DB and blocks in mdb_env_excl_lock trying to get the
shared lock
4. Process A finishes closing the env, closes the file descriptor and loses the
file lock
5. Process B gets the shared lock, does not initialize the mutex in
mdb_env_setup_locks (because it does not have the exclusive lock)
6. Process B tries to lock the mutex, but it is not initialized,
pthread_mutex_lock returns EINVAL
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10086
Issue ID: 10086
Summary: test059 does not set up valid cn=config replication
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: -…
[View More]--
For cn=config replication to be valid, the entryUUIDs must match throughout the
config database. However, this is not the case when test059 executes. The
entryUUID for 'dn: cn=config' differs between the two.
Example:
quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID:
cfcon.d/cn\=config.ldif
entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372
quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID:
db.1.a/cn\=config\,cn\=consumer.ldif
entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10073
Issue ID: 10073
Summary: database monitor | slapd fails to start when "database
ldap" without suffix exists
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
…
[View More]Reporter: cyusedfzfb(a)gmail.com
Target Milestone: ---
As requested on the mailinglist, I am filing an issue for this behaviour:
Today setup the cn=Monitor backend, and after doing so, openldap failed to
start with:
backend_startup_one (type=monitor, suffix="cn=Monitor"): bi_db_open failed!
(-1)
The reason turned out to be: we had configured one of our databases ("database
ldap") without a suffix.
After I added a suffix, openldap started, and cn=Monitor worked as expected.
It would be nice if this error message could become a little bit more specific.
:-)
Also: we've had the "database ldap" without a suffix in production working for
many years. Perhaps cn=Monitor should be able to deal with that config as
well..?
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10067
Issue ID: 10067
Summary: back-meta doesn't like an empty modify
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
A …
[View More]modify like:
dn: <dn>
changetype: modify
sent to a back-meta DB will trigger an assert on ch_malloc(0). The code also
kind of takes liberty at equating free and ch_free, which could backfire under
some (extremely rare) circumstances.
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10081
Issue ID: 10081
Summary: slapacl lists wrong permissions when peername.ip is
used in ACL
Product: OpenLDAP
Version: 2.5.14
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: …
[View More]carsten.jaeckel(a)tu-dortmund.de
Target Milestone: ---
in a testing environment (SLES 15 SP5, OpenLDAP 2.5.14) I use the following
ACLs in olcAccess:
{0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by
dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by *
none {1}to * by group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by *
none break {2}to * by self read by anonymous auth by * none break
If I run ldapmodify -xWD "cn=test,ou=users,dc=foo,dc=bar" to change the account
cn=test,ou=users,dc=foo,dc=bar on the system with ip 10.10.10.10 everything
works as expected.
LDAP-Log:
2023-06-16T12:53:12.024030+02:00 tst1 slapd[1333]: conn=1016 fd=28 ACCEPT from
IP=10.10.10.10:53558 (IP=0.0.0.0:636)
2023-06-16T12:53:12.039643+02:00 tst1 slapd[1333]: conn=1016 fd=28 TLS
established tls_ssf=128 ssf=128 tls_proto=TLSv1.3
tls_cipher=TLS_AES_128_GCM_SHA256
2023-06-16T12:53:12.039773+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND
dn="cn=test,ou=users,dc=foo,dc=bar" method=128
2023-06-16T12:53:12.039841+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND
dn="cn=test,ou=users,dc=foo,dc=bar" mech=SIMPLE bind_ssf=0 ssf=128
2023-06-16T12:53:12.041918+02:00 tst1 slapd[1333]: conn=1016 op=0 RESULT tag=97
err=0 qtime=0.000014 etime=0.002242 text=
2023-06-16T12:53:30.488074+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD
dn="cn=test,ou=users,dc=foo,dc=bar"
2023-06-16T12:53:30.488474+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD
attr=description
2023-06-16T12:53:30.557458+02:00 tst1 slapd[1333]: conn=1016 op=1 RESULT
tag=103 err=0 qtime=0.000022 etime=0.069664 text=
2023-06-16T12:53:33.035486+02:00 tst1 slapd[1333]: conn=1016 fd=28 closed
(connection lost)
Running the above command from another machine results in a Insufficient access
(50) error as also expected.
So I assume the ACLs to be working correctly.
If I run
slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D
cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar on the system
with ip 10.10.10.10 I get the following output:
PROXIED attributeDescription "OU" inserted.
PROXIED attributeDescription "DC" inserted.
authcDN: "cn=test,ou=users,dc=foo,dc=bar"
entry: none(=0)
children: none(=0)
description=test: none(=0)
cn=test: none(=0)
sn=test: none(=0)
objectClass=person: none(=0)
objectClass=top: none(=0)
structuralObjectClass=person: none(=0)
entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: none(=0)
creatorsName=cn=manager,dc=foo,dc=bar: none(=0)
createTimestamp=20230227131940Z: none(=0)
userPassword=****: none(=0)
pwdChangedTime=20230227131959Z: none(=0)
authTimestamp=20230616065542Z: none(=0)
pwdLastSuccess=20230616103806Z: none(=0)
entryCSN=20230616103806.257186Z#000000#000#000000: none(=0)
modifiersName=cn=test,ou=users,dc=foo,dc=bar: none(=0)
modifyTimestamp=20230616103806Z: none(=0)
I expected to see write access in slapacl's output.
If I remove the 'peername.ip="10.10.10.10"' part from olcAccess {0}to
dn.exact="cn=test,ou=users,dc=foo,dc=bar" by
dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by *
none the above slapacl command outputs write access correctly no matter if the
parameter '-o peername=10.10.10.10' is set or not.
olcAccess:
{0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by
dn.exact="cn=test,ou=users,dc=foo,dc=bar" write by * none {1}to * by
group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by * none break {2}to *
by self read by anonymous auth by * none break
slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D
cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar
PROXIED attributeDescription "OU" inserted.
PROXIED attributeDescription "DC" inserted.
authcDN: "cn=test,ou=users,dc=foo,dc=bar"
entry: write(=wrscxd)
children: write(=wrscxd)
description=first test
cn=test: write(=wrscxd)
sn=test: write(=wrscxd)
objectClass=person: write(=wrscxd)
objectClass=top: write(=wrscxd)
structuralObjectClass=person: write(=wrscxd)
entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: write(=wrscxd)
creatorsName=cn=manager,dc=foo,dc=bar: write(=wrscxd)
createTimestamp=20230227131940Z: write(=wrscxd)
userPassword=****: write(=wrscxd)
pwdChangedTime=20230227131959Z: write(=wrscxd)
authTimestamp=20230616065542Z: write(=wrscxd)
pwdLastSuccess=20230616105312Z: write(=wrscxd)
entryCSN=20230616105330.487886Z#000000#000#000000: write(=wrscxd)
modifiersName=cn=test,ou=users,dc=foo,dc=bar: write(=wrscxd)
modifyTimestamp=20230616105330Z: write(=wrscxd)
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]
https://bugs.openldap.org/show_bug.cgi?id=10047
Issue ID: 10047
Summary: slapd SEGV after slapindex -q
Product: OpenLDAP
Version: 2.6.3
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: ---
In an environment …
[View More]where cn=config is replicated:
a) Added an equality index for an existing attribute
b) Stopped slapd after the change to the configuration had been replicated to
the server. The indexing process that was automatically kicked off by this had
been running for ~30 minutes before I stopped slapd
c) ran: slapindex -q -F /path/to/config -b <base> <attr>
d) started slapd
e) segfault
To verify it wasn't an overall data issue, I then:
a) slapcat the database
b) moved the problem database files aside for debugging
c) reloaded the database with slapadd -q
d) everything works fine
I will attach the gdb output to this ticket momentarily
--
You are receiving this mail because:
You are on the CC list for the issue.
[View Less]