From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH pve-access-control] fix #6528: tfa: update user config on removal of TFA
Date: Tue, 29 Jul 2025 12:40:54 +0200 [thread overview]
Message-ID: <1753785610.otyyvk8ca5.astroid@yuna.none> (raw)
In-Reply-To: <DBOGTW5GCZZE.3V2FS3RAXC4FR@noor>
On July 29, 2025 12:26 pm, Shan Shaji wrote:
> Thank you so much for the review and i will update it accordingly.
> Had some doubts which i added as inline comments.
>
> On Tue Jul 29, 2025 at 11:45 AM CEST, Fabian Grünbichler wrote:
>> On July 29, 2025 10:30 am, Shan Shaji wrote:
>> > +
>> > + if ($update_user_config) {
>> > + PVE::AccessControl::lock_user_config(sub {
>> > + my $user_cfg = cfs_read_file('user.cfg');
>> > + my $user = $user_cfg->{users}->{$userid};
>> > + $user->{keys} = undef;
>> > + cfs_write_file('user.cfg', $user_cfg);
>> > + });
>> > + }
>>
>> the locking here is incomplete - in the meantime, another invocation
>> could have added a TFA entry again, and potentially the 'x' marker is
>> dropped afterwards making user.cfg wrong/out of sync..
>>
>> PVE::API2::TFA::delete_tfa() has the same issue, but in
>> PVE::API2::TFA::add_tfa_entry we have a nested call:
> So the order will the lock TFA -> lock user cfg -> update user cfg ->
> update tfa cfg.
yes, unless you find another code path that does the inverse (lock user
first, then lock TFA while the lock is held) - in that case we need to
settle on one of the two variants ;)
>> lock_tfa_config() {
>> set_user_tfa_enabled() {
>> lock_user_config() {
>> add 'x' entry to user.cfg
>> }
>> }
>> add tfa entry to tfa.cfg
>> }
>>
>> if that lock order is used everywhere else as well, the two deletion
>> paths (API and CLI) should also be done like that, to avoid races. there
>> might be more code paths missing proper nested locking, I haven't done a
>> complete analysis.
>>
>> > return;
>> > },
>> > });
>> > --
>> > 2.39.5
>> >
>> >
>> >
>> > _______________________________________________
>> > pve-devel mailing list
>> > pve-devel@lists.proxmox.com
>> > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>> >
>> >
>> >
>>
>>
>> _______________________________________________
>> pve-devel mailing list
>> pve-devel@lists.proxmox.com
>> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
>
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@lists.proxmox.com
> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
next prev parent reply other threads:[~2025-07-29 10:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 8:30 Shan Shaji
2025-07-29 9:45 ` Fabian Grünbichler
2025-07-29 10:26 ` Shan Shaji
2025-07-29 10:40 ` Fabian Grünbichler [this message]
2025-07-29 11:06 ` Shan Shaji
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=1753785610.otyyvk8ca5.astroid@yuna.none \
--to=f.gruenbichler@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.