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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id A048A8DA9F for ; Wed, 9 Nov 2022 13:39:55 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 81D421C1C6 for ; Wed, 9 Nov 2022 13:39:25 +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 13:39:23 +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 5DCBB42FD5 for ; Wed, 9 Nov 2022 13:39:23 +0100 (CET) Message-ID: <18114244-e7e5-d418-a27d-c2ff9d91bd36@proxmox.com> Date: Wed, 9 Nov 2022 13:39:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US To: Proxmox VE development discussion , =?UTF-8?Q?Fabian_Gr=c3=bcnbichler?= References: <20220920125041.3636561-1-d.csapak@proxmox.com> <20220920125041.3636561-7-d.csapak@proxmox.com> <1667994471.zlbn23bpo0.astroid@yuna.none> From: Dominik Csapak In-Reply-To: <1667994471.zlbn23bpo0.astroid@yuna.none> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.016 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 NICE_REPLY_A -0.001 Looks like a legit reply (A) POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes 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. [proxmox.com, rpcenvironment.pm, accesscontrol.pm] Subject: Re: [pve-devel] [PATCH access-control v3 1/1] PVE/AccessControl: add Hardware.* privileges and /hardware/ paths 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 12:39:55 -0000 On 11/9/22 13:05, Fabian Grünbichler wrote: > On September 20, 2022 2:50 pm, Dominik Csapak wrote: >> so that we can assign privileges on hardware level >> >> this will generate a new role (PVEHardwareAdmin) >> >> Signed-off-by: Dominik Csapak >> --- >> src/PVE/AccessControl.pm | 13 +++++++++++++ >> src/PVE/RPCEnvironment.pm | 3 ++- >> 2 files changed, 15 insertions(+), 1 deletion(-) >> >> diff --git a/src/PVE/AccessControl.pm b/src/PVE/AccessControl.pm >> index c32dcc3..9cbc376 100644 >> --- a/src/PVE/AccessControl.pm >> +++ b/src/PVE/AccessControl.pm >> @@ -1080,6 +1080,17 @@ my $privgroups = { >> 'Pool.Audit', >> ], >> }, >> + Hardware => { >> + root => [ >> + 'Hardware.Configure', # create/edit mappings >> + ], >> + admin => [ >> + 'Hardware.Use', >> + ], >> + audit => [ >> + 'Hardware.Audit', >> + ], >> + }, > > I guess the rationale here was that currently hardware is root only, so having > > admin => Configure, > user => Use, > audit => Audit, > > would mean the existing PVEAdmin roles would gain something that was previously > root only? > > note that the current patch still means that for the "Administrator" role > anyway, since that gets *all* defined privileges.. (which might also be > something worthy of calling out somewhere?) yes the idea was that existing roles don't get that privilege, but i did not really find a way to add the privilige and not give it to the administrator role and yes putting it in the admin bucket would mean that pveadmin gets it too > > it still might make sense to put Hardware.Use into the user category for > consistency's sake? also not sure whether it would be worth it to re-think > "Configure" (a bit more explicit) vs. "Modify" (consistent with existing > schema).. Modify is fine by me, i didn't choose it because we don't actually 'modify' the hardware, but yes we modify the hardware configuration putting the use in the user bracket has the side effect that there would be a 'PVEHardwareAdmin' and 'PVEHardwareUser' role with the same privileges, which i did find weird to have this way we only get the PVEHardwareAdmin that can use/see the devices if there is a way to only have 'user' role without the admin one please do tell ;) > >> }; >> >> my $valid_privs = {}; >> @@ -1209,6 +1220,8 @@ sub check_path { >> |/storage/[[:alnum:]\.\-\_]+ >> |/vms >> |/vms/[1-9][0-9]{2,} >> + |/hardware >> + |/hardware/[[:alnum:]\.\-\_]+ >> )$!xs; >> } >> >> diff --git a/src/PVE/RPCEnvironment.pm b/src/PVE/RPCEnvironment.pm >> index 0ee2346..bcf911b 100644 >> --- a/src/PVE/RPCEnvironment.pm >> +++ b/src/PVE/RPCEnvironment.pm >> @@ -187,10 +187,11 @@ sub compute_api_permission { >> nodes => qr/Sys\.|Permissions\.Modify/, >> sdn => qr/SDN\.|Permissions\.Modify/, >> dc => qr/Sys\.Audit|SDN\./, >> + hardware => qr/Hardware\.|Permissiions\.Modify/, > > typo "Permissiions" > >> }; >> map { $res->{$_} = {} } keys %$priv_re_map; >> >> - my $required_paths = ['/', '/nodes', '/access/groups', '/vms', '/storage', '/sdn']; >> + my $required_paths = ['/', '/nodes', '/access/groups', '/vms', '/storage', '/sdn', '/hardware']; >> >> my $checked_paths = {}; >> foreach my $path (@$required_paths, keys %{$usercfg->{acl}}) { >> -- >> 2.30.2 > > > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel > >