Upgrade to libcap-ng 0.8.1 breaks GNOME Keyring and other projects about libcap-ng

[stevegrubb]

A new release is available. I suppose this issue can be closed.

[diabonas]

LinuxCIFS utils is affected by this change as well:

if (capng_apply(CAPNG_SELECT_BOTH)) {
	fprintf(stderr, "Unable to apply new capability set.\n");
	return EX_SYSERR;
}

Downstream Arch Linux bug report: FS#68666

[stevegrubb]

Commit fda0224 should help the situation. Will probably push a new release early next week.

[diabonas]

IIUC this code fails because gnome-keyring-daemon does not have CAP_SETPCAP and tries to change its capability bounding set anyway, so capng_apply returns -4. I guess this behaviour is technically correct, but probably comes as a surprise for many developers, especially since this code is modelled exactly after example 2) in the libcap-ng README. Is there a better way of doing this without adding CAP_SETPCAP or giving up error checking?

[diabonas]

In any case I don't think this should fail early before even attempting to set the normal CAPNG_SELECT_CAPS: right now, probably a lot of legacy code just completely and silently fails trying to set capabilities because it uses the example code from the documentation without checking the return value of capng_apply.

[diabonas]

In any case I don't think this should fail early before even attempting to set the normal CAPNG_SELECT_CAPS: right now, probably a lot of legacy code just completely and silently fails trying to set capabilities because it uses the example code from the documentation without checking the return value of capng_apply.

To fix this part of the issue, I have opened #23. Hopefully this strikes a balance between the need for better error checking and not breaking legacy code: projects that perform error checking on capng_apply will need to be updated for the new libcap-ng release, while code not doing any error checking will continue working as before instead of completely failing to apply the capabilities.

In the downstream bug report, @dvzrv provided a link to a fix for GNOME keyring by libcap-ng mainainer @stevegrubb. I noticed that this fix doesn't even apply CAPNG_SELECT_CAPS any more if CAP_SETPCAP is not given, which previous versions of GNOME keyring and libcap-ng used to do. Could you comment on whether that is the intended behaviour, please?

For other projects like LinuxCIFS utils, no such fixes appear to be available yet.

[AdamWill]

Confirming both issues hit me on Rawhide today after an upgrade.

[SoapGentoo]

I can confirm this for Gentoo too

[stevegrubb]

I have placed a merge request here:
https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/34

[stevegrubb]

Message to package maintainers: Fedora has added commit fda0224 to rawhide and applied this patch on top which blocks the bad return codes: https://src.fedoraproject.org/rpms/libcap-ng/blob/master/f/libcap-ng-0.8.2-apply-disable.patch
Assuming this calms down issues, this provides a place to hook for syslog'ing apps that are not using capabilities correctly so that we can fix them. I don't expect, as of now, to carry the syslog patch in libcap-ng. But rather point to it as a downstream add-on that distros can use in their experimental branch to work out problems.

[diabonas]

LinuxCIFS utils is affected by this change as well

I sent the following patches upstream to the linux-cifs mailing list:

From f4e7c84467152624a288351321c8664dbf3364af Mon Sep 17 00:00:00 2001
From: Jonas Witschel <[email protected]>
Date: Sat, 21 Nov 2020 11:41:26 +0100
Subject: [PATCH 1/2] mount.cifs: update the cap bounding set only when
 CAP_SETPCAP is given

libcap-ng 0.8.1 tightened the error checking on capng_apply, returning an error
of -4 when trying to update the capability bounding set without having the
CAP_SETPCAP capability to be able to do so. Previous versions of libcap-ng
silently skipped updating the bounding set and only updated the normal
CAPNG_SELECT_CAPS capabilities instead.

Check beforehand whether we have CAP_SETPCAP, in which case we can use
CAPNG_SELECT_BOTH to update both the normal capabilities and the bounding set.
Otherwise, we can at least update the normal capabilities, but refrain from
trying to update the bounding set to avoid getting an error.

