public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Christian Ebner <c.ebner@proxmox.com>
To: Shannon Sterz <s.sterz@proxmox.com>,
	Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup v8 4/4] fix: api: avoid race condition in set_backup_owner
Date: Tue, 25 Mar 2025 11:18:21 +0100	[thread overview]
Message-ID: <e887bc02-798a-4441-8ef7-8a52aa89d9cb@proxmox.com> (raw)
In-Reply-To: <D8P9MR9B7MIV.182GHZ9TXWZOC@proxmox.com>

On 3/25/25 11:13, Shannon Sterz wrote:
> On Tue Mar 25, 2025 at 11:00 AM CET, Christian Ebner wrote:
>> On 3/24/25 13:51, Shannon Sterz wrote:
>>> when two clients change the owner of a backup store, a race condition
>>> arose. add locking to avoid this.
>>>
>>> Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
>>> ---
>>>    src/api2/admin/datastore.rs | 13 ++++++++++---
>>>    1 file changed, 10 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/api2/admin/datastore.rs b/src/api2/admin/datastore.rs
>>> index 483e595c..3e532636 100644
>>> --- a/src/api2/admin/datastore.rs
>>> +++ b/src/api2/admin/datastore.rs
>>> @@ -7,7 +7,7 @@ use std::os::unix::ffi::OsStrExt;
>>>    use std::path::{Path, PathBuf};
>>>    use std::sync::Arc;
>>>
>>> -use anyhow::{bail, format_err, Error};
>>> +use anyhow::{bail, format_err, Context, Error};
>>>    use futures::*;
>>>    use hyper::http::request::Parts;
>>>    use hyper::{header, Body, Response, StatusCode};
>>> @@ -2347,10 +2347,9 @@ pub async fn set_backup_owner(
>>>            let datastore = DataStore::lookup_datastore(&store, Some(Operation::Write))?;
>>>
>>>            let backup_group = datastore.backup_group(ns, backup_group);
>>> +        let owner = backup_group.get_owner()?;
>>
>> this needs to read the content from the owner file
>>
>>>
>>>            if owner_check_required {
>>> -            let owner = backup_group.get_owner()?;
>>> -
>>>                let allowed = match (owner.is_token(), new_owner.is_token()) {
>>>                    (true, true) => {
>>>                        // API token to API token, owned by same user
>>> @@ -2397,6 +2396,14 @@ pub async fn set_backup_owner(
>>>                );
>>>            }
>>>
>>> +        let _guard = backup_group
>>> +            .lock()
>>> +            .with_context(|| format!("while setting the owner of group '{backup_group:?}'"))?;
>>> +
>>> +        if owner != backup_group.get_owner()? {
>>
>> same here.
>>
>>> +            bail!("{owner} does not own this group anymore");
>>> +        }
>>> +
>>>            backup_group.set_owner(&new_owner, true)?;
>>>
>>>            Ok(())
>>
>> reading from the filesystem is more expensive than the ownership checks
>> if required, so IMO it is better to lock the whole operation instead of
>> reading the owner file twice. Or is this done to avoid locking over and
>> over by unauthorized users?
> 
> yes that function has `Permission::Anybody` if you locked the file right
> away, creating a dos attack by *any* logged in user for *any* group
> would be trivial. getting the owner might be a bit more expensive, but
> this way we can still handle multiple requests in parallel easily and
> only hold the lock for the part that actually requires it. hence, the
> dos potential is lower (imo) and group owners should not change *that*
> often in normal operations. so the performance hit is acceptable.

Acked, given that  information it makes sense to me. Maybe the commit 
message or a dedicated comment could explicitly mention this so this is 
not changed unintentionally.


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


  reply	other threads:[~2025-03-25 10:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-24 12:51 [pbs-devel] [PATCH proxmox-backup v8 0/4] refactor datastore locking to use tmpfs Shannon Sterz
2025-03-24 12:51 ` [pbs-devel] [PATCH proxmox-backup v8 1/4] datastore/api/backup: prepare for fix of #3935 by adding lock helpers Shannon Sterz
2025-03-25  9:35   ` Christian Ebner
2025-03-25  9:57     ` Shannon Sterz
2025-03-25 10:12       ` Christian Ebner
2025-03-24 12:51 ` [pbs-devel] [PATCH proxmox-backup v8 2/4] fix #3935: datastore/api/backup: move datastore locking to '/run' Shannon Sterz
2025-03-25  9:43   ` Christian Ebner
2025-03-25  9:48   ` Christian Ebner
2025-03-25 11:25   ` Wolfgang Bumiller
2025-03-24 12:51 ` [pbs-devel] [PATCH proxmox-backup v8 3/4] fix #3935: datastore: move manifest locking to new locking method Shannon Sterz
2025-03-25  9:44   ` Christian Ebner
2025-03-24 12:51 ` [pbs-devel] [PATCH proxmox-backup v8 4/4] fix: api: avoid race condition in set_backup_owner Shannon Sterz
2025-03-25 10:00   ` Christian Ebner
2025-03-25 10:13     ` Shannon Sterz
2025-03-25 10:18       ` Christian Ebner [this message]
2025-03-25 11:26 ` [pbs-devel] [PATCH proxmox-backup v8 0/4] refactor datastore locking to use tmpfs Wolfgang Bumiller
2025-03-25 11:33   ` 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=e887bc02-798a-4441-8ef7-8a52aa89d9cb@proxmox.com \
    --to=c.ebner@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    --cc=s.sterz@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
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal