all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH-SERIE pve-access-control/pve-manager/qemu-server] check permissions on local bridge
Date: Tue, 06 Jun 2023 09:31:46 +0200	[thread overview]
Message-ID: <1686036605.tcp2iewvk2.astroid@yuna.none> (raw)
In-Reply-To: <45c767c555473f0969dd1036627c9f9b76d2c340.camel@groupe-cyllene.com>

On June 6, 2023 7:32 am, DERUMIER, Alexandre wrote:
> Le lundi 05 juin 2023 à 12:13 +0200, Fabian Grünbichler a écrit :
>> On June 5, 2023 1:37 am, Alexandre Derumier wrote:
>> > add vnet/localbridge permissions management
>> > 
>> > Hi,
>> > as we has discuted some weeks ago,
>> > this patche serie introduce management of acl for vnets && local
>> > bridges
>> > 
>> > I have reuse current sdn permissions path, to have common paths
>> > 
>> > /sdn/vnets/<zone>/<vnet>
>> > 
>> > where the local vmbr are in a virtual "localnetwork" zone
>> > 
>> > /sdn/vnets/local/<vnet>
>> > 
>> > Vlans permissions  are also handled with
>> > /sdn/vnets/<zone>/<vnet>/<tag>
>> 
>> these paths don't match the patches ;)
>> 
>> if the paths were like this, then we could go one step further and
>> admins could set propagate on the zone to hand out access to the full
>> zone, including all vnets *and* vlan tags, and we could just check
>> the
>> vnet (or vnet+tag), and the zone would be implicitly checked as well
>> (by
>> virtue of traversing the ACL path).
>> 
>> we'd need to check for consistency of zone+vnet when checking ACLs
>> though, which is not required right now.
> oh yes, I think it was my first try. 
> 
> currently the vnets id are unique (and possibly (at least in sdn) user
> could move the vnet between zones. (not implemented, but technically,
> it'll work, and ifreload is able to online replug the vnet with vm
> guest running).
> 
> I don't think it something that user want to do regulary, so maybe it's
> not a problem to use /zone/vnet/tag and It's more secure if users need
> to recheck the acl.

I just wanted to mention it since it caught my eye, treating zones and
vnets as independent also makes sense, it should just be consistent :)


there are pros and cons for both approaches:
- pro for current approach:
-- vnets can be moved/converted between zones, ACLs stay valid
-- no extra checks needed
- pro for zone/vnet/.. approach:
-- propagation from zone to vnet is possible without manually doing it
at the check site
-- binding between zone and vnet is enforced at the ACL level




      parent reply	other threads:[~2023-06-06  7:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-04 23:37 Alexandre Derumier
2023-06-04 23:37 ` [pve-devel] [PATCH pve-access-control 1/2] access control: add /sdn/vnets/<vnet>/<vlan> path Alexandre Derumier
2023-06-04 23:37 ` [pve-devel] [PATCH v2 pve-manager 1/3] add vnet permissions panel Alexandre Derumier
2023-06-04 23:37 ` [pve-devel] [PATCH v2 qemu-server 1/1] api2: add check_bridge_access for create/update vm Alexandre Derumier
2023-06-05  7:38   ` Thomas Lamprecht
2023-06-06  4:20     ` DERUMIER, Alexandre
2023-06-05 10:12   ` Fabian Grünbichler
2023-06-04 23:37 ` [pve-devel] [PATCH v2 pve-manager 2/3] add permissions management for "localnetwork" zone Alexandre Derumier
2023-06-04 23:37 ` [pve-devel] [PATCH pve-access-control 2/2] rpcenvironnment: add check_sdn_bridge Alexandre Derumier
2023-06-05 10:12   ` Fabian Grünbichler
2023-06-06 12:15     ` DERUMIER, Alexandre
2023-06-06 12:37       ` Fabian Grünbichler
2023-06-04 23:37 ` [pve-devel] [PATCH v2 pve-manager 3/3] api2: network: check permissions for local bridges Alexandre Derumier
2023-06-05 10:13 ` [pve-devel] [PATCH-SERIE pve-access-control/pve-manager/qemu-server] check permissions on local bridge Fabian Grünbichler
2023-06-06  5:32   ` DERUMIER, Alexandre
2023-06-06  6:54     ` DERUMIER, Alexandre
2023-06-06  7:43       ` Fabian Grünbichler
2023-06-06  7:31     ` Fabian Grünbichler [this message]

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=1686036605.tcp2iewvk2.astroid@yuna.none \
    --to=f.gruenbichler@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