All of lore.kernel.org
 help / color / mirror / Atom feed
From: christian@brauner.io (Christian Brauner)
To: linux-security-module@vger.kernel.org
Subject: [PATCH 8/9] cap_file: handle run- vs buildtime vfs cap support
Date: Fri, 10 Aug 2018 18:13:34 +0200	[thread overview]
Message-ID: <20180810161335.27036-9-christian@brauner.io> (raw)
In-Reply-To: <20180810161335.27036-1-christian@brauner.io>

If libcap was compiled on a kernel supporting VFS_CAP_REVISION_3 but
running on a kernel that does not support VFS_CAP_REVISION_3 we should
always pass down a legacy struct vfs_cap_data if the rootid is 0. On
kernels supporting VFS_CAP_REVISION_3 the kernel will take care of
translating it from VFS_CAP_REVISION_2 to a VFS_CAP_REVISION_3 version.
We can elegantly handle both cases by setting magic to
VFS_CAP_REVISION_2 and only passing down XATTR_CAPS_SZ_2 bytes which
will leave out the rootid field.
If the rootid field is not 0 then we will pass down the
VFS_CAP_REVISION_3 and XATTR_CAPS_SZ_3. On kernels supporting
VFS_CAP_REVISION_3 this will succeed on kernels not supporting
VFS_CAP_REVISION_3 this will fail. The failure on kernels not supporting
VFS_CAP_REVISION_3 is wanted since the user explicitly requested an
unprivileged file capability but the kernel does not actually support
it. So fail hard.

Signed-off-by: Christian Brauner <christian@brauner.io>
Reviewed-by: Serge Hallyn <serge@hallyn.com>
---
 libcap/cap_file.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/libcap/cap_file.c b/libcap/cap_file.c
index 57c6e3f..a1f3891 100644
--- a/libcap/cap_file.c
+++ b/libcap/cap_file.c
@@ -202,6 +202,24 @@ static int _fcaps_save(struct vfs_cap_data *rawvfscap, cap_t cap_d, int *bytes_p
      * endian machine we need to fix this up.
      */
     rawvfscap->rootid = FIXUP_32BITS(cap_d->rootid);
+    if (rawvfscap->rootid == 0) {
+	/* If libcap was compiled on a kernel supporting VFS_CAP_REVISION_3 but
+	 * running on a kernel that does not support VFS_CAP_REVISION_3 we
+	 * should always pass down a legacy struct vfs_cap_data if the rootid is
+	 * 0. On kernels supporting VFS_CAP_REVISION_3 the kernel will take care
+	 * of translating it from VFS_CAP_REVISION_2 to a VFS_CAP_REVISION_3
+	 * version.  We can elegantly handle both cases by setting magic to
+	 * VFS_CAP_REVISION_2 and only passing down XATTR_CAPS_SZ_2 bytes which
+	 * will leave out the rootid field.  If the rootid field is not 0 then
+	 * we will pass down the VFS_CAP_REVISION_3 and XATTR_CAPS_SZ_3. On
+	 * kernels supporting VFS_CAP_REVISION_3 this will succeed on kernels
+	 * not supporting VFS_CAP_REVISION_3 this will fail. The failure on kernels
+	 * not supporting VFS_CAP_REVISION_3 is wanted since the user explicitly
+	 * requested an unprivileged file capability but the kernel does not
+	 * actually support it. So fail hard. */
+	magic = VFS_CAP_REVISION_2;
+	*bytes_p = XATTR_CAPS_SZ_2;
+    }
 #endif
 
     if (eff_not_zero == 0) {
-- 
2.17.1

  parent reply	other threads:[~2018-08-10 16:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-10 16:13 [PATCH 0/9] libcap: add user namespace fscaps support Christian Brauner
2018-08-10 16:13 ` [PATCH 1/9] cap_file: use v3 xattr macros Christian Brauner
2018-08-13 16:11   ` Serge E. Hallyn
2018-08-10 16:13 ` [PATCH 2/9] capability: update to new uapi header Christian Brauner
2018-08-10 16:13 ` [PATCH 3/9] cap_file: use struct vfs_ns_cap_data if possible Christian Brauner
2018-08-10 16:13 ` [PATCH 4/9] cap_file: add new rootid argument Christian Brauner
2018-08-10 16:13 ` [PATCH 5/9] cap_file: initialize rootid in _fcaps_load() Christian Brauner
2018-08-10 16:13 ` [PATCH 6/9] capability: add cap_get_nsowner() Christian Brauner
2018-08-10 16:13 ` [PATCH 7/9] cap_file: save rootid in _fcaps_save() Christian Brauner
2018-08-10 16:13 ` Christian Brauner [this message]
2018-08-10 16:13 ` [PATCH 9/9] capability: add cap_set_nsowner() Christian Brauner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180810161335.27036-9-christian@brauner.io \
    --to=christian@brauner.io \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.