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.