all lists on lists.proxmox.com
 help / color / mirror / Atom feed
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,
>
>
>
>
>




  reply	other threads:[~2026-07-06 12:58 UTC|newest]

Thread overview: 16+ 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
2026-07-07 12:08 ` superseded: [PATCH access-control/network v4 0/5] fix #7520: sdn: prune orphaned ACLs and handle VNet migrations 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 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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal