1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
From f4e7c84467152624a288351321c8664dbf3364af Mon Sep 17 00:00:00 2001
From: Jonas Witschel <diabonas@archlinux.org>
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 <diabonas@archlinux.org>
---
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 <diabonas@archlinux.org>
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 <diabonas@archlinux.org>
---
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
|
