From: David Riley <d.riley@proxmox.com>
To: Daniel Kral <d.kral@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH pve-access-control v4 3/5] fix: #7520: sdn: add VNet ACL migration
Date: Mon, 6 Jul 2026 14:58:15 +0200 [thread overview]
Message-ID: <f6dff62d-c99e-4feb-8fa5-7f1bd9ce7ac4@proxmox.com> (raw)
In-Reply-To: <DJO4BDT5EIYL.CBBJ8W6UDMQE@proxmox.com>
Thanks. I'll address the nits you have mentioned.
Some comments inline.
On 7/2/26 3:26 PM, Daniel Kral wrote:
> On Fri Jun 26, 2026 at 12:52 PM CEST, David Riley wrote:
>> Moving VNets between zones can lead to stale or orphaned ACL entries.
>> Introduce a migration routine to safely relocate ACLs during VNet
>> moves to maintain configuration integrity.
>>
>> * Conflict Validation: Abort the migration and the SDN apply
>> operation if the destination path has existing permissions. This
>> prevents accidental privilege escalation or overwrites.
>> * Relocation: Move ACLs to the new zone path.
>> * Error Handling: Report both the source and destination paths on
>> failure to guide manual resolution.
>>
>> Link: https://bugzilla.proxmox.com/show_bug.cgi?id=7520
>> Signed-off-by: David Riley <d.riley@proxmox.com>
>> ---
>> src/PVE/AccessControl.pm | 101 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 101 insertions(+)
>>
>> diff --git a/src/PVE/AccessControl.pm b/src/PVE/AccessControl.pm
>> index 10526db..34e56b6 100644
>> --- a/src/PVE/AccessControl.pm
>> +++ b/src/PVE/AccessControl.pm
>> @@ -2020,6 +2020,107 @@ sub lookup_acl_node {
>> return ($parent, $last_key, $current);
>> }
>>
>> +sub migrate_sdn_resource_access {
>> + my ($migrations) = @_; # [ { src_path => [...], dest_path => [...] } ]
>> + if (!defined($migrations) || scalar(@$migrations) == 0) {
>> + return;
>> + }
> nit: it's enough to use
>
> return if !$migrations;
>
> here, because Perl does evaluate $migrations in a scalar context here
> already.
>
>> +
>> + my $migrate_fn = sub {
>> + my $usercfg = cfs_read_file("user.cfg");
>> + my $modified = 0;
>> +
>> + my @prepared_moves;
> nit: initialize with empty array ()
>
>> + for my $migration (@$migrations) {
>> + for my $key (qw(src_path dest_path)) {
>> + if (!defined($migration->{$key}) || ref($migration->{$key}) ne 'ARRAY') {
>> + die "Invalid '$key': must be an array reference.\n";
> die'ing here might be a bit harsh as that is more of a programming error
> and a user cannot resolve that problem... Maybe a warn makes more sense
> or just skipping the current $migration?
It should actually never occur, but yes die'ing might be a little harsh, so a warning
should be enough. I'll skip the current migration if this happens.
>
>> + }
>> + }
>> +
>> + my $src_path = ['sdn', @{ $migration->{src_path} }];
>> + my $dest_path = ['sdn', @{ $migration->{dest_path} }];
> nit: use postfix $migration->{src_path}->@*
>
>> +
>> + my ($src_parent, $src_last_key, $acl_node) =
>> + lookup_acl_node($usercfg->{acl_root}, $src_path);
>> +
>> + if (defined($src_parent) && defined($src_last_key) && defined($acl_node)) {
>> + # probe dest for conflicts
>> + my (undef, undef, $existing_dest_node) =
>> + lookup_acl_node($usercfg->{acl_root}, $dest_path);
>> +
>> + if (acl_tree_has_permissions($existing_dest_node)) {
>> + my $conflict_path = '/' . join('/', @$dest_path);
>> + my $source_path = '/' . join('/', @$src_path);
>> + die
>> + "Destination '$conflict_path' already has permissions configured (Source:"
>> + . " '$source_path'). Please remove the target ACLs manually before"
>> + . " retrying.\n";
> nice for doing this before actually migrating so users can resolve the
> issues and then cleanly commit the newly compiled running config and
> not having any inconsistent state inbetween!
>
>> + }
>> + # stage move
>> + push(
>> + @prepared_moves,
>> + {
>> + src_parent => $src_parent,
>> + src_last_key => $src_last_key,
>> + dest_path => $dest_path,
>> + node => $acl_node,
>> + },
>> + );
>> + }
>> + }
>> +
>> + for my $move (@prepared_moves) {
>> + delete $move->{src_parent}->{children}->{ $move->{src_last_key} };
>> +
>> + my $current = $usercfg->{acl_root};
>> + my @dest_segments = @{ $move->{dest_path} };
>> + my $dest_last_key = pop @dest_segments;
>> +
>> + for my $segment (@dest_segments) {
>> + if (!defined($current->{children}->{$segment})) {
>> + $current->{children}->{$segment} = {};
>> + }
> nit: use post-if here
>
>> + $current = $current->{children}->{$segment};
>> + }
>> + $current->{children}->{$dest_last_key} = $move->{node};
>> +
>> + $modified = 1;
>> + }
>> +
>> + if ($modified) {
>> + cfs_write_file("user.cfg", $usercfg);
>> + }
>> + };
>> +
>> + lock_user_config($migrate_fn, "ACL migration failed");
> nit: prefix "SDN" here too, so it's clear that it's about the SDN ACL
> migration
Intentionally left this out. The error message will still contain the SDN keyword
from the caller.
I felt like it would not add much repeating SDN multiple times here.
Example:
could not commit SDN config: ACL migration failed: Destination '/sdn/zones/zone/vnet' already has permissions configured (Source: '/sdn/zones/ozone/vnet'). Please remove the target ACLs manually before retrying. (500)
>> +}
>> +
>> +# recursively checks a node and all its children for active permissions
>> +sub acl_tree_has_permissions {
>> + my ($node) = @_;
>> +
>> + if (ref($node) ne 'HASH') {
>> + return 0;
>> + }
>> +
>> + for my $key (keys %$node) {
>> + if ($key ne 'children') {
>> + return 1;
>> + }
>> + }
>> +
>> + if (ref($node->{children}) eq 'HASH') {
>> + for my $child_key (keys $node->{children}->%*) {
>> + if (acl_tree_has_permissions($node->{children}->{$child_key})) {
>> + return 1;
>> + }
>> + }
>> + }
>> +
>> + return 0;
>> +}
> maybe acl_tree_has_permissions() could reuse iterate_acl_tree() here?
>
> We also don't seem to do a hash ref check there, so it seems like for
> the already populated ACL tree nodes, there already is a children hash
> ref entry defined, so the check for the for loop might not be needed...
> But I'm not sure about this.
I also considered reusing iterate_acl_tree initially, but decided against it because
it forces a full traversal. In my opinion having a subroutine that returns early when
a permission is found makes more sense in the context that I'm using it.
I do agree with your point about the ref checks and from what I can tell these are
guaranteed to be initialized.
>> my $USER_CONTROLLED_TFA_TYPES = {
>> u2f => 1,
>> oath => 1,
>
>
>
>
>
next prev parent reply other threads:[~2026-07-06 12:58 UTC|newest]
Thread overview: 15+ 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
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-07-06 13:15 ` David Riley
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-07-06 12:58 ` David Riley [this message]
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=f6dff62d-c99e-4feb-8fa5-7f1bd9ce7ac4@proxmox.com \
--to=d.riley@proxmox.com \
--cc=d.kral@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