all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: "Shannon Sterz" <s.sterz@proxmox.com>
To: "Dominik Csapak" <d.csapak@proxmox.com>,
	"Proxmox Datacenter Manager development discussion"
	<pdm-devel@lists.proxmox.com>,
	"Dietmar Maurer" <dietmar@proxmox.com>
Subject: Re: [pdm-devel] [PATCH proxmox 2/4] access-control: add acl api feature
Date: Fri, 11 Apr 2025 13:40:21 +0200	[thread overview]
Message-ID: <D93S4RWONVOT.35K5MQPHT6OR0@proxmox.com> (raw)
In-Reply-To: <ad8c93a3-11f3-4a55-86f8-ba20e9a50c1c@proxmox.com>

On Fri Apr 11, 2025 at 12:53 PM CEST, Dominik Csapak wrote:
> On 4/11/25 12:29, Shannon Sterz wrote:
>> On Wed Apr 9, 2025 at 2:58 PM CEST, Shannon Sterz wrote:
>>> On Wed Apr 9, 2025 at 1:39 PM CEST, Dominik Csapak wrote:
>>>> On 4/9/25 13:01, Dietmar Maurer wrote:
>>>> maybe something like this for the update case (untested, please verify before using this!):
>>>> (the diff is for pbs, where the code was copied from)
>>>>
>>>> this also includes a reformatted check for the token,non-token, same user checks
>>>> that are IMHO more readable than what we currently have
>>>> with the match, i think it's much more obvious that all cases are handled
>>>>
>>>> ---
>>>>        let user_info = CachedUserInfo::new()?;
>>>>
>>>> -    let top_level_privs = user_info.lookup_privs(&current_auth_id, &["access", "acl"]);
>>>> -    if top_level_privs & PRIV_PERMISSIONS_MODIFY == 0 {
>>>> +    let has_modify_permission = user_info
>>>> +        .check_privs(
>>>> +            &current_auth_id,
>>>> +            &["access", "acl"],
>>>> +            PRIV_PERMISSIONS_MODIFY,
>>>> +            false,
>>>> +        )
>>>> +        .is_ok();
>>>> +
>>>> +    if !has_modify_permission {
>>>>            if group.is_some() {
>>>>                bail!("Unprivileged users are not allowed to create group ACL item.");
>>>>            }
>>>>
>>>>            match &auth_id {
>>>>                Some(auth_id) => {
>>>> -                if current_auth_id.is_token() {
>>>> -                    bail!("Unprivileged API tokens can't set ACL items.");
>>>> -                } else if !auth_id.is_token() {
>>>> -                    bail!("Unprivileged users can only set ACL items for API tokens.");
>>>> -                } else if auth_id.user() != current_auth_id.user() {
>>>> -                    bail!("Unprivileged users can only set ACL items for their own API tokens.");
>>>> +                let same_user = auth_id.user() == current_auth_id.user();
>>>> +                match (current_auth_id.is_token(), auth_id.is_token(), same_user) {
>>>> +                    (true, _, _) => bail!("Unprivileged API tokens can't set ACL items."),
>>>> +                    (false, false, _) => {
>>>> +                        bail!("Unprivileged users can only set ACL items for API tokens.")
>>>> +                    }
>>>> +                    (false, true, true) => {
>>>> +                        // users are always allowed to modify ACLs for their own tokens
>>>> +                    }
>>>> +                    (false, true, false) => {
>>>> +                        bail!("Unprivileged users can only set ACL items for their own API tokens.")
>>>> +                    }
>>>>                    }
>>>>                }
>>>>                None => {
>>>> ---
>>
>> had another think about this, i'd tend towards something like the below.
>> the match statement is a nice idea, but it couples together things that
>> aren't really related. for example, why pull in the
>> `current_auth_id.is_token()` check, but not the `group.is_some()` check?
>> having match statements with tuples like this is making the code more
>> complex. imo, this is simpler:
>>
>> ```rs
>>      let unprivileged_user = CachedUserInfo::new()?
>>          .check_privs(
>>              &current_auth_id,
>>              &["access", "acl"],
>>              access_conf.acl_modify_privileges(),
>>              access_conf.allow_partial_permission_match(),
>>          )
>>          .is_err();
>>
>>      if unprivileged_user {
>>          if group.is_some() {
>>              bail!("Unprivileged users are not allowed to create group ACL item.");
>>          }
>>
>>          let auth_id = auth_id.as_ref().ok_or_else(|| {
>>              format_err!("Unprivileged user needs to provide auth_id to update ACL item.")
>>          })?;
>>
>>          if current_auth_id.is_token() {
>>              bail!("Unprivileged API tokens can't set ACL items.");
>>          }
>>
>>          if !auth_id.is_token() {
>>              bail!("Unprivileged users can only set ACL items for API tokens.");
>>          }
>>
>>          if current_auth_id != *auth_id {
>>              bail!("Unprivileged users can only set ACL items for their own API tokens.");
>>          }
>>      }
>> ```
>>
>> what do you think?
>
> I see what you mean, and yes i think it's more readable, but what I really wanted to convey with my
> approach was to clarify which condition is ok
>
> we currently try to filter out all invalid states, and it is not really obvious what
> condition makes the code continue at first glance
>
> Maybe we have to approach it completely different, for example check only the valid cases first
> and let that pass through, and then fail with the specific errors and have a fallback error
> for all other cases. that way we can't come into a situation where we forget/overlook some edge
> case.

oh, i mean we could just add a comment to the first if statement there
something like:

```rs
// check that if a user with insufficient permissions is changing acl
// entries, that they only modify their own api tokens' entries.
// unprivileged api tokens are not allowed to modify anything.
if unprivileged_user {
...
```

alternatively, we could do this which is closer to your suggestion in
the last comment

```rs
    if unprivileged_user {
        if group.is_none()
            && !current_auth_id.is_token()
            // check that an entry for an auth_id is being edited and
            // that it is a token for the user that is making the edit
            && auth_id
                .as_ref()
                .map(|id| id.is_token() && current_auth_id.user() == id.user())
                .unwrap_or_default()
        {
            // a user is directly editing the privileges of their own token, this is always
            // allowed
        } else {
            if group.is_some() {
                bail!("Unprivileged users are not allowed to create group ACL item.");
            }

            let auth_id = auth_id.as_ref().ok_or_else(|| {
                format_err!("Unprivileged user needs to provide auth_id to update ACL item.")
            })?;

            if current_auth_id.is_token() {
                bail!("Unprivileged API tokens can't set ACL items.");
            }

            if !auth_id.is_token() {
                bail!("Unprivileged users can only set ACL items for API tokens.");
            }

            if current_auth_id.user() != auth_id.user() {
                bail!("Unprivileged users can only set ACL items for their own API tokens.");
            }

            // this should not be reachable, but just in case, bail here
            bail!("Unprivileged user is trying to set an invalid ACL item.")
        }
    }
```

i think that respects your initial intend and also has a fail-safe just
in case something got overlooked or is changed later on.


_______________________________________________
pdm-devel mailing list
pdm-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pdm-devel


  reply	other threads:[~2025-04-11 11:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-03 14:17 [pdm-devel] [PATCH datacenter-manager/proxmox/yew-comp 0/9] ACL edit api and ui components Shannon Sterz
2025-04-03 14:17 ` [pdm-devel] [PATCH proxmox 1/4] access-control: add more types to prepare for api feature Shannon Sterz
2025-04-03 14:17 ` [pdm-devel] [PATCH proxmox 2/4] access-control: add acl " Shannon Sterz
2025-04-09 11:01   ` Dietmar Maurer
2025-04-09 11:39     ` Dominik Csapak
2025-04-09 12:58       ` Shannon Sterz
2025-04-10  6:28         ` Dominik Csapak
2025-04-10  8:17           ` Shannon Sterz
2025-04-10 10:09             ` Dominik Csapak
2025-04-11 10:29         ` Shannon Sterz
2025-04-11 10:53           ` Dominik Csapak
2025-04-11 11:40             ` Shannon Sterz [this message]
2025-04-03 14:18 ` [pdm-devel] [PATCH proxmox 3/4] access-control: add comments to roles function of AccessControlConfig Shannon Sterz
2025-04-03 14:18 ` [pdm-devel] [PATCH proxmox 4/4] access-control: add generic roles endpoint to `api` feature Shannon Sterz
2025-04-03 14:18 ` [pdm-devel] [PATCH yew-comp 1/3] api-types/role_selector: depend on common `RoleInfo` type Shannon Sterz
2025-04-03 14:18 ` [pdm-devel] [PATCH yew-comp 2/3] acl: add a view and semi-generic `EditWindow` for acl entries Shannon Sterz
2025-04-03 14:18 ` [pdm-devel] [PATCH yew-comp 3/3] role_selector/acl_edit: make api endpoint and default role configurable Shannon Sterz
2025-04-03 14:18 ` [pdm-devel] [PATCH datacenter-manager 1/2] server: use proxmox-access-control api implementations Shannon Sterz
2025-04-03 14:18 ` [pdm-devel] [PATCH datacenter-manager 2/2] ui: configuration: add panel for viewing and editing acl entries Shannon Sterz
2025-04-11 13:45 ` [pdm-devel] [PATCH datacenter-manager/proxmox/yew-comp 0/9] ACL edit api and ui components Shannon Sterz

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=D93S4RWONVOT.35K5MQPHT6OR0@proxmox.com \
    --to=s.sterz@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=dietmar@proxmox.com \
    --cc=pdm-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.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal