[Issue 9718] New: test022 can fail on expiry
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9718
Issue ID: 9718
Summary: test022 can fail on expiry
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
>>>>> Starting test022-ppolicy for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
Using ldapsearch to check that slapd is running...
Testing redundant ppolicy instance...
Using ldapadd to populate the database...
Testing account lockout...
Waiting 13 seconds for lockout to reset...
Testing password expiration
Waiting seconds for password to expire...
sleep: missing operand
Try 'sleep --help' for more information.
Password expiration test failed
>>>>> test022-ppolicy failed for mdb after 43 seconds
(exit 1)
The issue here is apparently that line 122-123 failed to populate the DELAY
variable.
121
122 DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \
123 -b "$USER" -E accountUsability 1.1 | sed -n -e
's/.*expire=\(\d*\)/\1/p'`
124
125 echo "Testing password expiration"
126 echo "Waiting $DELAY seconds for password to expire..."
127 sleep $DELAY
128 sleep 1
--
You are receiving this mail because:
You are on the CC list for the issue.
9 hours, 1 minute
[Issue 9496] New: Some writes missing from database
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9496
Issue ID: 9496
Summary: Some writes missing from database
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: igfoo(a)github.com
Target Milestone: ---
With the attached test program, some of my database writes appear not to
actually be written to the database. For example, a run may look like this:
$ ./run.sh
All done.
All finished
1802 test.txt
foo_200 is missing
bar_200 is missing
foo_404 is missing
bar_404 is missing
foo_407 is missing
bar_407 is missing
The script that I am using to run the program is below. This is using
mdb.master 52bc29ee2efccf09c650598635cd42a50b6ecffe on Linux, with an ext4
filesystem.
Is this an LMDB bug, or is there a bug in my code?
Thanks
Ian
#!/bin/sh
set -e
if ! [ -d lmdb ]
then
rm -rf lmdb
git clone https://github.com/LMDB/lmdb.git
INSTALL_DIR="`pwd`/inst"
cd lmdb/libraries/liblmdb
make install prefix="$INSTALL_DIR"
cd ../../..
fi
gcc -Wall -Werror -Iinst/include loop.c inst/lib/liblmdb.a -o loop -pthread
rm -f test.db test.db-lock
./loop
echo "All finished"
mdb_dump -np test.db > test.txt
wc -l test.txt
for i in `seq 100 999`
do
if ! grep -q "foo_$i" test.txt
then
echo "foo_$i is missing"
fi
if ! grep -q "bar_$i" test.txt
then
echo "bar_$i is missing"
fi
done
--
You are receiving this mail because:
You are on the CC list for the issue.
10 hours, 2 minutes
[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9343
Issue ID: 9343
Summary: Expand ppolicy policy configuration to allow URL
filter
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: ---
Currently, ppolicy only supports a single global default policy, and past that
any policies must be manually added to a given user entry if they are supposed
to have something other than the default policy.
Also, some sites want no default policy, and only a specific subset to have a
policy applied to them.
For both of these cases, it would be helpful if it were possible to configure a
policy to apply to a set of users via a URL similar to the way we handle
creating groups of users in dynlist
--
You are receiving this mail because:
You are on the CC list for the issue.
2 weeks, 6 days
[Issue 9813] New: Incompatibility between remoteauth and ppolicy overlays
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9813
Issue ID: 9813
Summary: Incompatibility between remoteauth and ppolicy
overlays
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: thierry.pubellier(a)paris.fr
Target Milestone: ---
Hi,
We are planning to use OpenLDAP as a proxy for some users in our Active
Directory servers, using remoteauth overlay.
We want this OpenLDAP instance to also implement an account lockout policy,
preventing the lockout on our internal Active Directory servers.
But there seems to be an incompatibility between remoteauth and ppolicy
overlays : remoteauth won't remote authenticate a user if local userPassword
attribute exists, while ppolicy overlay needs this attribute.
Could there be a configuration parameter in ppolicy to allow lockout
checks/modifications (which seemed to be the default behavior of OpenLDAP
before ITS#7089) ?
I can provide a patch if allowed.
Thanks by advance,
Best regards,
Thierry
--
You are receiving this mail because:
You are on the CC list for the issue.
2 weeks, 6 days
[Issue 9880] New: reqStart filter with trailing zeros is truncated, which breaks certain searches
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9880
Issue ID: 9880
Summary: reqStart filter with trailing zeros is truncated,
which breaks certain searches
Product: OpenLDAP
Version: 2.5.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: subbarao(a)computer.org
Target Milestone: ---
Note: ITS#9358 seems to address this very issue, but it doesn't seem to help
this particular case.
Certain range searches with reqStart on the changelog don't work as expected.
For example:
(!(reqStart<=20220707123456.000000Z))
The idea here is to grab all entries strictly greater than the timestamp. But
slapd truncates zeros in this filter, rewriting it to:
(!(reqStart<=20220707123456Z))
As a result, the reqStart=20220707123456.000000Z entry is the first match since
it is greater than 20220707123456Z, which is not the desired behavior.
I was able to reproduce this issue on 2.5.12 as follows:
1) Start the test043-delta-syncrepl test, let it run almost to the end so that
it makes many changes, and then hit ^Z to suspend the script. I waited until
one of the last occurrences of "Waiting 7 seconds for syncrepl to receive
changes".
2) pkill -CONT -f slapd to restart slapd (but not the test script)
3) ldapsearch -x -h localhost:9011 -b cn=log objectclass=top | grep
'^dn:.*.000000Z'
Look for a change with all trailing zeros. It's not as rare as one might think,
I saw at least one trailing-zeros change in two consecutive runs of the test
script. I suppose you could also just create an entry with all trailing zeros
in the accesslog :-)
4) Run a range search to only return changes after that change (I used -z 1 and
-s one so that it would only give me one result):
ldapsearch -x -z 1 -h localhost:9011 -b cn=log -s one
'(!(reqStart<=20220708012121.000000Z))'
If you see the same entry, then the problem is present.
5) Even if you can't have an accesslog entry with all trailing zeros, you can
still do the above search verbatim and look at the slapd log file
testrun/slapd.1.log:
62c7873f.145b4396 0x7fabf14c9700 conn=1011 op=1 SRCH base="cn=log" scope=1
deref
=0 filter="(!(reqStart<=20220708012121Z))"
The filter being rewritten in the server log seems to indicate that trailing
zeros are being truncated somewhere.
--
You are receiving this mail because:
You are on the CC list for the issue.
3 weeks
[Issue 9600] New: Rework lloadd's cn=monitor interface (connections)
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9600
Issue ID: 9600
Summary: Rework lloadd's cn=monitor interface (connections)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
At the moment, most of the lloadd's monitor entries are generated on demand for
the search. To support management of the server and its connections, an entry
should be created when a connection is set up and torn down accordingly.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 month, 2 weeks
[Issue 9920] New: MDB_PAGE_FULL with master3 (encryption) because there is no room for the authentication data (MAC)
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9920
Issue ID: 9920
Summary: MDB_PAGE_FULL with master3 (encryption) because there
is no room for the authentication data (MAC)
Product: LMDB
Version: unspecified
Hardware: x86_64
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: info(a)parlepeuple.fr
Target Milestone: ---
Created attachment 915
--> https://bugs.openldap.org/attachment.cgi?id=915&action=edit
proposed patch
Hello,
on master3, using the encryption at rest feature,
I am testing as follow:
- on a new named database, i set the encryption function with
mdb_env_set_encrypt(env, encfunc, &enckey, 32)
- note that I chose to have a size parameter (The size of authentication data
in bytes, if any. Set this to zero for unauthenticated encryption mechanisms.)
of 32 bytes.
- I add 2 entries on the DB, trying to saturate the first page. I chose to add
a key of 33 Bytes and a value of 1977 Bytes, so the size of each node is 2010
Bytes (obviously the 2 keys are different).
- This passes and the DB has just one leaf_pages, no overflow_pages, no
branch_pages, an a depth of 1.
- If I add one byte to the values I insert (starting again from a blank DB),
then , instead of seeing 2 overflow_pages, I get an error : MDB_PAGE_FULL.
- this clearly should not have happened.
- Here is some tracing :
add to leaf page 2 index 0, data size 48 key size 7 [74657374646200]
add to leaf page 3 index 0, data size 1978 key size 33
[000000000000000000000000000000000000000000000000000000000000000000]
add to branch page 5 index 0, data size 0 key size 0 [null]
add to branch page 5 index 1, data size 0 key size 33
[000000000000000000000000000000000000000000000000000000000000000000]
add to leaf page 4 index 0, data size 1978 key size 33
[000000000000000000000000000000000000000000000000000000000000000000]
add to leaf page 4 index 1, data size 1978 key size 33
[020202020202020202020202020202020202020202020202020202020202020202]
not enough room in page 4, got 1 ptrs
upper-lower = 2020 - 2 = 2016
node size = 2020
Looking at the code, I understand that there is a problem at line 9005 :
} else if (node_size + data->mv_size > mc->mc_txn->mt_env->me_nodemax) {
where me_nodemax is incorrect, as it is not taking into account that some bytes
will be needed for the MAC authentication code, which size is in
env->me_esumsize.
me_nodemax is calculated at line 5349:
env->me_nodemax = (((env->me_psize - PAGEHDRSZ ) / MDB_MINKEYS) & -2)
- sizeof(indx_t);
So I substract me_esumsize with a "- env->me_esumsize" here:
env->me_nodemax = (((env->me_psize - PAGEHDRSZ - env->me_esumsize) /
MDB_MINKEYS) & -2)
- sizeof(indx_t);
I also substract it from me_maxfree_1pg in the line above, and in pmax in line
10435.
I do not know if my patch is correct, but it solves the issue.
Maybe there are other places in the code where the me_esumsize should be
substracted from the available size. By example, when calculating the number of
overflow pages in OVPAGES, it does not take into account me_esumsize, but I
think it is ok, because there is only one MAC for the entire set of OV pages,
and there is room for it in the first OV page.
See the attached proposed patch.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 months
[Issue 9916] New: slapd crashes due to unaligned access in mdb.c on Linux SPARC
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9916
Issue ID: 9916
Summary: slapd crashes due to unaligned access in mdb.c on
Linux SPARC
Product: OpenLDAP
Version: 2.6.3
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: glaubitz(a)physik.fu-berlin.de
Target Milestone: ---
The testsuite of the openldap package in Debian unstable fails on sparc64 with
a "bus error" which indicates an unaligned access [1]:
>>>>> Test succeeded
>>>>> 00:00:02 Finished test000-rootdse for mdb after 1 seconds.
>>>>> 00:00:02 Starting test001-slapadd for mdb...
running defines.sh
Running slapadd to build slapd database...
Bus error
slapadd failed (138)!
>>>>> 00:00:03 Failed test001-slapadd for mdb after 1 seconds
(exit 138)
Building openldap from git and running the affected test with GDB results in
the following backtrace:
(gdb) bt
#0 0x00000100000cc36c in mdb_node_add (mc=0x100004316e8, indx=<optimized out>,
key=0x7feffffe570, data=0x7feffffe560, pgno=0, flags=0)
at ./../../../libraries/liblmdb/mdb.c:7358
#1 0x00000100000d0894 in mdb_cursor_put (mc=0x100004316e8, key=0x7feffffe570,
data=0x7feffffe560, flags=16) at ./../../../libraries/liblmdb/mdb.c:6960
#2 0x00000100000d1224 in mdb_cursor_put (mc=0x10000431560, key=0x7feffffe6b0,
data=0x7feffffe6c0, flags=36) at ./../../../libraries/liblmdb/mdb.c:7007
#3 0x00000100000f0d24 in mdb_dn2id_add (op=0x7feffffea28, mcp=0x10000431560,
mcd=0x100004267a0, pid=<optimized out>, nsubs=<optimized out>,
upsub=<optimized out>, e=0x1000044c6b8) at dn2id.c:141
#4 0x00000100000dd79c in mdb_tool_next_id (op=0x7feffffea28, tid=<optimized
out>, e=0x1000044c6b8, text=0x7feffffec78, hole=<optimized out>)
at tools.c:519
#5 0x00000100000de67c in mdb_tool_entry_put (be=0x100003d9080,
e=0x1000044c6b8, text=0x7feffffec78) at tools.c:731
#6 0x00000100000b72f4 in slapadd (argc=<optimized out>, argv=<optimized out>)
at slapadd.c:453
#7 0x0000010000016858 in main (argc=<optimized out>, argv=0x7fefffff438) at
main.c:540
(gdb)
This was reproduced with:
$ gdb --args /home/glaubitz/openldap/servers/slapd/slapd -Ta -d 0 -f
/home/glaubitz/openldap/tests/testrun/slapadd.conf -l
./testdata/test-ordered.ldif
On the machine gcc202 running Debian on sparc64 in the GCC compile farm. Access
to the machines in the GCC compile farm can be obtained by any developer [2].
> [1] https://buildd.debian.org/status/fetch.php?pkg=openldap&arch=sparc64&ver=...
> [2] https://gcc.gnu.org/wiki/CompileFarm
--
You are receiving this mail because:
You are on the CC list for the issue.
2 months
[Issue 9806] New: MDB_PAGE_FULL on mdb_put
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9806
Issue ID: 9806
Summary: MDB_PAGE_FULL on mdb_put
Product: LMDB
Version: unspecified
Hardware: Other
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: casey(a)rodarmor.com
Target Milestone: ---
I'm using the using latest lmdb from OpenLDAP, commit
e8813b12b6188d5ba5f174ff8726c438c8ca4bfd.
I'm getting an MDB_PAGE_FULL error after calling `mdb_put`. If I delete the
database and perform the same sequence of inserts, I get the same error in on
the same mdb_put.
If there's any information I can provide to help debug this, let me know.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 months
[Issue 9899] New: "cyrus.c" uses non-portable GNU extension for void pointer arithmetics and fails on HP-UX aCC
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9899
Issue ID: 9899
Summary: "cyrus.c" uses non-portable GNU extension for void
pointer arithmetics and fails on HP-UX aCC
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: michael.osipov(a)siemens.com
Target Milestone: ---
On HP-UX with cc: HP C/aC++ B3910B A.06.29 [Oct 18 2016]
tells me
libtool: compile: /opt/aCC/bin/aCC -Ae -g -I../../include -I../../include
-I/opt/ports/include -DLDAP_LIBRARY -c cyrus.c -DPIC -o .libs/cyrus.o
"cyrus.c", line 420: error #3143: arithmetic on pointer to void or function
type
memcpy( cb_data + plen, cbv.bv_val, cbv.bv_len );
^
1 error detected in the compilation of "cyrus.c".
gmake[2]: *** [Makefile:434: cyrus.lo] Error 1
void pointer arithmetics is not valid/undefined and just a GNU extension
supported by GCC or clang.
I was able to reproduce this on FreeBSD clang version 13.0.0
(git@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a303):
osipovmi@deblndw011x:~/var/Projekte/openldap-2.6.3/libraries/libldap
$ cc -std=c17 -I../../include -I../../include -I/usr/local/include
-DLDAP_LIBRARY -c cyrus.c -o cyrus.o -pedantic -Werror
cyrus.c:420:18: error: arithmetic on a pointer to void is a GNU extension
[-Werror,-Wpointer-arith]
memcpy( cb_data + plen, cbv.bv_val, cbv.bv_len );
~~~~~~~ ^
1 error generated.
I am not a daily C hacker, but I guess cb_data needs to be typed to "unsigned
char" just like data from sasl_channel_binding_t
(https://github.com/cyrusimap/cyrus-sasl/blob/cb549ef71c5bb646fe583697ebdc...).
Or at least a malloc with an "unsigned char", save the pointer start address,
copy the prefix, increment by prefix length, copy the channel binding value and
then assign the pointer start address to the output struct.
I will unset SASL_CHANNEL_BINDING for now since it is not required in your AD
environment when SASL GSSAPI with minssf=1 is set.
--
You are receiving this mail because:
You are on the CC list for the issue.
3 months