If a distribution has set user processes' RLIMIT_MEMLOCK to be high
enough, then there is no reason why gnome-keyring really needs to be
setuid or have elevated filesystem capabilities. Silence the warning
about insufficient capabilities in this case.

In particular, giving gnome-keyring elevated capabilities is practically
problematic because there is a desire to harden libraries like GLib and
libdbus against processes that (inadvisably) use those libraries while
they have genuinely abusable elevated capabilities, without first
sanitizing the execution environment to protect themselves against
being invoked by a malicious parent process. The mechanisms used to do
this cannot distinguish between genuinely abusable elevated capabilities,
like CAP_SYS_ADMIN, and elevated capabilities that are merely a
denial-of-service vector, like CAP_IPC_LOCK - so they will tend to err
on the side of caution and prevent gnome-keyring from accessing
environment variables that it needs to do its job, such as
DBUS_SESSION_BUS_ADDRESS and XDG_RUNTIME_DIR.

Also, if a sysadmin is concerned about users carrying out a
denial-of-service via locking abusive amounts of memory, they should
be equally concerned about whether gnome-keyring can be induced to
execute arbitrary code with CAP_IPC_LOCK (which it probably can, because
it relies on desktop services like dbus-daemon and systemd --user that
are under the unprivileged user's control).

Signed-off-by: Simon McVittie <smcv@debian.org>

Quentin PAGÈS authored Aug 11, 2021 and Administrator committed Aug 11, 2021

(cherry picked from commit 08695936)

readme: Mention libsecret instead of deprecated libgnome-keyring

See merge request !37

daemon: Make it systemd-activatable through the control socket

See merge request !35

Daiki Ueno authored Feb 12, 2021 and Daiki Ueno committed Mar 26, 2021

This enables gnome-keyring-daemon to be launched through the systemd
socket activation mechanism, rather than through pam_gnome_keyring.so.

Fix CI runs

See merge request !36

This ports the commits 572a35626625d0a2cd0be54124e402d6bcb43898 and
5b69e07be75ee5f43df0d734eaee007033a33647 from gcr, by Niels De Graef.

See
https://mail.gnome.org/archives/desktop-devel-list/2020-February/msg00055.html
for more context.

Also only deploy coverage information when built on the master branch.

Steven Grubb authored Nov 20, 2020 and Daiki Ueno committed Nov 21, 2020

There is a change in libcap-ng-0.8.1 that causes gnome-keyring to not
work correctly. The capng_apply function now returns an error if it
cannot change the bounding set. Previously this was ignored. Which means
now gnome-keyring exits when it shouldn't.

The new patch adds troubleshooting info to the error messages. And it checks
to see if we have CAP_SETPCAP. If we do not, then we cannot change the
bounding set and just set capabilities. On the setuid side, it now drops
the bounding set and clears any supplemental groups that may be left over
as an accident.

Jwtiyar Neriman authored Feb 27, 2020 and Administrator committed Feb 27, 2020

(cherry picked from commit 4d35eb83)