common: Fix a race condition removing stale lockfile.
Concern Raisedd94b411f129f
Actions

Description

common: Fix a race condition removing stale lockfile.

* common/dotlock.c (read_lockfile): Return the file descriptor when
R_FD is available.
(dotlock_take_unix): Check the case the lockfile was already removed.

GnuPG-bug-id: T5884
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>

Details

Auditors

• werner

Provenance

• gniibe

Authored on Mar 18 2022, 6:33 AM

Parents

rGa30359cecb5b: common: More heavy test condition for t-dotlock.c.

Branches

Unknown

Tags

Unknown

Tasks

T5884: dotlock is not perfect (errornously remove .lock as stale lockfile)

Event Timeline

• gniibe committed rGd94b411f129f: common: Fix a race condition removing stale lockfile. (authored by • gniibe).Mar 18 2022, 6:33 AM

• gniibe added a task: T5884: dotlock is not perfect (errornously remove .lock as stale lockfile).Mar 18 2022, 6:57 AM

• werner raised a concern with this commit.Mar 18 2022, 8:49 AM

• werner added a subscriber: • werner.

• werner added inline comments.

/common/dotlock.c
1134	What about systems w/o hardlink support (h->use_o_excl)? I recall that I wrote changed the code once to support such systems (actually for a large installation of gnupg)

This commit now has outstanding concerns.Mar 18 2022, 8:49 AM

For the logic of detecting unlocking, it should work when h->use_o_excl == 1.

When h->use_o_excl == 0, the removed comment is irrelevant, because it fails at the creation of lockfile.

The comment removed matters when h->use_o_excl == 1. I overlooked this case.
I'll add comment back.

• gniibe mentioned this in T5884: dotlock is not perfect (errornously remove .lock as stale lockfile).Mar 21 2022, 5:09 AM

Changes (1)

Path

Size

common/

dotlock.c

rGd94b411f129f

View Options