From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: pve-devel@lists.proxmox.com
Subject: [RFC PATCH 0/4] add 'additive' flag to ACL entries
Date: Thu, 16 Jul 2026 01:19:58 +0200 [thread overview]
Message-ID: <20260715232121.1009607-1-t.lamprecht@proxmox.com> (raw)
By default a more specific ACL entry on a deeper path fully replaces the
roles inherited from ancestor paths. That works well for scoped
delegation, but it is awkward when a role should apply to a whole
subtree. Take an auditor group that needs read access everywhere: today
that role has to be repeated on every deeper entry, and it quietly stops
applying as soon as someone adds a more specific ACL below.
I run into this frequently on some of our own infra especially if users
are part of multiple groups.
So, to make this a bit easier this series adds an optional per-entry
'additive' flag. An additive entry's roles are carried down the walk and
merged with more specific entries below instead of being replaced;
NoAccess still dominates. On disk it is a compact '+' option field on
the acl: line, exposed via the API and CLI as a boolean 'additive'.
See the docs patch - especially its Notes section - for some more
details.
Sending as RFC mainly for feedback on the overall semantics and also
happy to bikeshed the name and the on-disk '+' encoding (an extensible
option field, so future flags need no new positional column).
Basic docs and UI integration included to make it a bit more complete
and easier to test.
pve-access-control:
acl: support 'additive' option on ACL entries
api: acl: expose 'additive' flag via GET and PUT
src/PVE/API2/ACL.pm | 75 ++++++++++--
src/PVE/AccessControl.pm | 247 +++++++++++++++++++++++++++++---------
src/test/Makefile | 2 +
src/test/api-acl-test.pl | 223 ++++++++++++++++++++++++++++++++++
src/test/parser_writer.pl | 149 +++++++++++++++++++++++
src/test/perm-test9.pl | 181 ++++++++++++++++++++++++++++
src/test/test9.cfg | 86 +++++++++++++
7 files changed, 898 insertions(+), 65 deletions(-)
pve-manager:
ui: acl: expose the 'additive' ACL flag
www/manager6/dc/ACLView.js | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
pve-docs:
pveum: document 'additive' ACL option
pveum.adoc | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
base-commit: dcda7019c90c550995e784c165c9786d5cef4ed3
--
2.47.3
next reply other threads:[~2026-07-15 23:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-15 23:19 Thomas Lamprecht [this message]
2026-07-15 23:19 ` [RFC PATCH access-control 1/4] acl: support 'additive' option on ACL entries Thomas Lamprecht
2026-07-15 23:20 ` [RFC PATCH access-control 2/4] api: acl: expose 'additive' flag via GET and PUT Thomas Lamprecht
2026-07-15 23:20 ` [RFC PATCH manager 3/4] ui: acl: expose the 'additive' ACL flag Thomas Lamprecht
2026-07-15 23:20 ` [RFC PATCH docs 4/4] pveum: document 'additive' ACL option Thomas Lamprecht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260715232121.1009607-1-t.lamprecht@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.