public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Elias Huhsovitz <e.huhsovitz@proxmox.com>, pve-devel@lists.proxmox.com
Subject: Re: [PATCH manager v2] fix #6735: api: pci: allow mdevscan access via mapping permissions.
Date: Wed, 2 Sep 2026 12:56:05 +0200	[thread overview]
Message-ID: <df1586c0-b351-43db-ad5f-fcd31664a7d3@proxmox.com> (raw)
In-Reply-To: <DL4PAYX5DT9G.ZBNOSACGTRDU@proxmox.com>



On 9/2/26 10:51 AM, Elias Huhsovitz wrote:
> Thanks for the feedback! Just one small stylistic question below.
> 
> On Tue Sep 1, 2026 at 2:27 PM CEST, Dominik Csapak wrote:
>> some comments inline
>>
> 
> [...]
>>> +
>>> +        return PVE::QemuServer::PCI::Mdev::get_mdev_types($id) if ($is_pci_id);
>>> +
>>> +        if (!$rpcenv->check_any($authuser, '/', ['Sys.Audit', 'Sys.Modify'], 1)) {
>>
>> isn't this just $has_global_perms again?
> 
> Sorry, these shouldn't have been here, i formatted the wrong branch by
> mistake. The check is indeeed redundant.
> 
>>> +            $rpcenv->check_any(
>>> +                $authuser,
>>> +                "/mapping/pci/$id",
>>> +                ['Mapping.Use', 'Mapping.Modify', 'Mapping.Audit'],
>>> +            );
>>
>> this was also already checked?
>>
>>
>> IMO these happen because the code flow is not very obvious. Instead
>> of having a bunch of postif clauses, I'd prefer a simpler approach:
>>
>>
>> my $id = ...
>> my $rpcenv = ...
>> my $authuser = ...
>>
>> my $has_global_perms = ...
>> my $is_pci_id = ...
>>
>>
>> if ($is_pci_id)  {
>>      raise_perm_exc if !$has_global_perms;
>>      ...
>> } else {
>>      raise_perm_exc if !$has_global_perms && !check_any(mapping_perms);
>>      ...
>> }
>>
>> with such code, the existing flow and indentation stays the same,
>> and it's clear which branch takes which permissions
>>
>> does that make sense?
> 
> 
> I just have a small question here:
> 
> Do you propse A or B:
> 
> A:
> 
>   if ($is_pci_id)  {
>       raise_perm_exc if !$has_global_perms;
>       # business logic ....
>   } else {
>       raise_perm_exc if !$has_global_perms && !check_any(mapping_perms);
>       # business logic ...
>   }
> 
>   # END OF SUBROUTINE
> 
> B:
> 
>   if ($is_pci_id)  {
>       raise_perm_exc if !$has_global_perms;
>   } else {
>       raise_perm_exc if !$has_global_perms && !check_any(mapping_perms);
>   }
>   
>   # business logic ...
> 
>   # END OF SUBROUTINE
> 
> Becuase i prefer B. It seems much simpler to me since the permission logic and
> business logic aren't intertwined. I would even like to go as far as
> factoring the logic into its own subroutine, since the business logic
> should be completely separate from the authorization.
> 
> C:
> 
>   check_custom_perm($is_pci_id);
> 
>   # business logic ...
> 
>   # END OF SUBROUTINE
> 
> 
> This also doesnt change the business logic, and i can keep the if-else
> statement if you prefer.

Actually i would prefer A, because the two branches are by definition
very different (aside from one permission check), so having it split
up early makes sense to me.

With B and C, we at least have to duplicate one if/else (namely
on the 'is it a pci id or not' and that has a good chance
to diverge in the future (e.g. imagine we introduce a 3rd branch
that needs again different permissions, with A this is
more or less automatic since each branch needs it's own check.

with B and C two different parts of the code have to argue
about the same branching.





      reply	other threads:[~2026-09-02 10:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-27 11:25 [PATCH manager v2] fix #6735: api: pci: allow mdevscan access via mapping permissions Elias Huhsovitz
2026-09-01 12:27 ` Dominik Csapak
2026-09-02  8:51   ` Elias Huhsovitz
2026-09-02 10:56     ` Dominik Csapak [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=df1586c0-b351-43db-ad5f-fcd31664a7d3@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=e.huhsovitz@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal