Linux Security Modules development
 help / color / mirror / Atom feed
* [PATCH] security: commoncap: clarify CAP_FS_SET comment in cap_task_fix_setuid()
@ 2026-09-19 13:01 Adriano Cordova
  2026-09-19 13:03 ` sashiko-bot
  2026-09-20 16:17 ` Serge E. Hallyn
  0 siblings, 2 replies; 3+ messages in thread
From: Adriano Cordova @ 2026-09-19 13:01 UTC (permalink / raw)
  To: Serge Hallyn
  Cc: Paul Moore, James Morris, linux-security-module, Adriano Cordova

CAP_FS_SET is defined as exactly the capabilities an fsuid of 0
historically granted (see CAP_FS_MASK in include/linux/capability.h),
so dropping it when fsuid leaves 0 is correct by construction, not
"too harsh". Replace the stale FIXME with this explanation.

Signed-off-by: Adriano Cordova <adrianox@gmail.com>
---
 security/commoncap.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/security/commoncap.c b/security/commoncap.c
index 3399535808fe..e0a2f386c556 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -1169,11 +1169,13 @@ int cap_task_fix_setuid(struct cred *new, const struct cred *old, int flags)
 		break;
 
 	case LSM_SETID_FS:
-		/* juggle the capabilities to follow FSUID changes, unless
-		 * otherwise suppressed
+		/* Juggle the capabilities to follow FSUID changes, unless
+		 * otherwise suppressed.
 		 *
-		 * FIXME - is fsuser used for all CAP_FS_MASK capabilities?
-		 *          if not, we might be a bit too harsh here.
+		 * CAP_FS_SET is exactly the set of capabilities that an
+		 * fsuid of 0 historically granted (see CAP_FS_MASK in
+		 * <linux/capability.h>), so dropping that set when fsuid
+		 * leaves 0 is intentional rather than too harsh.
 		 */
 		if (!issecure(SECURE_NO_SETUID_FIXUP)) {
 			kuid_t root_uid = make_kuid(old->user_ns, 0);
-- 
2.51.0


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] security: commoncap: clarify CAP_FS_SET comment in cap_task_fix_setuid()
  2026-09-19 13:01 [PATCH] security: commoncap: clarify CAP_FS_SET comment in cap_task_fix_setuid() Adriano Cordova
@ 2026-09-19 13:03 ` sashiko-bot
  2026-09-20 16:17 ` Serge E. Hallyn
  1 sibling, 0 replies; 3+ messages in thread
From: sashiko-bot @ 2026-09-19 13:03 UTC (permalink / raw)
  Cc: linux-security-module

> CAP_FS_SET is defined as exactly the capabilities an fsuid of 0
> historically granted (see CAP_FS_MASK in include/linux/capability.h),
> so dropping it when fsuid leaves 0 is correct by construction, not
> "too harsh". Replace the stale FIXME with this explanation.
> 
> Signed-off-by: Adriano Cordova <adrianox@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260919130112.849932-1-adrianox@gmail.com?part=1


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] security: commoncap: clarify CAP_FS_SET comment in cap_task_fix_setuid()
  2026-09-19 13:01 [PATCH] security: commoncap: clarify CAP_FS_SET comment in cap_task_fix_setuid() Adriano Cordova
  2026-09-19 13:03 ` sashiko-bot
@ 2026-09-20 16:17 ` Serge E. Hallyn
  1 sibling, 0 replies; 3+ messages in thread
From: Serge E. Hallyn @ 2026-09-20 16:17 UTC (permalink / raw)
  To: Adriano Cordova; +Cc: Paul Moore, James Morris, linux-security-module

On Sat, Sep 19, 2026 at 10:01:12AM -0300, Adriano Cordova wrote:
> CAP_FS_SET is defined as exactly the capabilities an fsuid of 0
> historically granted (see CAP_FS_MASK in include/linux/capability.h),
> so dropping it when fsuid leaves 0 is correct by construction, not
> "too harsh". Replace the stale FIXME with this explanation.
> 
> Signed-off-by: Adriano Cordova <adrianox@gmail.com>

Thanks, but,

> ---
>  security/commoncap.c | 10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/security/commoncap.c b/security/commoncap.c
> index 3399535808fe..e0a2f386c556 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -1169,11 +1169,13 @@ int cap_task_fix_setuid(struct cred *new, const struct cred *old, int flags)
>  		break;
>  
>  	case LSM_SETID_FS:
> -		/* juggle the capabilities to follow FSUID changes, unless
> -		 * otherwise suppressed
> +		/* Juggle the capabilities to follow FSUID changes, unless
> +		 * otherwise suppressed.
>  		 *
> -		 * FIXME - is fsuser used for all CAP_FS_MASK capabilities?
> -		 *          if not, we might be a bit too harsh here.
> +		 * CAP_FS_SET is exactly the set of capabilities that an
> +		 * fsuid of 0 historically granted (see CAP_FS_MASK in
> +		 * <linux/capability.h>), so dropping that set when fsuid
> +		 * leaves 0 is intentional rather than too harsh.

"rather than too harsh" seems like arguing against the past comment.  Just
make it something like:

 +		 * CAP_FS_SET is exactly the set of capabilities that an
 +		 * fsuid of 0 historically granted (see CAP_FS_MASK in
 +		 * <linux/capability.h>), so we drop that set when fsuid
 +		 * leaves 0.

or

 +		/* Juggle the capabilities to follow FSUID changes, unless
 +		 * otherwise suppressed.  We drop the CAP_FS_SET when uid leaves
 +		 * 0, since that is the set of capabilities that an fsuid of 0
 +		 *  historically granted.

or even shorter.

>  		 */
>  		if (!issecure(SECURE_NO_SETUID_FIXUP)) {
>  			kuid_t root_uid = make_kuid(old->user_ns, 0);
> -- 
> 2.51.0

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-09-20 16:17 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-19 13:01 [PATCH] security: commoncap: clarify CAP_FS_SET comment in cap_task_fix_setuid() Adriano Cordova
2026-09-19 13:03 ` sashiko-bot
2026-09-20 16:17 ` Serge E. Hallyn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox