From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <d.csapak@proxmox.com>
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 1D2408DACB
for <pve-devel@lists.proxmox.com>; Wed, 9 Nov 2022 14:23:49 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id F08CB1C835
for <pve-devel@lists.proxmox.com>; Wed, 9 Nov 2022 14:23:48 +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 <pve-devel@lists.proxmox.com>; Wed, 9 Nov 2022 14:23:48 +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 C890A42652
for <pve-devel@lists.proxmox.com>; Wed, 9 Nov 2022 14:23:47 +0100 (CET)
Message-ID: <150929da-a685-a323-e4c8-617cb0dbaa46@proxmox.com>
Date: Wed, 9 Nov 2022 14:23:46 +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: =?UTF-8?Q?Fabian_Gr=c3=bcnbichler?= <f.gruenbichler@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20220920125041.3636561-1-d.csapak@proxmox.com>
<20220920125041.3636561-7-d.csapak@proxmox.com>
<1667994471.zlbn23bpo0.astroid@yuna.none>
<18114244-e7e5-d418-a27d-c2ff9d91bd36@proxmox.com>
<1667998564.0rf5qj5m6h.astroid@yuna.none>
From: Dominik Csapak <d.csapak@proxmox.com>
In-Reply-To: <1667998564.0rf5qj5m6h.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. [accesscontrol.pm, rpcenvironment.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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2022 13:23:49 -0000
On 11/9/22 14:06, Fabian Grünbichler wrote:
> On November 9, 2022 1:39 pm, Dominik Csapak wrote:
>> 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 <d.csapak@proxmox.com>
>>>> ---
>>>> 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
>
> could only be done by manual filtering in create_roles (similar to how the
> SuperUser series does it).
>
ah yes i see it now how we could do that
>> 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
>
> well, it does rather refer to the config entry/hardware map, not the hardware
> itself :)
>
>> 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 ;)
>
> no automatic way ;)
>
> one way out would be to:
> - give Hardware.Configure (/Modify) to the Admin role
> - give Hardware.Use to the User role
> - still require root in addition to Hardware.Configure (until point or major
> release time, where the extra check is dropped and documented in the release notes)
>
> my guess is that most people that currently hand out Administrator (as opposed
> to "just" PVEAdmin) would actually want those users to also be able to configure
> the hardware map anyway.. and no users would get the new role
> "PVEHardwareAdmin" anyway by default, so handing that out is an explicit grant
> of the associated privileges anyway.
>
> also there is the similar can of worms like with SuperUser - any user that can
> change permissions can give themselves or someone else Hardware.Configure (which
> is possibly root-level access if misused?). if we add more "special"
> privileges/roles like that, we might need to have some extension to the acl and
> group membership code paths to handle that better.. but I haven't really thought
> that through yet (at least more extensive docs would be a good idea I think).
mhmm didn't think about that until now. Independent of my patch, is it
really possible to give any privilege when having the privilege on
permissions? shouldn't it be limited to ones own privileges?
iow. why should i be able go give out privilege X when i don't have
that myself? (or am i misunderstanding something here)
if that's the case then there is really no way for now besides keeping
the configuration root only, since with 'modify' you can often do
pretty bad things (like pass through the sata/nvme controller of the
root disk, or taking away the network of the host and of course
make the host system crash by passing through some device that's
necessary for the host)
in that case we can omit the 'Cluster.HWMap.Modify' for now and only
introduce a 'Cluster.HWMap.Use' for users of these root configured
devices
when we decide how we can handle these permission issues, we can still
introduce a new 'Cluster.HWMap.Modify' (imho no point in adding
it now if it does nothing)