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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.