#995023 gnome-keyring fails on home directory provided by sshfs

Package:
gnome-keyring
Source:
gnome-keyring
Description:
GNOME keyring services (daemon and tools)
Submitter:
"Andreas B. Mundt"
Date:
2021-09-27 12:18:04 UTC
Severity:
normal
Tags:
#995023#5
Date:
2021-09-24 21:25:16 UTC
From:
To:
Hi,

there is a long standing issue with gnome-keyring:  If the home
directory is provided by sshfs, thousands of files are generated
in '~/.local/share/keyrings/' on the first login of a user (and
the login usually fails).  The upstream bug [1] provides a link
to the old bug tracker with more information and history.

The reason is the following:  In pkcs11/gkm/gkm-transaction.c, a
temporary link, respectively copy of a file is generated.  On file
systems that provide support for hard links, this is done by calling
link() (right above the lines of the patch).  To take file systems
into account that do not support hard links, a copy of the file is
made if the hard linking fails.

Unfortunately on sshfs, the call of link() already makes a copy of the
file, which fails to be noticed, as success is checked by looking at
the link counter of the original file, which doesn't change if a copy is
made instead.  So a copy is attempted, which fails as well, because the
copy already exists.  After that, the loop continues from the beginning,
trying another random file name for the link/copy.

The attached patch for review adds a test for the file which did not
exist before calling link(). This covers the case, where link() already
copies the file and another copy would fail because a file with the same
name already exists.

Regards,

  Andi


[1] <URL:https://gitlab.gnome.org/GNOME/gnome-keyring/-/issues/84>
#995023#10
Date:
2021-09-25 16:01:14 UTC
From:
To:
Hi,

the patch provided before does not take into account that the file
may exists before we call link() on a file system where link() fails
(and not with EEXIST).  In that case, we would use the already existing
file.

The attached patch makes sure we try a new file name in that case.

Regards,

  Andi
#995023#15
Date:
2021-09-27 12:16:18 UTC
From:
To:
The proposed patch here is working around sshfs being incompatible with
the assumptions of a previous workaround for a different filesystem
bug.  I don't think this change should be applied in Debian until its
implications are understood, which is better discussed upstream than here.

Tagging this "- patch" to reflect that the patch is not ready to apply.

Thanks,
    smcv