public inbox for pve-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal