https://bugs.openldap.org/show_bug.cgi?id=10241
Issue ID: 10241
Summary: Crash in mdb_page_search_root()
Product: LMDB
Version: 0.9.24
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: david.komarek(a)whalebone.io
Target Milestone: ---
Hello,
The LMDB is crashing in mdb_page_search_root() on following instruction
`0x7f85221479d2 movzwl 0xa(%rdx),%eax`. This instruction corresponds to
following line in source code -
https://github.com/LMDB/lmdb/blob/LMDB_0.9.24/libraries/liblmdb/mdb.c#L5485
(while access mp_flags in MDB_page structure)
Here is callstack as generated by core dump (without symbols as we're using
package from Ubuntu repositories)
```
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f85221479d2 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
#1 0x00007f8522147d15 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
#2 0x00007f8522148432 in ?? () from /usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
#3 0x00007f8522148a70 in mdb_get () from
/usr/lib/x86_64-linux-gnu/liblmdb.so.0
No symbol table info available.
```
Translation
```
#0 mdb_page_search_root()
#1 mdb_page_search()
#2 mdb_cursor_set()
#3 mdb_get()
```
Registers in time of crash:
```
rax 0x2 2
rbx 0x7ffcd8d2a100 140723946168576
rcx 0x3 3
rdx 0x7f825baf7000 140197860700160
rsi 0x1000 4096
rdi 0x7f851c00f4d0 140209677202640
rbp 0x0 0x0
rsp 0x7ffcd8d29e40 0x7ffcd8d29e40
r8 0x7ffcd8d29e50 140723946167888
r9 0x7f851c00f5b8 140209677202872
r10 0x7f851c003090 140209677152400
r11 0x2ce33e6c02ce33e7 3234497591006606311
r12 0x0 0
r13 0x7ffcd8d2a510 140723946169616
r14 0x79 121
r15 0x7f851c003098 140209677152408
rip 0x7f85221479d2 0x7f85221479d2
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
k0 0x40 64
k1 0xfffff0f0 4294963440
k2 0xff01 65281
k3 0xffffffff 4294967295
k4 0xffffffff 4294967295
k5 0xffffffff 4294967295
k6 0xffffffff 4294967295
k7 0x0 0
```
Our setup is following:
We have single process (running in separate container) which reads and writes
to LMDB. It opens environment with following flags
MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_NOSYNC. The environment contain
several DBs. All DBIs are open with MDB_CREATE flag. Transactions are open
without flags.
On the other hand we have several processes running in the single container,
which are only allowed read (these processes crash). The environment is open
with following flags MDB_NORDAHEAD|MDB_WRITEMAP|MDB_NOTLS|MDB_RDONLY. All DBIs
are open without flags. Transactions are open with MDB_RDONLY flag.
Could you please investigate it? If you will need some other artifacts or
comments, please let me know.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10240
Issue ID: 10240
Summary: Information required about the end of support date for
OpenLDAP ver 2.6.3
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: bluesoulprince(a)gmail.com
Target Milestone: ---
Hi Team,
As we have integrated OpenLDAP 2.6.3 version in our application, we would like
to know the community support availability end of date for this version, to
plan our application maintenance accordingly.
Could you please help us with this information.
Thanks,
Vivek S
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10236
Issue ID: 10236
Summary: fragmentation makes mdb_page_alloc slow
Product: LMDB
Version: 0.9.31
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: aalekseyev(a)janestreet.com
Target Milestone: ---
Created attachment 1022
--> https://bugs.openldap.org/attachment.cgi?id=1022&action=edit
patch is relative to LMDB_0.9.31
It's a known problem that mdb_page_alloc can be slow
when the free list is large and fragmented. [1] [2] [3]
I'm not sure it's known *how* slow it can be.
In our workload we saw a fragmented freelist leading
to a pathological O(n^2) behavior.
To handle a multi-page allocation we iterate loading chunks of the
free list one by one, and at every iteration we do O(n) work to check
if the allocation can succeed.
Even small-ish allocations (tens of pages) are repeatedly hitting
this edge case, with free list growing to ~1000000, and the outer loop
taking ~2000 iterations (10^9 worth of work in total, just to allocate a
few pages).
Even though I'm sure there are ways to avoid hitting this pathological
scenario so much (avoid values larger than 4k, or fix whatever causes
fragmentation), it seems unacceptable to have a performance cliff this bad.
I made a patch to make the allocation take ~O(n*log(n)), by loading
and merging multiple chunks at once instead of doing it one-by-one.
I'd appreciate it if someone could review the patch (attached), improve it,
and/or come up with an alternative fix.
The code in `midl.c` is kinda meme-y, including a contribution from GPT-4o, but
it performs well enough to speed up our pathological workload by ~20x (which is
still ~3x away from the non-fragmented case).
Anyway, the main thing that warrants scrutiny is the change in `mdb.c`:
I understand very little about lmdb internals and I worry that loading
multiple pages at once instead of one-by-one might break something.
[1] issue #8664
[2]
https://lists.openldap.org/hyperkitty/list/openldap-bugs@openldap.org/threa…
[3]
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10239
Issue ID: 10239
Summary: The slapd domain name is inconsistent, synchronization
cannot be modified by the rewrite dn parameter dc.
Product: OpenLDAP
Version: 2.4.44
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: 2458943823(a)qq.com
Target Milestone: ---
/etc/openldap/slapd:
syncrepl rid=002
provider=ldap://172.18.1.1
bindmethod=simple
binddn="cn=Manager,dc=wsc,dc=ls,dc=com"
credentials=lnewnews1tter
searchbase="dc=wsc,dc=ls,dc=com"
schemachecking=off
type=refreshAndPersist
retry="60 +"
rewrite dn "dc=wsc,dc=ls,dc=com" "dc=wsc,dc=slave1,dc=ls,dc=com"
The error is as follows:
66912211 /etc/openldap/slapd.conf: line 281: Error: parse_syncrepl_line: unable
to parse "rewrite"
.
66912211 failed to add syncinfo
slaptest: bad configuration directory!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10222
Issue ID: 10222
Summary: mdb_dump page has outdated information about
user-defined comparison functions
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: tools
Assignee: bugs(a)openldap.org
Reporter: zach.vonler(a)sambanovasystems.com
Target Milestone: ---
Created attachment 1019
--> https://bugs.openldap.org/attachment.cgi?id=1019&action=edit
Patch to mdb_dump man page
The `mdb_dump` man page contains an outdated section warning that databases
created with user-defined comparison functions cannot be dumped and reloaded
without changes to the `mdb_load` program. The `-a` option that was added to
the `mdb_load` program in this commit
https://github.com/openldap/openldap/commit/7796aaebcd1b937233adab5b1f3d3a1…
made it possible to reload such databases, so this patch updates the `mdb_dump`
man page to reflect that.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10147
Issue ID: 10147
Summary: Bind dn is getting malformed inside ldap_sasl_bind
function
Product: OpenLDAP
Version: 2.6.3
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: satishkumar1728(a)gmail.com
Target Milestone: ---
Hi team,
We are using open ldap version 2.6 in one of our application processes.
We are using ldap_sasl_bind function defined in open ldap api to send bind
request to ldap server.
We are passing the dn name to the above function and it is parsing the dn name
as expected.
We have added some print statements inside ldap_sasl_bind function and it is
printing the dn string that we passed to the function.
Also, ldap_sasl_bind function will accept const char pointer to dn as an
argument. So, it cannot modify the dn string inside the function.
But somehow the bind dn is getting malformed and we are getting failed bind
response from the ldap server (invalid DN).
We did some analysis using tcpdump and we found out that the dn string that we
passed to the ldap_sasl_bind function and the dn string from the tcpdump are
different.
We did some code walkthrough of ldap_sasl_bind function and it is observed that
it is doing some ber encoding of dn name inside the function.
We are suspecting that the encoding is not happening properly.
Example dn that we passed to ldap_sasl_bin function: "uid=abc, ou=users,
dc=fds, dc=mr"
Dn name that was captured in tcpdump at source: "uid=abc, o dc= dc= dc= dc=
dc=mr"
Is there any specific reason for the bind DN to get malformed like this inside
ldap_sasl_bind function.
Do you have any observations like this in any scenario. Kindly provide some
inputs to resolve this issue.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10175
Issue ID: 10175
Summary: Secure LDAP is not working on GCC 10.3.0
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: bluesoulprince(a)gmail.com
Target Milestone: ---
Hi Team,
We have recently migrated our C++ application which is using OpenLDAP 2.6 to
GCC version 10.3.0.
We are observing difference in LDAP behavior. The non-secure version of LDAP is
able to return the result in GCC 10.3.0, however when we switch to secure LDAP,
it is not able to return with result.
There was no compilation / build issue observed while building our application.
Our query is, does secure LDAP from OpenLDAP ver 2.6 have any compatibility
issues over GCC 10.3.0?
If there are any issues identified over this version, how to resolve those? in
which version fixes for them are available?
Thanks,
Vivek
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10228
Issue ID: 10228
Summary: config LDAP_BACK_CONN_PRIV_MAX to higher value
Product: OpenLDAP
Version: 2.5.16
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: shaosong.li(a)salesforce.com
Target Milestone: ---
Hi,
LDAP_BACK_CONN_PRIV_MAX parameter is set to 256 by below config,
https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/serv…
Can we set this value to a higher value, such as 7k/10k, which is commonly used
in PingDirectory. Any reason that we set this value to a low value like 256,
thanks.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10138
Issue ID: 10138
Summary: Allow generating multiple nested read transactions
from a write transaction
Product: LMDB
Version: 0.9.30
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Hello,
I have a feature request. Would it be possible to read a database from the
point of view of a non-yet-committed write transaction?
What I want to do is to write a lot of entries into a database, use a couple of
threads to read those entries (using MDB_NOTLS) to generate a lot of new
entries (that will be written to disk and then once the generation is done,
drop the read-transaction handles and write (with MDB_APPEND) those new entries
from disk into LMDB.
This would have been possible if I had committed the first entries, but
unfortunately, it is impossible. I need to do this in the same transaction.
Have a great day,
kero
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10225
Issue ID: 10225
Summary: tlso_session_pinning: will crash if
digest/keyhash.bv_val is not properly initialized over
the lifetime of the function
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: yaneurabeya(a)gmail.com
Target Milestone: ---
tlso_session_pinning(..) does not initialize the `digest` stack memory before
referring to it later on in the function. This can result in a library crash if
(for whatever reason) keyhash.bv_val fails to initialize properly on line 1191
[1].
This issue kind of goes hand in hand with bug 10224.
1.
https://github.com/openldap/openldap/blob/15edb3b30f2b6a3dbdf77cc42d39466d5…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10220
Issue ID: 10220
Summary: Feature Request: new option for append-only write
transaction
Product: LMDB
Version: unspecified
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: xhtang518(a)gmail.com
Target Milestone: ---
My project uses LMDB to store values larger than 100KB, and rarely delete
values. So I can afford wasting some space on free pages, then LMDB can reduce
4KB-write operations and improve write performance when committing write
transactions.
I suppose this feature is not hard to implement: just pretend the free-list is
empty in this transaction if the new option is present.
Is this feature reasonable?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10182
Issue ID: 10182
Summary: slapo-alias doesn't work with static operational
attributes
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
It only checks in rs->sr_operational_attrs which is for dynamically generated
opattrs, and ignores them if they're in the entry itself.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10104
Issue ID: 10104
Summary: Add alias overlay to contrib
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10188
Issue ID: 10188
Summary: autogroup doesn't allow a group to be a member of
another group
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Try setting up autogroup (autogroup-attrset groupOfURLs memberURL member) and
loading the following ldif. You'll notice that neither group is marked as a
member:
dn: cn=test
objectClass: device
dn: cn=group,cn=test
objectClass: mygroupOfURLs
memberURL: ldap:///cn=test??sub?(description=a member)
memberURL: ldap:///cn=test??sub?(description=I'm in)
description: a member
dn: cn=member,cn=test
objectClass: device
description: I'm in
dn: cn=another,cn=test
objectClass: mygroupOfURLs
memberURL: ldap:///cn=test??sub?(objectclass=groupOfURLs)
description: I'm in
Just set up mygroupOfURLs with at least a MAY that includes "cn $ description $
member $ memberURL" somehow, e.g.
objectClass ( NetscapeLDAPobjectClass:33.1
NAME 'mygroupOfURLs'
SUP groupofurls STRUCTURAL
MAY member )
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10172
Issue ID: 10172
Summary: check for writability of directory of logfile during
startup
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Even if the logfile itself is writable, if the enclosing directory is not
writable then slapd won't be able to perform logfile rotation. Check for
this when the logfile is being configured. This will prevent starting up
with a bad config, but we still can't do anything about it if the directory's
perms are changed while slapd is already running. Logging an error message
in that situation would likely fill all disk space with that error message.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10103
Issue ID: 10103
Summary: Contrib OIDs inconsistent
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
When the latest batch of contrib overlays were added, the OIDs list wasn't
updated and OIDs inside the code populated properly.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10197
Issue ID: 10197
Summary: Back-meta and back-asyncmeta add a new target
structure and increase the number of targets even if
uri parsing fails
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
This happens when a new target is added via cn=config. In asyncmeta's case it
can lead to too many connection structures allocated, although it seems
operational.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10204
Issue ID: 10204
Summary: Slapd crashes when attempting to use DN as constraint
attribute
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: eresendiz(a)symas.com
Target Milestone: ---
Created attachment 1016
--> https://bugs.openldap.org/attachment.cgi?id=1016&action=edit
Crash output
When adding a to the constraint overlay with a constraintattribute that
contains a 'dn' filter the slapd process crashes. Please see below for more
detail.
Very readily produceable with any kind of non-existent attribute specified in
the attribute list.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7400
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10193
Issue ID: 10193
Summary: Asyncmeta starts more than one timeout loop per
database
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
By design, there should be always exactly one timeout loop task per database,
it is a balance to make sure timeout checks do not throttle traffic processing.
For some reason, there seems to be more than one. This is only visible if slapd
is started with -dasyncmeta log level.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10207
Issue ID: 10207
Summary: configure: Syntax error: Unterminated quoted string
(2.6.8 (RE26))
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: FreeBSD
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: brett(a)gladserv.com
Target Milestone: ---
Created attachment 1017
--> https://bugs.openldap.org/attachment.cgi?id=1017&action=edit
Patch for configure.ac
Testing RE26 (2.6.8)
On FreeBSD and NetBSD, configure fails with the following error:
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
./configure: 13865: Syntax error: Unterminated quoted string
Patch for configure.ac attached.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10161
Issue ID: 10161
Summary: Move nested group support to its own overlay
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Adding the feature to dynlist has made that code overly complex, along with
killing performance.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10185
Issue ID: 10185
Summary: autogroup doesn't populate members in newly added
dynamic groups
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
This was broken in 316afb1190c4fa8d96dc56b38b41f4a6ffb163e9 ITS#6970
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10183
Issue ID: 10183
Summary: ldapadd jump option
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Same as the jump option added for slapadd in ITS#4555. Should have been added
long ago.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10167
Issue ID: 10167
Summary: slapo-memberof should have a way of reacting to a
member entry being added after group referencing it
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: ---
If a group (with member: values) is added before the member entries exist, the
memberof values never get populated. This can happen e.g. during replication.
No idea how it meshes with the refint functionality of memberof if it's indeed
reconcilable at all.
Silly example (Hird's memberof will be empty):
```ldif
dn: cn=GNU,ou=Groups,dc=example,dc=com
objectClass: groupOfNames
member: cn=Hurd,ou=Groups,dc=example,dc=com
dn: cn=Hurd,ou=Groups,dc=example,dc=com
objectClass: groupOfNames
member: cn=Hird,ou=Groups,dc=example,dc=com
member: cn=Roger Rabbit,ou=People,dc=example,dc=com
dn: cn=Hird,ou=Groups,dc=example,dc=com
objectClass: groupOfNames
member: cn=Tweety Bird,ou=People,dc=example,dc=com
member: cn=Hurd,ou=Groups,dc=example,dc=com
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10186
Issue ID: 10186
Summary: Overlay response callbacks should ignore op->o_abandon
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Overlays that need to perform other DB write operations in their response
callbacks usually create a new Operation by copying the existing *op. If the op
had its o_abandon flag set, then every op the overlay starts will be
immediately abandoned instead of executing. They should zero out the
op->o_abandon flag, because the fact that the response callback got invoked
means the original operation already completed. If the main op actually
observed the abandon request, the response callbacks wouldn't have gotten
triggered.
This in particular affects the memberof overlay, which must perform other
modifications after the main op completes. It also affects the contrib
autogroup overlay. It might be relevant for accesslog as well, but I haven't
looked at that yet.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10176
Issue ID: 10176
Summary: new atexit() call to atexit(ldap_exit_tls_destroy) in
2.5.17 crashes AIX application
Product: OpenLDAP
Version: 2.5.17
Hardware: Other
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: philip.miloslavsky(a)gmail.com
Target Milestone: ---
We have a long standing openldap application that's being ported from 2.4.58 to
2.5.17.
On ppc AIX (but not on linux for which we also build), when we exit the main
application we get a crash in exit() because it is trying to run the atexit
which LDAP regsitered, but ldap has already been unloaded and the unloading
caused that atexit function pointer to become zero.
So I tracked it to this line of code in ldap 2.5.17 that was not there in
2.4.58
libraries/libldap/tls2.c: atexit( ldap_exit_tls_destroy );
If I remove that line of code, my issue goes away.
So, now on to dlcose and atexit.
So we have a main kernel (irisdb), a C++ library (ldap.so) that we wrote that
calls ldap client libraries, and the 2 actual openldap libraries which ldap.so
is linked against.
During irisdb exit (the h command)
irisdb does call dlclose on ldap.so, which as a side effect results in the
unloading of the 2 official openldap libraries, but no one calls unatexit() (on
the 0x09001000a04947a8 below).
After the 3 libraries are unloaded, the atexit registration is still there but
its been replaced with zeroes. At what point in this process should we call
unatexit or some LDAP function and why does this sequence of events work right
on linux but not AIX?
[5] stop in ldap_unbind_s
(dbx) c
[1] stopped in unload_sharedlib at line 7793 in file
"/nethome/pmilosla/perforce/projects/OpenLDAP4/kernel/common/src/cdzf.c" ($t1)
7793 if (!libptr)
(dbx) where
unload_sharedlib(libptr = 0x0000000000000004), line 7793 in "cdzf.c"
UnloadZFETable(zfetabdescp = 0x0a00010000032790), line 7346 in "cdzf.c"
ResetZFETable(), line 7940 in "cdzf.c"
zfrundown(), line 10135 in "cdzf.c"
chsub2(), line 3480 in "dmisc2.c"
chalt(flag = 1), line 3222 in "dmisc2.c"
Chaltcmd(), line 3146 in "dmisc2.c"
(dbx) p zfetabdescp->fnameptr
"/home/gavlak/gavlakcre7424/bin/ldap.so"
(dbx) 0x09001000a04947a8/2x
0x09001000a04947a8: 0900 0000
(dbx) 0x09001000a04947a8/4x
0x09001000a04947a8: 0900 0000 0491 8ec0
(dbx) c
[3] stopped in dlclose at 0x90000000029da40 ($t1)
0x90000000029da40 (dlclose) 7c0802a6 mflr r0
(dbx) where
dlclose(0x4) at 0x90000000029da40
unload_sharedlib(libptr = 0x0000000000000004), line 7804 in "cdzf.c"
UnloadZFETable(zfetabdescp = 0x0a00010000032790), line 7346 in "cdzf.c"
ResetZFETable(), line 7940 in "cdzf.c"
zfrundown(), line 10135 in "cdzf.c"
chsub2(), line 3480 in "dmisc2.c"
chalt(flag = 1), line 3222 in "dmisc2.c"
Chaltcmd(), line 3146 in "dmisc2.c"
(dbx) p zfetabdescp->fnameptr
"/home/gavlak/gavlakcre7424/bin/ldap.so"
(dbx) c
[2] stopped in exit at 0x9000000002524a0 ($t1)
0x9000000002524a0 (exit) 7c0802a6 mflr r0
(dbx) 0x09001000a04947a8/4x
0x09001000a04947a8: 0000 0000 0000 0000
(dbx) c
Illegal instruction in . at 0x0 ($t1)
0x0000000000000000 00000000 Invalid opcode.
(dbx) where
.() at 0x0
exit(??) at 0x900000000252610
syshalt(a = 0), line 6925 in "emisc.c"
chalt(flag = 1), line 3227 in "dmisc2.c"
Chaltcmd(), line 3146 in "dmisc2.c"
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10170
Issue ID: 10170
Summary: accesslog breaks if internal ops done in startup
Product: OpenLDAP
Version: 2.5.17
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
If some other overlay performs some internal operations in its db_open handler,
before all DBs and overlays are fully initialized, and accesslog_response is
invoked, it may crash if its logDB hasn't been initialized yet.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10044
Issue ID: 10044
Summary: dynlist sometimes crashes when a search operation is
abandoned
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: ---
Playing with the DB provided in ITS#10041 on master, interrupting the
ldapsearch sometimes leads to a slapd crash. It's not 100% repeatable and the
debugger shows dynlist_search2resp touching memory freed by
dynlist_search_cleanup already, which doesn't make sense. Might be something
else is happening at the same time.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10165
Issue ID: 10165
Summary: back-meta fails to bind to target when proxying an
internal operation
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
When the target is configured as follows:
idassert-bind bindmethod=sasl saslmech=EXTERNAL authz=proxyauthz flags=override
and an overlay issues an internal operation, back-meta attempts to open a new
connection to the target, but the bind fails, so the internal operation cannot
be executed.
The target server returns the following error (as logged by back-meta):
<unauthenticated bind (DN with no password) disallowed>
Example configuration of the target server:
authz-regexp gidNumber=.*\+uidNumber=.*,cn=peercred,cn=external,cn=auth
cn=config
logfile ./main.log
database config
database mdb
directory ./main
rootdn cn=config
suffix o=example.com
overlay accesslog
logdb cn=log
logops writes
logsuccess true
database mdb
suffix cn=log
directory ./log
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10173
Issue ID: 10173
Summary: Accesslog bootstrap doesn't populate minCSN internally
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: ---
When a new accesslog DB is being set up from zero but a main DB exists, the
correct minCSN is pushed into the auditContainer entry but li_mincsn et al are
not set up internally. Fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10211
Issue ID: 10211
Summary: uid or gid >= 2^31 can crash slapd when performing
peercred auth
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nick(a)portercomputing.co.uk
Target Milestone: ---
Created attachment 1018
--> https://bugs.openldap.org/attachment.cgi?id=1018&action=edit
Patch to resolve issue
If a user with uid or gid >= 2^31 performs peercred authentication, slapd can
crash due to incorrect formatting of uid and gid when producing the authid
string.
uid and gid are unsigned int values, but are currently cast to int and printed
with %d. This results in values >= 2^31 being printed as negatives, which is
wrong, and for some values that will result in a string longer than the space
which has been allocated due to the addition of the leading '-'.
The issue can be reproduced by attempting a peercred auth from a user with uid
and gid 2649996510 - which will currently be printed as -1644970786.
Attached is a patch which rectifies this.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10206
Issue ID: 10206
Summary: smbk5pwd.c: implicit declaration of function
'kadm5_s_init_with_password_ctx'
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
smbk5pwd.c: In function ‘smbk5pwd_modules_init’:
smbk5pwd.c:917:23: warning: implicit declaration of function
‘kadm5_s_init_with_password_ctx’; did you mean ‘kadm5_init_with_password_ctx’?
[-Wimplicit-function-declaration]
917 | ret = kadm5_s_init_with_password_ctx( context,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| kadm5_init_with_password_ctx
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10177
Issue ID: 10177
Summary: back-perl build for clang15
Product: OpenLDAP
Version: 2.5.17
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
back-perl cannot be built with clang15 on RHEL9.
The following error occurs:
```
libtool: link: clang -shared -fPIC -DPIC .libs/init.o .libs/search.o
.libs/close.o .libs/config.o .libs/bind.o .libs/compare.o .libs/modify.o
.libs/add.o .libs/modrdn.o .libs/delete.o .libs/version.o -Wl,-rpath
-Wl,/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/libldap/.libs
-Wl,-rpath
-Wl,/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs
-Wl,-rpath -Wl,/usr/local/lib
-L/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs
-L/usr/local/lib -L/usr/lib64/perl5/CORE -lperl -lpthread -lresolv -ldl -lm
-lcrypt -lutil ../../../libraries/libldap/.libs/libldap.so
/home/hamano/tmp/openldap-2.5.17/build-clang15/libraries/liblber/.libs/liblber.so
-lsasl2 -lssl -lcrypto ../../../libraries/liblber/.libs/liblber.so -g -O0
-Wl,--enable-new-dtags -Wl,-z -Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -Wl,-z
-Wl,relro -Wl,--as-needed -Wl,-z -Wl,now -fstack-protector-strong -Wl,-soname
-Wl,back_perl-2.5.so.0 -o .libs/back_perl-2.5.so.0.1.12
.libs/init.o: file not recognized: file format not recognized
clang-15: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [Makefile:348: back_perl.la] Error 1
make: Leaving directory
'/home/hamano/tmp/openldap-2.5.17/build-clang15/servers/slapd/back-perl'
```
The cause is that the `-flto=auto` flag prevents the generation with ELF
format.
```
$ file servers/slapd/back-perl/.libs/init.o
servers/slapd/back-perl/.libs/init.o: LLVM IR bitcode
```
I'll open gitlab PR.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10208
Issue ID: 10208
Summary: build test failure: test076-authid-rewrite (2.6.8
(RE26)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: brett(a)gladserv.com
Target Milestone: ---
Testing RE26 on Gentoo Linux. Test 076 fails with "generic failure: internal
error: failed to init cipher 'rc4'"
>>>>> 00:07:19 Starting test076-authid-rewrite for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests
Using ldapsearch to check that slapd is running...
Checking whether DIGEST-MD5 is supported...
Adding schema and database...
Using ldapadd to populate the database...
Adding olcAuthzRegexp rule for static mapping...
Testing ldapwhoami as Manager...
ldap_sasl_interactive_bind: Local error (-2)
additional info: SASL(-1): generic failure: internal error: failed to
init cipher 'rc4'
ldapwhoami failed (254)!
>>>>> 00:07:20 Failed test076-authid-rewrite for mdb after 1 seconds
(exit 254)
make[2]: *** [Makefile:320: mdb-yes] Error 254
make[2]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests'
make[1]: *** [Makefile:287: test] Error 2
make[1]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests'
make: *** [Makefile:298: test] Error 2
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10209
Issue ID: 10209
Summary: OpenBSD Build failure (2.6.8 (RE26)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: brett(a)gladserv.com
Target Milestone: ---
Build failure on OpenBSD 7.2. NB: OpenBSD uses LibreSSL, not OpenSSL, and I
have no idea if that's supported, but configure should at least pick that up I
think.
libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c
tls_o.c -fPIC -DPIC -o .libs/tls_o.o
tls_o.c:228:19: error: use of undeclared identifier 'OPENSSL_INIT_NO_ATEXIT'
OPENSSL_init_ssl(OPENSSL_INIT_NO_ATEXIT, NULL);
^
1 error generated.
*** Error 1 in libraries/libldap (Makefile:432 'tls_o.lo')
*** Error 2 in libraries (Makefile:317 'all-common': @for i in liblutil
liblber liblunicode libldap librewrite ; do echo " Entering
...)
*** Error 2 in /home/bacs/openldap-OPENLDAP_REL_ENG_2_6 (Makefile:325
'all-common': @for i in include libraries clients servers tests doc ; ...)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10214
Issue ID: 10214
Summary: Reduce library dependencies
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
Currently, slapd links libsystemd to notify service state to systemd.
However, libsystemd link several unnecessary libraries, which increases
security risks.
The systemd documentation provides a method to send state notifications to
systemd using a simple protocol without the need to link against libsystemd.
https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html
I propose removing libsystemd and its depended libraries, similar to the
approach taken by OpenSSH.
Applying this fix reduced the following ten dependencies in the RHEL 8
environment.
- libsystemd.so.0
- libblkid.so.1
- libcap.so.2
- libgcc_s.so.1
- libgcrypt.so.20
- libgpg-error.so.0
- liblz4.so.1
- liblzma.so.5
- libmount.so.1
- librt.so.1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10179
Issue ID: 10179
Summary: back-asyncmeta(5) man page incorrectly mentions
"rewrite"
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Man page for back-asyncmeta mentions the rewrite options, yet asyncmeta does
not support the rewrite engine at the moment.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10164
Issue ID: 10164
Summary: back-meta hangs when used with dynlist overlay
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
When back-meta is configured with the dynlist overlay, on a search request that
triggers dynlist, it will hang. This happens because of a bug in back-meta that
is only revealed when an overlay issues an internal operation while processing
a result or an entry, as dynlist does, as apposed to issuing it when the client
op is first received ( on the way "down" to the backend).
The issue is reproduced by configuring dynlist over a back-meta database, and
sending a subtree search request with the database suffix as dn.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10216
Issue ID: 10216
Summary: Channel binding enforced on AD with AD cert using
EDCSA-SHA384 fails
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
Secure LDAP connections to the target Windows server 2019 DC began failing
after the Windows Server DC certificate was updated to an Elliptic Curve Public
Key (384 bits) with the sha384ECDSA signature algorithm and sha384 signature
hash algorithm specified.
The connections were previously successful when the Windows server DC
certificate specified an RSA Public Key certificate with signature algorithm
sha256RSA and signature hash algorithm sha256 specified.
Once the Windows server domain controller certificate is upgraded to the ECC
public key, subsequent secure ldap connection attempts fail.
If channel binding is turned off on the Windows AD target server, secure ldap
connections will succeed using starttls.
If Windows server domain controller certificate is upgraded to ECC public key
and ldap channel binding is enforced, subsequent secure ldap connection
attempts fail with this error message:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: 80090346: LdapErr: DSID-0C09070F, comment:
AcceptSecurityContext error, data 80090346, v4563
Expected results:
Kerberos SASL should work with STARTTLS even when AD certificate is ECC and
SASL_CBINDING is set to "tls-endpoint"
Actual results:
Kerberos SASL only works with STARTTLS even when AD certificate is RSA and
SASL_CBINDING is set to "tls-endpoint"; it fails when AD certificate is ECC
Additional information:
According to the OpenSSL maintainer, there might be a bug in the OpenLDAP code:
it uses EVP_get_digestbynid() to find a digest algorithm based on the signature
algorithm, but there might be no such mapping in EC compared to the RSA case.
OpenLDAP needs to use OBJ_find_sigid_algs() to find the right algorithm.
Possibly, this is the failing code:
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/…
Instead of X509_get_signature_nid() OpenLDAP code probably should call
something like OBJ_find_sigid_algs(X509_get_signature_nid(cert), &md_nid,
&pk_nid).
The former only supports mapping for a few known signature algorithms, but
everything did work, most likely due to a fallback to sha256 in case the digest
wasn't really found.
Judging by https://github.com/openssl/openssl/issues/14278 and
https://github.com/openssl/openssl/issues/14467, a better API is coming but not
currently available (and as it was in the state for a few years, it probably
won't be coming soon)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10212
Issue ID: 10212
Summary: read-only tools may use wrong meta page
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
On a quiescent database that's only used for read-only txns, the txnid won't be
initialized so it remains set to zero. Then only meta page zero will get used,
even if page one is newer. Thus all information retrieved will be stale by one
txn.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9921
Issue ID: 9921
Summary: Tautology in clients/tools/common.c:print_vlv()
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm…
contains:
tool_write_ldif( ldif ? LDIF_PUT_COMMENT : LDIF_PUT_VALUE,
ldif ? "vlvResult" : "vlvResult", buf, rc );
The second parameter is always vlvResult, irrespective of the value of ldif.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10215
Issue ID: 10215
Summary: [QUESTION] FIPS Validated password hashing
Product: OpenLDAP
Version: 2.4.54
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 11tete11(a)gmail.com
Target Milestone: ---
Hi! we are in process of a certification, and we are using openldap of ubuntu
pro fips 20.04, that its the 2.4.54
At some point the auditor ask us, how the passwords are stored into ldap, and
we found this:
https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass…
seems that that module do not use a FIPS validated library like "openssl" that
comes with ubuntu fips. and make it's own implementation of the sha512.
Is there any ldap module that uses the openssl library of the SO that in this
case its the openssl 1.1.1f to hash its passwords?, could be this
https://github.com/openldap/openldap/tree/master/contrib/slapd-modules/pass…
maybe if i'm understanding right?
thx!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10198
Issue ID: 10198
Summary: Crash in mdb_strerr on Windows
Product: LMDB
Version: unspecified
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: b.koch(a)beckhoff.com
Target Milestone: ---
The call to FormatMessageA in mdb_strerr crashes on Windows 10 for error code
112 (disk full).
Its "Arguments" parameter is an invalid pointer. The documentation says that
the parameter should be ignored because of FORMAT_MESSAGE_IGNORE_INSERTS but my
copy of Windows disagrees. Documentation for FormatMessageA:
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-form…
The error is (with addresses replaced by <...>):
Exception thrown at <RtlFormatMessageEx> (ntdll.dll) in
ConsoleApplication1.exe: 0xC0000005: Access violation reading location
<buf+8*1024>.
Trivial fix: Change the last parameter to NULL (in this call:
https://github.com/LMDB/lmdb/blob/8645e92b937794c06f0c66dfae64e425a085b6cd/…)
Bug 8361 is raising some additional issues in this code and it implies that the
va_list is somehow related to the padding hack (but I don't understand how that
is, to be honest), so I'm not sure whether the trivial fix would be fine.
Here is some code to reproduce the crash outside of liblmdb (tested with Visual
Studio 2022, x86 and x64, C++ console project):
#include <iostream>
#include <windows.h>
int main()
{
std::cout << "Hello World!\n";
char buf[1024];
FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, 112, 0, buf, sizeof(buf), (va_list*)buf + 1024);
char* msg = buf;
std::cout << msg;
}
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10210
Issue ID: 10210
Summary: ldapurl manpage references options that no longer
exist
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
-h ldaphost
Set the host.
-p ldapport
Set the TCP port.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10195
Issue ID: 10195
Summary: permissive modify control without value
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: lesignor(a)cirad.fr
Target Milestone: ---
Hello,
A windows ldap client (dotnet) format the request with oid permissive modify
control like this :
00d0 30 84 00 00 00 1e 04 17 ........0.......
00e0 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 2e 31 1.2.840.113556.1
00f0 2e 34 2e 31 34 31 33 01 01 ff 04 00 .4.1413.....
The last 2 bytes 04 00 seems to indicate no value (length of value = 0 ?).
With openldap 2.4.x this request was accepted.
With openldap 2.5.x or openldap 2.6.x, this request is rejected for invalid
protocol with error message : permissiveModify control value not absent
With ldapmodify from openldap, the same request is formatted without the last 2
bytes and is accepted.
Could it be possible to accept request with control without value formatted
with 04 00 to indicate no value ?
It will help to migrate from openldap 2.4.x to 2.5.x or 2.6.x
Thanks
--
You are receiving this mail because:
You are on the CC list for the issue.