https://bugs.openldap.org/show_bug.cgi?id=10299
Issue ID: 10299 Summary: slapacl -u segfaults on nonexistent user Product: OpenLDAP Version: 2.6.9 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs@openldap.org Reporter: ratness@gmail.com Target Milestone: ---
Created attachment 1048 --> https://bugs.openldap.org/attachment.cgi?id=1048&action=edit config.ldif
2.6.9, symas-packaged RPMs, Rocky 9. In slapacl, a rootDN user is, as you'd expect, allowed to do anything:
# /opt/symas/sbin/slapacl -D 'cn=Manager,dc=example,dc=com' -u -b 'uid=fakeuser,ou=users,dc=example,dc=com' entry/write authcDN: "cn=manager,dc=example,dc=com" write access to entry: ALLOWED
But, a user given full-manage rights, segfaults:
# /opt/symas/sbin/slapacl -D 'uid=direct,ou=users,dc=example,dc=com' -u -b 'uid=fakeuser,ou=users,dc=example,dc=com' entry/write authcDN: "uid=direct,ou=users,dc=example,dc=com" Segmentation fault (core dumped)
Traceback:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7135888 in mdb_txn_begin (env=0x0, parent=parent@entry=0x0, flags=flags@entry=131072, ret=ret@entry=0x5555557f4940) at ./../../../libraries/liblmdb/mdb.c:2893 2893 flags |= env->me_flags & MDB_WRITEMAP; Missing separate debuginfos, use: dnf debuginfo-install glibc-2.34-60.el9.x86_64 libevent-2.1.12-6.el9.x86_64 sqlite-libs-3.34.1-6.el9_1.x86_64 (gdb) bt #0 0x00007ffff7135888 in mdb_txn_begin (env=0x0, parent=parent@entry=0x0, flags=flags@entry=131072, ret=ret@entry=0x5555557f4940) at ./../../../libraries/liblmdb/mdb.c:2893 #1 0x00007ffff71361a1 in mdb_opinfo_get (op=op@entry=0x7fffffffdce0, mdb=mdb@entry=0x7ffff7048010, rdonly=rdonly@entry=1, moip=moip@entry=0x7fffffffc410) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/back-mdb/id2entry.c:793 #2 0x00007ffff7136459 in mdb_entry_get (op=0x7fffffffdce0, ndn=0x7fffffffc640, oc=0x5555557a4360, at=0x5555557c3560, rw=0, ent=0x7fffffffc4c8) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/back-mdb/id2entry.c:620 #3 0x00005555555a77a0 in be_entry_get_rw (e=0x7fffffffc4c8, rw=0, at=0x5555557c3560, oc=0x5555557a4360, ndn=0x7fffffffc640, op=0x7fffffffdce0) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1438 #4 fe_acl_group (op=0x7fffffffdce0, target=<optimized out>, gr_ndn=0x7fffffffc640, op_ndn=0x7fffffffde10, group_oc=0x5555557a4360, group_at=0x5555557c3560) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1494 #5 0x000055555559ec5c in backend_group (op=0x7fffffffdce0, target=<optimized out>, gr_ndn=<optimized out>, op_ndn=<optimized out>, group_oc=<optimized out>, group_at=<optimized out>) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/backend.c:1690 #6 0x00005555555bfbc2 in slap_acl_mask (access=ACL_WRITE, state=0x7fffffffc660, count=1, matches=0x7fffffffcab0, val=<optimized out>, desc=<optimized out>, e=0x7fffffffd910, op=0x7fffffffdce0, mask=<synthetic pointer>, prev=0x0, a=0x5555557c3970) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:1643 #7 slap_access_allowed (op=op@entry=0x7fffffffdce0, e=e@entry=0x7fffffffd910, desc=<optimized out>, val=<optimized out>, access=<optimized out>, state=<optimized out>, maskp=<optimized out>) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:288 #8 0x00005555555c1e2e in fe_access_allowed (op=0x7fffffffdce0, e=0x7fffffffd910, desc=<optimized out>, val=<optimized out>, access=<optimized out>, state=<optimized out>, maskp=0x7fffffffd828) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:352 #9 0x00005555555b7c74 in access_allowed_mask (op=0x7fffffffdce0, e=0x7fffffffd910, desc=0x55555573d540, val=<optimized out>, access=ACL_WRITE, state=0x0, maskp=0x7fffffffd900) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/acl.c:456 #10 0x0000555555620182 in slapacl (argc=<optimized out>, argv=0x7fffffffe398) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/slapacl.c:362 #11 0x000055555557658f in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/symas-openldap-2.6.9-1.el9.x86_64/servers/slapd/main.c:540
I could understand it if it was a case of "trying to verify cn/write and not knowing if the user was objectClass=person" but for entry/write I don't see any reason these should be different.
https://bugs.openldap.org/show_bug.cgi?id=10299
--- Comment #1 from Greg ratness@gmail.com --- Created attachment 1049 --> https://bugs.openldap.org/attachment.cgi?id=1049&action=edit db.ldif
https://bugs.openldap.org/show_bug.cgi?id=10299
Greg ratness@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=8456
https://bugs.openldap.org/show_bug.cgi?id=10299
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Target Milestone|--- |2.6.10 Assignee|bugs@openldap.org |ondra@mistotebe.net
https://bugs.openldap.org/show_bug.cgi?id=10299
--- Comment #2 from Ondřej Kuzník ondra@mistotebe.net --- Hi Greg, thanks for the report and configuration. The crash comes down to you having ACLs with group membership testing needs to pull the group entry but with the DB not being initialised due to dry-run (-u) you'll see the crash.
Don't know if there is a way to refuse this if a group ACL is encountered in dry-run mode, Howard?
https://bugs.openldap.org/show_bug.cgi?id=10299
--- Comment #3 from Greg ratness@gmail.com --- This is just a note explaining my thinking, don't take it as advocacy.
In man 8 slapacl, -u and -b 'point at each other', and -u saying "a fake entry with the DN given with the -b option is used" had me to where my interpretation was that -u is scope-limited just to the DN specified in -b. That you then indicated the -rest- of the ACLs aren't looked up, that surprised me.
https://bugs.openldap.org/show_bug.cgi?id=10299
--- Comment #4 from Howard Chu hyc@openldap.org --- (In reply to Greg from comment #3)
This is just a note explaining my thinking, don't take it as advocacy.
In man 8 slapacl, -u and -b 'point at each other', and -u saying "a fake entry with the DN given with the -b option is used" had me to where my interpretation was that -u is scope-limited just to the DN specified in -b. That you then indicated the -rest- of the ACLs aren't looked up, that surprised me.
I don't understand any of your comment at all, but clearly the SEGV is because you have an ACL that references a group and the group entry couldn't be retrieved from the DB because in dryrun mode none of the DBs are opened. If you want this slapacl invocation to work, don't use dryrun mode.
https://bugs.openldap.org/show_bug.cgi?id=10299
--- Comment #5 from Ondřej Kuzník ondra@mistotebe.net --- On Thu, Mar 27, 2025 at 03:15:40PM +0000, openldap-its@openldap.org wrote:
I don't understand any of your comment at all, but clearly the SEGV is because you have an ACL that references a group and the group entry couldn't be retrieved from the DB because in dryrun mode none of the DBs are opened. If you want this slapacl invocation to work, don't use dryrun mode.
The question is:
Is there a way to have slapacl avoid the SEGV but return with an actual error in this case?
https://bugs.openldap.org/show_bug.cgi?id=10299
--- Comment #6 from Howard Chu hyc@openldap.org --- (In reply to Ondřej Kuzník from comment #2)
Hi Greg, thanks for the report and configuration. The crash comes down to you having ACLs with group membership testing needs to pull the group entry but with the DB not being initialised due to dry-run (-u) you'll see the crash.
Don't know if there is a way to refuse this if a group ACL is encountered in dry-run mode, Howard?
Currently no, there's no way to stop the processing. At most we can return an error when trying to process the group ACL, which will only result in ACL processing continuing on to the next defined ACL. As such, you'll get a result from slapacl but it will probably be incorrect.
I guess we could have slapacl pre-check all of the relevant ACLs to see if any of them reference any groups, and fail immediately, when dryrun is specified. There's no relevant code that does any similar check right now.
https://bugs.openldap.org/show_bug.cgi?id=10299
--- Comment #7 from Howard Chu hyc@openldap.org --- (In reply to Ondřej Kuzník from comment #5)
On Thu, Mar 27, 2025 at 03:15:40PM +0000, openldap-its@openldap.org wrote:
I don't understand any of your comment at all, but clearly the SEGV is because you have an ACL that references a group and the group entry couldn't be retrieved from the DB because in dryrun mode none of the DBs are opened. If you want this slapacl invocation to work, don't use dryrun mode.
The question is:
Is there a way to have slapacl avoid the SEGV but return with an actual error in this case?
I think SEGV is a pretty definitive error code already.
We could also just print a message when slapacl starts up saying "using dryrun mode may trigger SEGV if ACL evaluation requires DB access"
https://bugs.openldap.org/show_bug.cgi?id=10299
--- Comment #8 from Howard Chu hyc@openldap.org --- Really I think the first problem is with the slapacl(8) manpage.
The offending text came from this commit 592c4ad2b0cf0a1f4909c06aebb31624a6d7d989
+.TP +.BI -u +do not fetch the entry from the database. +In this case, if the entry does not exist, a fake entry with the DN +given with the +.B -b +option is used, with no attributes.
The first sentence is most relevant: the entry is not fetched from the DB.
The "if the entry does not exist" clause does not belong; a fake entry is used regardless, since we don't even access the DB and therefore have no idea whether the entry exists or not.
https://bugs.openldap.org/show_bug.cgi?id=10299
Howard Chu hyc@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1
--- Comment #9 from Howard Chu hyc@openldap.org --- Proposed fix in https://git.openldap.org/openldap/openldap/-/merge_requests/756
-
openldap-its＠openldap.org