From: "Daniel Kral" <d.kral@proxmox.com>
To: "David Riley" <d.riley@proxmox.com>, <pve-devel@lists.proxmox.com>
Subject: Re: [PATCH pve-access-control v4 1/5] fix: #7520: sdn: prune orphaned ACLs on resource deletion
Date: Fri, 03 Jul 2026 14:21:20 +0200 [thread overview]
Message-ID: <DJOXK83G71DW.1ADVDOZY4DMRC@proxmox.com> (raw)
In-Reply-To: <8d7a699c-f820-49c0-939b-e4a91668b50d@proxmox.com>
On Fri Jul 3, 2026 at 2:10 PM CEST, David Riley wrote:
> Thanks for the feedback.
> Some comments inline.
>
> On 7/2/26 3:15 PM, Daniel Kral wrote:
>> On Fri Jun 26, 2026 at 12:52 PM CEST, David Riley wrote:
[ snip ]
>>> +sub lookup_acl_node {
>>> + my ($root, $path) = @_;
>>> +
>>> + my $current = $root;
>>> + my $parent = undef;
>>> + my $last_key = undef;
>>> +
>>> + for my $step (@$path) {
>> nit: another patch uses $segment (instead of $step) for the same
>> concept, so it might also make more sense to use the same term here
>> (if this is still needed with the comment below)
>
>
> Good catch. Will adapt this to keep it consistent.
>
>>> + if (defined($current->{children}) && defined($current->{children}->{$step})) {
>>> + $parent = $current;
>>> + $last_key = $step;
>>> + $current = $current->{children}->{$step};
>>> + } else {
>>> + return (undef, undef, undef);
>>> + }
>>> + }
>>> +
>>> + return ($parent, $last_key, $current);
>>> +}
>> If $path is a string, then this could reuse the code from the existing
>> find_acl_tree_node() subroutine. Either adapt it with a
>>
>> return wantarray ? ($node, $parent, $last_key) : $node;
>>
>> or a wrapper
>>
>> sub find_acl_tree_node_full($root, $path) { ... }
>>
>> sub find_acl_tree_node($root, $path) {
>> my ($node) = find_acl_tree_node_full($root, $path);
>>
>> return $node;
>> }
>>
>> No hard feelings here though.
>
>
> I did have a look at the find_acl_tree_node subroutine.
>
> However, it automatically creates intermediate nodes if they do not
> exist. This felt somewhat counterintuitive, as the goal is to remove
> these paths and not create them.
>
> Additionally, I need the parent node so I can call |delete| on that
> specific child key. Adapting find_acl_tree_node to fit my use case
> without breaking existing callers would be quite tricky and not
> worth the regression risk, in my opinion.
>
Yeah, good point about it re-creating the path nodes and not
accidentally breaking existing callers!
If you keep it, then I'd add it next to find_acl_tree_node() (maybe
align with that name, e.g. find_acl_tree_node_with_parent()?) and add a
subroutine comment what it does (differently), so others are aware that
this exists as well.
>
>>> +
>>> my $USER_CONTROLLED_TFA_TYPES = {
>>> u2f => 1,
>>> oath => 1,
next prev parent reply other threads:[~2026-07-03 12:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 10:52 [PATCH access-control/network v4 0/5] fix #7520: sdn: prune orphaned ACLs and handle VNet migrations David Riley
2026-06-26 10:52 ` [PATCH pve-access-control v4 1/5] fix: #7520: sdn: prune orphaned ACLs on resource deletion David Riley
2026-07-02 13:14 ` Daniel Kral
2026-07-03 12:10 ` David Riley
2026-07-03 12:21 ` Daniel Kral [this message]
2026-06-26 10:52 ` [PATCH pve-access-control v4 2/5] fix #7520: test: add unit tests for sdn acl pruning logic David Riley
2026-07-02 13:14 ` Daniel Kral
2026-06-26 10:52 ` [PATCH pve-access-control v4 3/5] fix: #7520: sdn: add VNet ACL migration David Riley
2026-07-02 13:26 ` Daniel Kral
2026-06-26 10:52 ` [PATCH pve-access-control v4 4/5] fix #7520: test: add unit tests for sdn acl migration logic David Riley
2026-06-26 10:52 ` [PATCH pve-network v4 5/5] fix #7520: config: prune orphaned ACLs and relocate moved VNets David Riley
2026-07-02 13:26 ` Daniel Kral
2026-07-03 9:42 ` David Riley
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=DJOXK83G71DW.1ADVDOZY4DMRC@proxmox.com \
--to=d.kral@proxmox.com \
--cc=d.riley@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox