From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
"Fabian Grünbichler" <f.gruenbichler@proxmox.com>
Subject: [pve-devel] applied: [PATCH access-control] fix #4518: improve ACL computation performance
Date: Mon, 6 Mar 2023 10:42:27 +0100 [thread overview]
Message-ID: <66c708b5-55db-ad60-bbdb-25762fd8160c@proxmox.com> (raw)
In-Reply-To: <20230215094413.196673-1-f.gruenbichler@proxmox.com>
Am 15/02/2023 um 10:44 schrieb Fabian Grünbichler:
> by switching to a tree-based in-memory structure, like we do in PBS.
>
> instead of parsing ACL entries into a hash using the full ACL path as key for
> each entry, parse them into a tree-like nested hash. when evaluating ACLs,
> iterating over all path prefixes starting at '/' is needed anyway, so this is a
> more natural way to store and access the parsed configuration.
>
> some performance data, timing `pveum user permissions $user > /dev/null` for
> various amounts of ACL entries in user.cfg
>
> entries | stock | patched | speedup
> -------------------------------------
> 1k | 1.234s | 0.241s | 5.12
> 2k | 4.480s | 0.262s | 17.09
> 20k | 7m25s | 0.987s | 450.86
>
> similarly, an /access/ticket request such as the one happening on login goes
> down from 4.27s to 109ms with 2k entries (testing with 20k entries fails
> because the request times out after 30s, but with the patch it takes 336ms).
>
> the underlying issue is that these two code paths not only iterate over *all
> defined ACL paths* to get a complete picture of a user's/token's privileges,
> but the fact that that ACL computation for each checked path itself did another
> such loop in PVE::AccessControl::roles().
>
> it is enough to iterate over the to-be-checked ACL path in a component-wise
> fashion in order to handle role propagation, e.g., when looking at /a/b/c/d,
> iterate over
>
> /
> /a
> /a/b
> /a/b/c
> /a/b/c/d
>
> in turn instead of all defined ACL paths.
>
> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
> ---
> we only use(d) $cfg->{acl} in pve-access-control, and the API doesn't expose
> the full parsed user.cfg anywhere, since we have separate endpoints for each
> type of entity stored within, so I don't think this counts as breaking change.
>
> could of course still be post-poned to 8.0 if desired.
>
> src/PVE/API2/ACL.pm | 25 ++++---
> src/PVE/AccessControl.pm | 132 ++++++++++++++++++++++++++----------
> src/PVE/RPCEnvironment.pm | 14 ++--
> src/test/parser_writer.pl | 52 ++++++++++----
> src/test/realm_sync_test.pl | 54 ++++++---------
> 5 files changed, 179 insertions(+), 98 deletions(-)
>
>
applied, thanks!
prev parent reply other threads:[~2023-03-06 9:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-15 9:44 [pve-devel] " Fabian Grünbichler
2023-03-06 9:42 ` Thomas Lamprecht [this message]
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=66c708b5-55db-ad60-bbdb-25762fd8160c@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=f.gruenbichler@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.