all lists on lists.proxmox.com
 help / color / mirror / Atom feed
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 3/5] fix: #7520: sdn: add VNet ACL migration
Date: Thu, 02 Jul 2026 15:26:15 +0200	[thread overview]
Message-ID: <DJO4BDT5EIYL.CBBJ8W6UDMQE@proxmox.com> (raw)
In-Reply-To: <20260626105258.56914-4-d.riley@proxmox.com>

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?

> +                }
> +            }
> +
> +            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

> +}
> +
> +# 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.

> +
>  my $USER_CONTROLLED_TFA_TYPES = {
>      u2f => 1,
>      oath => 1,






  reply	other threads:[~2026-07-02 13:26 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
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 [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=DJO4BDT5EIYL.CBBJ8W6UDMQE@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 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