[pve-devel] [PATCH access-control v3 1/1] PVE/AccessControl: add Hardware.* privileges and /hardware/ paths

[Fabian Grünbichler]

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 at 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).

> 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).