From: "Elias Huhsovitz" <e.huhsovitz@proxmox.com>
To: "Dominik Csapak" <d.csapak@proxmox.com>, <pve-devel@lists.proxmox.com>
Subject: Re: [PATCH manager v2] fix #6735: api: pci: allow mdevscan access via mapping permissions.
Date: Wed, 02 Sep 2026 10:51:44 +0200 [thread overview]
Message-ID: <DL4PAYX5DT9G.ZBNOSACGTRDU@proxmox.com> (raw)
In-Reply-To: <f79a99cb-c6b2-4a98-9e7f-f96bdc6b5720@proxmox.com>
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.
next prev parent reply other threads:[~2026-09-02 8:52 UTC|newest]
Thread overview: 5+ 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 [this message]
2026-09-02 10:56 ` Dominik Csapak
2026-09-03 12:15 ` superseded: " Elias Huhsovitz
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=DL4PAYX5DT9G.ZBNOSACGTRDU@proxmox.com \
--to=e.huhsovitz@proxmox.com \
--cc=d.csapak@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