Comments (15)
A new release is available. I suppose this issue can be closed.
from libcap-ng.
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
from libcap-ng.
Commit fda0224 should help the situation. Will probably push a new release early next week.
from libcap-ng.
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?
from libcap-ng.
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
.
from libcap-ng.
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 ofcapng_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.
from libcap-ng.
Confirming both issues hit me on Rawhide today after an upgrade.
from libcap-ng.
I can confirm this for Gentoo too
from libcap-ng.
I have placed a merge request here:
https://gitlab.gnome.org/GNOME/gnome-keyring/-/merge_requests/34
from libcap-ng.
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.
from libcap-ng.
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
from libcap-ng.
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:
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.
from libcap-ng.
Patch above looks good. Thanks for sending it to their mail list! I also have reports openconnect may be affected.
from libcap-ng.
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 :)
from libcap-ng.
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
from libcap-ng.
Related Issues (20)
- capng_get_caps_process vs sandbox HOT 3
- Warning: comparison of integer expressions of different signedness: 'unsigned int' and 'int' [-Wsign-compare] in lookup_table.c and cap-ng.c HOT 2
- capng_updatev (python) doesnt work HOT 2
- `capng_apply` applies ambient caps too early? HOT 7
- `capng_apply` does not notice it failed to apply a capability HOT 6
- How to support conditional compilation with/without CAPNG_AMBIENT & CAPNG_SELECT_ALL? HOT 4
- Improve last cap detection HOT 4
- libdrop_ambient breaks compile if PR_CAP_AMBIENT is undefined HOT 4
- Detect kernel support of PR_CAP_AMBIENT at runtime HOT 5
- libcap-ng used by "/usr/sbin/mount.cifs" failed due to not having CAP_SETPCAP in capng_apply HOT 3
- capng_change_id() can leave PR_SET_KEEPCAPS set to 1 on failure HOT 4
- Tarball distribution issues. HOT 3
- Problem with namespaces HOT 5
- Why to modify capng_updatev parameter type to signed for python bindings HOT 2
- Misleading output in configure HOT 2
- Source version corresponding to libdrop_ambient 0.0.0 HOT 2
- 0.8.4: autoreconf fails HOT 4
- Build of libcap-ng failed with SWIG 4.2.0 HOT 10
- python bindings install fails if `python` binary is missing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from libcap-ng.