Signed-off-by: Jonas Witschel <[email protected]>
---
 mount.cifs.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/mount.cifs.c b/mount.cifs.c
index 4feb397..88b8b69 100644
--- a/mount.cifs.c
+++ b/mount.cifs.c
@@ -338,6 +338,8 @@ static int set_password(struct parsed_mount_info *parsed_info, const char *src)
 static int
 drop_capabilities(int parent)
 {
+	capng_select_t set = CAPNG_SELECT_CAPS;
+
 	capng_setpid(getpid());
 	capng_clear(CAPNG_SELECT_BOTH);
 	if (parent) {
@@ -355,7 +357,10 @@ drop_capabilities(int parent)
 			return EX_SYSERR;
 		}
 	}
-	if (capng_apply(CAPNG_SELECT_BOTH)) {
+	if (capng_have_capability(CAPNG_EFFECTIVE, CAP_SETPCAP)) {
+		set = CAPNG_SELECT_BOTH;
+	}
+	if (capng_apply(set)) {
 		fprintf(stderr, "Unable to apply new capability set.\n");
 		return EX_SYSERR;
 	}
--
2.29.2


From 64dfbafe7a0639a96d67f0b840b6e6498e1f68a9 Mon Sep 17 00:00:00 2001
From: Jonas Witschel <[email protected]>
Date: Sat, 21 Nov 2020 11:48:33 +0100
Subject: [PATCH 2/2] cifs.upall: update the cap bounding set only when
 CAP_SETPCAP is given

libcap-ng 0.8.1 tightened the error checking on capng_apply, returning an error
of -4 when trying to update the capability bounding set without having the
CAP_SETPCAP capability to be able to do so. Previous versions of libcap-ng
silently skipped updating the bounding set and only updated the normal
CAPNG_SELECT_CAPS capabilities instead.

Check beforehand whether we have CAP_SETPCAP, in which case we can use
CAPNG_SELECT_BOTH to update both the normal capabilities and the bounding set.
Otherwise, we can at least update the normal capabilities, but refrain from
trying to update the bounding set to avoid getting an error.

Signed-off-by: Jonas Witschel <[email protected]>
---
 cifs.upcall.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/cifs.upcall.c b/cifs.upcall.c
index 1559434..af1a0b0 100644
--- a/cifs.upcall.c
+++ b/cifs.upcall.c
@@ -88,6 +88,8 @@ typedef enum _sectype {
 static int
 trim_capabilities(bool need_environ)
 {
+	capng_select_t set = CAPNG_SELECT_CAPS;
+
 	capng_clear(CAPNG_SELECT_BOTH);

 	/* SETUID and SETGID to change uid, gid, and grouplist */
@@ -105,7 +107,10 @@ trim_capabilities(bool need_environ)
 		return 1;
 	}

-	if (capng_apply(CAPNG_SELECT_BOTH)) {
+	if (capng_have_capability(CAPNG_EFFECTIVE, CAP_SETPCAP)) {
+		set = CAPNG_SELECT_BOTH;
+	}
+	if (capng_apply(set)) {
 		syslog(LOG_ERR, "%s: Unable to apply capability set: %m\n", __func__);
 		return 1;
 	}
--
2.29.2

[diabonas]

Other projects I could find that might potentially be affected by this change because they perform error checking on capng_apply(CAPNG_SELECT_BOTH) without checking for CAP_SETPCAP first are:

• Ceph
• QEMU

Most other projects I looked at don't do any error checking on capng_apply, so they should be fine with the upcoming release including commit fda0224.

[stevegrubb]

Patch above looks good. Thanks for sending it to their mail list! I also have reports openconnect may be affected.

[diabonas]

Commit fda0224 should help the situation. Will probably push a new release early next week.

A new libcap-ng including this commit would be much appreciated :)

[diabonas]

Thank you very much for cutting the new release! I agree that this issue can be closed, since all other potentially necessary fixes need to be made downstream. Incidentally, the patches for LinuxCIFS utils have just been merged: piastry/cifs-utils@fcef79b, piastry/cifs-utils@0495bad