From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Gabriel Goller <g.goller@proxmox.com>
Cc: Proxmox Backup Server development discussion
<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup] auth: add locking to `PbsAuthenticator` to avoid race conditions
Date: Mon, 3 Jun 2024 11:00:51 +0200 [thread overview]
Message-ID: <4jt24gf7mcf7mt4a6isoz3szpq5f3pqpflsj55ti2itprzwpyz@mie5xdspzcqb> (raw)
In-Reply-To: <20240523114647.g7tf64ins3hhh5e6@luna.proxmox.com>
On Thu, May 23, 2024 at 01:46:47PM GMT, Gabriel Goller wrote:
> On 23.05.2024 13:25, Shannon Sterz wrote:
> > currently we don't lock the shadow file when removing or storing a
> > password. by adding locking here we avoid a situation where storing
> > and/or removing a password concurrently could lead to a race
> > condition. in this scenario it is possible that a password isn't
> > persisted or a password isn't removed. we already do this for
> > the "token.shadow" file, so just use the same mechanism here.
> >
> > Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
>
> Is there any reason why the store_password function does not lock the
> shadow.json file?
I'm assuming you mean this as an alternative to having a separate file
for the locking. In this case the answer is yes: We use `repalce_file()`
to store the new version to make sure the update is atomic (and a
parallel `authenticat_user` does not read a *partial* file and fail).
When you hold a lock on a file and you *replace* it, the new file is a
separate thing with no lock on it. Old threads waiting for a lock on the
old file will continue when the lock is free, new threads waiting on the
lock on the new file will be able to acquire that simultaneously.
Iow.: you can't lock something you're *replacing*.
_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel
next prev parent reply other threads:[~2024-06-03 9:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 11:25 Shannon Sterz
2024-05-23 11:46 ` Gabriel Goller
2024-05-23 12:06 ` Shannon Sterz
2024-06-03 9:00 ` Wolfgang Bumiller [this message]
2024-06-03 9:12 ` Gabriel Goller
2024-06-03 9:02 ` [pbs-devel] applied: " Wolfgang Bumiller
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=4jt24gf7mcf7mt4a6isoz3szpq5f3pqpflsj55ti2itprzwpyz@mie5xdspzcqb \
--to=w.bumiller@proxmox.com \
--cc=g.goller@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.