From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id A202E8DAD6 for ; Wed, 9 Nov 2022 14:28:45 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 80B781C978 for ; Wed, 9 Nov 2022 14:28:45 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Wed, 9 Nov 2022 14:28:44 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id BD9A74314A for ; Wed, 9 Nov 2022 14:28:43 +0100 (CET) Date: Wed, 09 Nov 2022 14:28:36 +0100 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Dominik Csapak , Proxmox VE development discussion References: <20220920125041.3636561-1-d.csapak@proxmox.com> <20220920125041.3636561-18-d.csapak@proxmox.com> <1667995675.8a5847bwnj.astroid@yuna.none> <1d2d1b03-7ff7-792b-d021-59c7c7c2a97c@proxmox.com> In-Reply-To: <1d2d1b03-7ff7-792b-d021-59c7c7c2a97c@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.16.0 (https://github.com/astroidmail/astroid) Message-Id: <1667999886.rcarxnfy7f.astroid@yuna.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.141 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [qemu.pm] Subject: Re: [pve-devel] [PATCH qemu-server v3 08/13] PVE/API2/Qemu: add permission checks for mapped pci devices X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2022 13:28:45 -0000 On November 9, 2022 1:51 pm, Dominik Csapak wrote: >=20 > On 11/9/22 13:14, Fabian Gr=C3=BCnbichler wrote: >> On September 20, 2022 2:50 pm, Dominik Csapak wrote: >>> Signed-off-by: Dominik Csapak >>> --- >>> PVE/API2/Qemu.pm | 54 ++++++++++++++++++++++++++++++++++++++++++++++-= - >>> 1 file changed, 52 insertions(+), 2 deletions(-) >>> >>> diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm >>> index 7afd7a4..d6d393f 100644 >>> --- a/PVE/API2/Qemu.pm >>> +++ b/PVE/API2/Qemu.pm >>> @@ -26,6 +26,7 @@ use PVE::QemuServer::Drive; >>> use PVE::QemuServer::ImportDisk; >>> use PVE::QemuServer::Monitor qw(mon_cmd); >>> use PVE::QemuServer::Machine; >>> +use PVE::QemuServer::PCI; >>> use PVE::QemuServer::USB qw(parse_usb_device); >>> use PVE::QemuMigrate; >>> use PVE::RPCEnvironment; >>> @@ -603,6 +604,26 @@ my $check_vm_create_usb_perm =3D sub { >>> return 1; >>> }; >>> =20 >>> +my $check_vm_create_hostpci_perm =3D sub { >>> + my ($rpcenv, $authuser, $vmid, $pool, $param) =3D @_; >>> + >>> + return 1 if $authuser eq 'root@pam'; >>> + >>> + foreach my $opt (keys %{$param}) { >>> + next if $opt !~ m/^hostpci\d+$/; >>> + >>> + my $device =3D PVE::JSONSchema::parse_property_string('pve-qm-hostpci= ', $param->{$opt}); >>> + if ($device->{host} !~ m/:/) { >>=20 >> while thinking about the priv patch I decided to check out the ACL handl= ing as >> well - sorry for not asking earlier about this aspect! >>=20 >> would it make sense to have a prefix for "ID of mapped hardware" instead= of >> claiming "everything that doesn't contain ':'" as namespace? >=20 > i mean we could, but a few downsides come to mind: > * if we prefix the ids in the hardware-map itself, the user always > sees that prefix, which is useless to them, or we have to remove it > everywhere when displaying, which is imho unnecessary work > * if we only prefix it in the vm config, we have to add/remove it > in the gui/cli (or api?) which also means users that edit > the config don't have the direct correlation with the hardware map I meant the latter ;) I think with something like "hw_map:NAME" it would be pretty clear. and yeah, it would need to be added client/GUI side, not in t= he API else it would be really confusing.. > basically, more work for us all around >=20 > for usb devices we actually check the vendor/id/path regex first, then=20 > for spice (which is the only exception to the namespace clash) and > all other values we interpret as mapped devices > (imho the small downside of not being able to name a mapping 'spice' > is worth the work we save by not introducing a prefix/namespace) there is a second downside - we don't have a way to add another non-mapping value that uses a valid (i.e., readable!) name. obviously doesn't matter if= we are sure no such values have to be added in the future (or if we don't care= that we need to encode them in way that makes them live in a different namespace= than the map entry names, which would in turn restrict future extensions of the = name schema there). > we could do the same for pci ids of course, i just used the shortcut > of having ':' >=20 > ofc if you insist on having some separated namespace by prefix (or > similar), i'll implement that, i'm not very attached to the current > implementation ;) no, I don't insist on it - just wanted to make sure it's a conscious decisi= on and not an oversight :) when in doubt, I'd rather err on the side of having= a simple, understandable prefix (preserving future extensibility). what actually originally prompted me was that I find "/hardware/$device->{h= ost}" to be a really weird ACL path, as it's not immediately obvious that "host" = here is overloaded to either mean the original host-hardware-ID or the newly add= ed name of the map entry. having it prefixed with a helper to check for and ex= tract the name would make the code more readable IMHO. >> the same also applies to the USB ACL checks and the other checks in this= patch.. >>=20 >>> + $rpcenv->check_full($authuser, "/hardware/$device->{host}", ['Har= dware.Use']); >>=20 >> this and similar sites would then also be more explicit: >>=20 >> my $hw_id =3D ..; # extract actual ID >> $rpvenv->check_full($authuser, "/hardware/$hw_id", ['Hardware.Use']); >>=20 >>> + $rpcenv->check_vm_perm($authuser, $vmid, $pool, ['VM.Config.HWTyp= e']); >>> + } else { >>> + die "only root can set '$opt' config for non-mapped devices\n"; >>> + } >>> + } >>> + >>> + return 1; >>> +}; >>> + >>> >>> [...]