all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Robert Obkircher <r.obkircher@proxmox.com>
To: Christian Ebner <c.ebner@proxmox.com>, pbs-devel@lists.proxmox.com
Subject: Re: [PATCH v1 proxmox-backup] config: invalidate CachedUserInfo after ACL changes
Date: Mon, 31 Aug 2026 15:30:36 +0200	[thread overview]
Message-ID: <73eba739-16da-4b38-9aa4-6947064d0d5e@proxmox.com> (raw)
In-Reply-To: <caea9c62-fa66-4060-a6cc-2f7e1497a899@proxmox.com>


On 28.08.26 11:18, Christian Ebner wrote:
> One tiny nit inline and one high level comment: We currently do not
> document the 5 second caching behavior for manual config file edits,
> not for the user and not for the acl introduced here. We do have a
> warning with respect to the more critical 60 seconds for
> token.shadow caching [0] but maybe we could add a note to the end of
> [1,2] for completeness as well? 

Do we support manual changes at all? If so, we would also have to
document that changes must be atomic renames instead of in-place
updates, and that we recognize them based on mtime.

The timeout is also not even guaranteed to be 5 seconds, because it is
based on system time instead of a monotonic clock. I assume this is
because Instant doesn't work on wasm, but it woudn't be that hard to
conditionally re-export it in proxmox-sys and replace it with a
performance.now() wrapper on wasm targets.

(Imo the generation and timeout checks also belong in the individual
cached_config methods instead of CachedUserInfo::new, but I'll leave
it as-is for now.)

>
> [0] https://pbs.proxmox.com/docs/user-management.html#api-tokens
> [1]
> https://pbs.proxmox.com/docs/user-management.html#user-configuration
> [2] https://pbs.proxmox.com/docs/user-management.html#access-control
>
> On 8/18/26 3:36 PM, Robert Obkircher wrote:
>> The ACL tree was cached for up to 5 seconds in CachedUserInfo, even
>> when the configuration was modified. This forced automated scripts to
>> wait for an arbitrary amount of time, and it was an unnecessary
>> security risk to keep revoked permissions for this long.
>>
>> Add a generation counter for acl.cfg and bump it upon save to force
>> subsequent requests to reload the file. A separate counter was chosen
>> for clarity, though incrementing the user_cache_generation would have
>> worked as well.
>>
>> Fixes: https://forum.proxmox.com/threads/185745
>> Signed-off-by: Robert Obkircher <r.obkircher@proxmox.com>
>
> Reviewed-by: Christian Ebner <c.ebner@proxmox.com>
> Tested-by: Christian Ebner <c.ebner@proxmox.com>
>
>> ---
>>   pbs-config/src/acl.rs                  | 11 +++++++++--
>>   pbs-config/src/cached_user_info.rs     |  5 +++++
>>   pbs-config/src/config_version_cache.rs | 18 ++++++++++++++++++
>>   3 files changed, 32 insertions(+), 2 deletions(-)
>>
>> diff --git a/pbs-config/src/acl.rs b/pbs-config/src/acl.rs
>> index 8612abed7..584238cde 100644
>> --- a/pbs-config/src/acl.rs
>> +++ b/pbs-config/src/acl.rs
>> @@ -11,7 +11,7 @@ use proxmox_schema::{ApiStringFormat, ApiType,
>> Schema, StringSchema};
>>     use pbs_api_types::{Authid, ROLE_NAME_NO_ACCESS, Role, Userid};
>>   -use crate::{BackupLockGuard, open_backup_lockfile};
>> +use crate::{BackupLockGuard, ConfigVersionCache,
>> open_backup_lockfile};
>>     /// Map of pre-defined [Roles](Role) to their associated
>>   /// [privileges](pbs_api_types::PRIVILEGES) combination and
>> description.
>> @@ -768,7 +768,14 @@ pub fn save_config(acl: &AclTree) ->
>> Result<(), Error> {
>>         acl.write_config(&mut raw)?;
>>   -    replace_privileged_config(ACL_CFG_FILENAME, &raw)
>> +    replace_privileged_config(ACL_CFG_FILENAME, &raw)?;
>> +
>> +    // increase acl version
>> +    // We use this in CachedUserInfo
>
> nit: I see that this is pre-existing in
> pbs_config::user::save_config(), but these comments do not give much
> context, especially the first line is redundant as already implied
> by the method call below.
>
> I would suggest to either drop the comment altogether or be more
> verbose, e.g.:
> `generation bump invalidates cached user and acl tree in
> CachedUserInfo`
>
> and adapt the comment in user config as well. 

Yeah, I'll fix this in a v2.

>
> [..]




  reply	other threads:[~2026-08-31 13:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-18 13:34 [PATCH v1 proxmox-backup] config: invalidate CachedUserInfo after ACL changes Robert Obkircher
2026-08-28  9:18 ` Christian Ebner
2026-08-31 13:30   ` Robert Obkircher [this message]
2026-08-31 14:06     ` Christian Ebner
2026-09-02 23:19 ` applied: " Thomas Lamprecht

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=73eba739-16da-4b38-9aa4-6947064d0d5e@proxmox.com \
    --to=r.obkircher@proxmox.com \
    --cc=c.ebner@proxmox.com \
    --cc=pbs-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