[PATCH 2.4] CAP_FS_MASK: add CAP_LINUX_IMMUTABLE and CAP_MKNOD

[PATCH 2.4] CAP_FS_MASK: add CAP_LINUX_IMMUTABLE and CAP_MKNOD

[Serge E. Hallyn]

When POSIX capabilities were introduced during the 2.1 Linux
cycle, the fs mask, which represents the capabilities which having
fsuid==0 is supposed to grant, did not include CAP_MKNOD and
CAP_LINUX_IMMUTABLE.  However, before capabilities the privilege
to call these did in fact depend upon fsuid==0.

This patch introduces those capabilities into the fsmask,
restoring the old behavior.

See the thread starting at http://lkml.org/lkml/2009/3/11/157 for
reference.

Reported-by: Igor Zhbanov <izh1979@gmail.com>
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Cc: stable@kernel.org
---
 include/linux/capability.h |   14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff -Nrup linux-2.4.37/include/linux/capability.h linux-2.4.37.new/include/linux/capability.h
--- linux-2.4.37/include/linux/capability.h	2008-12-02 02:01:34.000000000 -0600
+++ linux-2.4.37.new/include/linux/capability.h	2009-03-25 11:09:47.000000000 -0500
@@ -99,10 +99,6 @@ typedef __u32 kernel_cap_t;
 
 #define CAP_FSETID           4
 
-/* Used to decide between falling back on the old suser() or fsuser(). */
-
-#define CAP_FS_MASK          0x1f
-
 /* Overrides the restriction that the real or effective user ID of a
    process sending a signal must match the real or effective user ID
    of the process receiving the signal. */
@@ -301,6 +297,16 @@ extern kernel_cap_t cap_bset;
 
 #endif
 
+/* Used to decide between falling back on the old suser() or fsuser(). */
+
+#define CAP_FS_MASK	(CAP_TO_MASK(CAP_CHOWN)			\
+			| CAP_TO_MASK(CAP_DAC_OVERRIDE)		\
+			| CAP_TO_MASK(CAP_DAC_READ_SEARCH)	\
+			| CAP_TO_MASK(CAP_FOWNER)		\
+			| CAP_TO_MASK(CAP_FSETID)		\
+			| CAP_TO_MASK(CAP_LINUX_IMMUTABLE)	\
+			| CAP_TO_MASK(CAP_MKNOD))
+
 #define CAP_EMPTY_SET       to_cap_t(0)
 #define CAP_FULL_SET        to_cap_t(~0)
 #define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))

Re: [PATCH 2.4] CAP_FS_MASK: add CAP_LINUX_IMMUTABLE and CAP_MKNOD

[Willy Tarreau]

Hello,

On Wed, Mar 25, 2009 at 12:39:54PM -0500, Serge E. Hallyn wrote:
> When POSIX capabilities were introduced during the 2.1 Linux
> cycle, the fs mask, which represents the capabilities which having
> fsuid==0 is supposed to grant, did not include CAP_MKNOD and
> CAP_LINUX_IMMUTABLE.  However, before capabilities the privilege
> to call these did in fact depend upon fsuid==0.
> 
> This patch introduces those capabilities into the fsmask,
> restoring the old behavior.
> 
> See the thread starting at http://lkml.org/lkml/2009/3/11/157 for
> reference.

Thanks to Igor and you for fixing this. The impact did not appear
obvious to me at first, to be honnest! I'm queuing the patch for
next release.

BTW, I've noticed your other patch for 2.2.26, but it's not worth
wasting time on it, as 2.2 has remained unmaintained for years now
and people are really discouraged from using it as many holes have
never been fixed there.

Cheers,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2.4] CAP_FS_MASK: add CAP_LINUX_IMMUTABLE and CAP_MKNOD

[Serge E. Hallyn]

Quoting Willy Tarreau (w@1wt.eu):
> Hello,
> 
> On Wed, Mar 25, 2009 at 12:39:54PM -0500, Serge E. Hallyn wrote:
> > When POSIX capabilities were introduced during the 2.1 Linux
> > cycle, the fs mask, which represents the capabilities which having
> > fsuid==0 is supposed to grant, did not include CAP_MKNOD and
> > CAP_LINUX_IMMUTABLE.  However, before capabilities the privilege
> > to call these did in fact depend upon fsuid==0.
> > 
> > This patch introduces those capabilities into the fsmask,
> > restoring the old behavior.
> > 
> > See the thread starting at http://lkml.org/lkml/2009/3/11/157 for
> > reference.
> 
> Thanks to Igor and you for fixing this. The impact did not appear
> obvious to me at first, to be honnest! I'm queuing the patch for
> next release.
> 
> BTW, I've noticed your other patch for 2.2.26, but it's not worth
> wasting time on it, as 2.2 has remained unmaintained for years now
> and people are really discouraged from using it as many holes have
> never been fixed there.
> 
> Cheers,
> Willy

Sounds good to me.

thanks,
-serge