All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Seth Forshee (DigitalOcean)" <sforshee@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Serge Hallyn <serge@hallyn.com>, Paul Moore <paul@paul-moore.com>,
	Eric Paris <eparis@redhat.com>, James Morris <jmorris@namei.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Amir Goldstein <amir73il@gmail.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-security-module@vger.kernel.org, audit@vger.kernel.org,
	linux-unionfs@vger.kernel.org
Subject: Re: [PATCH 05/16] capability: provide helpers for converting between xattrs and vfs_caps
Date: Fri, 1 Dec 2023 11:09:26 -0600	[thread overview]
Message-ID: <ZWoTRsbZLSRkXbrd@do-x1extreme> (raw)
In-Reply-To: <20231201-gefahndet-biogas-ee3669edc96c@brauner>

On Fri, Dec 01, 2023 at 05:41:19PM +0100, Christian Brauner wrote:
> >  /**
> > - * get_vfs_caps_from_disk - retrieve vfs caps from disk
> > + * vfs_caps_from_xattr - convert raw caps xattr data to vfs_caps
> >   *
> > - * @idmap:	idmap of the mount the inode was found from
> > - * @dentry:	dentry from which @inode is retrieved
> > - * @cpu_caps:	vfs capabilities
> > + * @idmap:      idmap of the mount the inode was found from
> > + * @src_userns: user namespace for ids in xattr data
> > + * @vfs_caps:   destination buffer for vfs_caps data
> > + * @data:       rax xattr caps data
> > + * @size:       size of xattr data
> >   *
> > - * Extract the on-exec-apply capability sets for an executable file.
> > + * Converts a raw security.capability xattr into the kernel-internal
> > + * capabilities format.
> >   *
> > - * If the inode has been found through an idmapped mount the idmap of
> > - * the vfsmount must be passed through @idmap. This function will then
> > - * take care to map the inode according to @idmap before checking
> > - * permissions. On non-idmapped mounts or if permission checking is to be
> > - * performed on the raw inode simply pass @nop_mnt_idmap.
> > + * If the xattr is being read or written through an idmapped mount the
> > + * idmap of the vfsmount must be passed through @idmap. This function
> > + * will then take care to map the rootid according to @idmap.
> > + *
> > + * Return: On success, return 0; on error, return < 0.
> >   */
> > -int get_vfs_caps_from_disk(struct mnt_idmap *idmap,
> > -			   const struct dentry *dentry,
> > -			   struct vfs_caps *cpu_caps)
> > +int vfs_caps_from_xattr(struct mnt_idmap *idmap,
> > +			struct user_namespace *src_userns,
> > +			struct vfs_caps *vfs_caps,
> > +			const void *data, int size)
> >  {
> > -	struct inode *inode = d_backing_inode(dentry);
> >  	__u32 magic_etc;
> > -	int size;
> > -	struct vfs_ns_cap_data data, *nscaps = &data;
> > -	struct vfs_cap_data *caps = (struct vfs_cap_data *) &data;
> > +	const struct vfs_ns_cap_data *ns_caps = data;
> 
> The casting here is predicated on the compatibility of these two structs
> and I'm kinda surprised to see no static assertions about their layout.
> So I would recommend to add some to the header:
> 
> diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
> index 5bb906098697..0fd75aab9754 100644
> --- a/include/uapi/linux/capability.h
> +++ b/include/uapi/linux/capability.h
> @@ -16,6 +16,10 @@
> 
>  #include <linux/types.h>
> 
> +#ifdef __KERNEL__
> +#include <linux/build_bug.h>
> +#endif
> +
>  /* User-level do most of the mapping between kernel and user
>     capabilities based on the version tag given by the kernel. The
>     kernel might be somewhat backwards compatible, but don't bet on
> @@ -100,6 +104,15 @@ struct vfs_ns_cap_data {
>  #define _LINUX_CAPABILITY_VERSION  _LINUX_CAPABILITY_VERSION_1
>  #define _LINUX_CAPABILITY_U32S     _LINUX_CAPABILITY_U32S_1
> 
> +#else
> +
> +static_assert(offsetof(struct vfs_cap_data, magic_etc) ==
> +             offsetof(struct vfs_ns_cap_data, magic_etc));
> +static_assert(offsetof(struct vfs_cap_data, data) ==
> +             offsetof(struct vfs_ns_cap_data, data));
> +static_assert(sizeof(struct vfs_cap_data) ==
> +             offsetof(struct vfs_ns_cap_data, rootid));
> +
>  #endif

It's a little orthogonal to the changes, but I can certainly add a patch
for this.

> > +/**
> > + * vfs_caps_to_xattr - convert vfs_caps to raw caps xattr data
> > + *
> > + * @idmap:       idmap of the mount the inode was found from
> > + * @dest_userns: user namespace for ids in xattr data
> > + * @vfs_caps:    source vfs_caps data
> > + * @data:        destination buffer for rax xattr caps data
> > + * @size:        size of the @data buffer
> > + *
> > + * Converts a kernel-interrnal capability into the raw security.capability
> 
> s/interrnal/internal/
> 
> > + * xattr format.
> > + *
> > + * If the xattr is being read or written through an idmapped mount the
> > + * idmap of the vfsmount must be passed through @idmap. This function
> > + * will then take care to map the rootid according to @idmap.
> > + *
> > + * Return: On success, return 0; on error, return < 0.
> > + */
> > +int vfs_caps_to_xattr(struct mnt_idmap *idmap,
> > +		      struct user_namespace *dest_userns,
> > +		      const struct vfs_caps *vfs_caps,
> > +		      void *data, int size)
> > +{
> > +	struct vfs_ns_cap_data *caps = data;
> > +	int ret;
> > +
> > +	ret = __vfs_caps_to_xattr(idmap, dest_userns, vfs_caps, data, size);
> > +	if (ret > 0 &&
> > +	    (vfs_caps->magic_etc & VFS_CAP_REVISION_MASK) == VFS_CAP_REVISION_3 &&
> > +	     le32_to_cpu(caps->rootid) == (uid_t)-1)
> > +		return -EOVERFLOW;
> 
> I think the return value situation of these two helper is a bit
> confusing. So if they return the size or a negative error pointer the
> return value of both functions should likely be ssize_t.
> 
> But unless you actually later use the size in the callers of these
> helpers it would be easier to just stick with 0 on success, negative
> errno on failure. Note that that's what vfs_caps_from_xattr() is doing.
> 
> I'll see whether that becomes relevant later in the series though.

Size is relevant since the different versions have different xattr
sizes, and callers need to know how much data to write to disk or copy
to userspace. ssize_t probably is better though, so I'll change it.


  reply	other threads:[~2023-12-01 17:09 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-29 21:50 [PATCH 00/16] fs: use type-safe uid representation for filesystem capabilities Seth Forshee (DigitalOcean)
2023-11-29 21:50 ` [PATCH 01/16] mnt_idmapping: split out core vfs[ug]id_t definitions into vfsid.h Seth Forshee (DigitalOcean)
2023-11-29 21:50 ` [PATCH 02/16] mnt_idmapping: include cred.h Seth Forshee (DigitalOcean)
2023-11-29 21:50 ` [PATCH 03/16] capability: rename cpu_vfs_cap_data to vfs_caps Seth Forshee (DigitalOcean)
2023-12-01 15:50   ` Christian Brauner
2023-12-05 21:25   ` [PATCH 3/16] " Paul Moore
2023-11-29 21:50 ` [PATCH 04/16] capability: use vfsuid_t for vfs_caps rootids Seth Forshee (DigitalOcean)
2023-12-05 21:25   ` [PATCH 4/16] " Paul Moore
2023-11-29 21:50 ` [PATCH 05/16] capability: provide helpers for converting between xattrs and vfs_caps Seth Forshee (DigitalOcean)
2023-12-01 16:41   ` Christian Brauner
2023-12-01 17:09     ` Seth Forshee (DigitalOcean) [this message]
2023-11-29 21:50 ` [PATCH 06/16] capability: provide a helper for converting vfs_caps to xattr for userspace Seth Forshee (DigitalOcean)
2023-12-01 16:57   ` Christian Brauner
2023-12-01 17:23     ` Seth Forshee (DigitalOcean)
2023-11-29 21:50 ` [PATCH 07/16] fs: add inode operations to get/set/remove fscaps Seth Forshee (DigitalOcean)
2023-11-30  5:32   ` Amir Goldstein
2023-11-30 15:36     ` Seth Forshee (DigitalOcean)
2023-12-01 17:02   ` Christian Brauner
2023-12-01 17:38     ` Seth Forshee (DigitalOcean)
2023-12-05 11:50       ` Christian Brauner
2023-11-29 21:50 ` [PATCH 08/16] fs: add vfs_get_fscaps() Seth Forshee (DigitalOcean)
2023-12-01 17:09   ` Christian Brauner
2023-12-01 17:41     ` Seth Forshee (DigitalOcean)
2023-11-29 21:50 ` [PATCH 09/16] fs: add vfs_set_fscaps() Seth Forshee (DigitalOcean)
2023-11-30  8:01   ` Amir Goldstein
2023-11-30 15:38     ` Seth Forshee (DigitalOcean)
2023-12-01 17:39   ` Christian Brauner
2023-12-01 18:18     ` Seth Forshee (DigitalOcean)
2023-12-07 14:42       ` Seth Forshee (DigitalOcean)
2023-12-10 16:41         ` Amir Goldstein
2023-11-29 21:50 ` [PATCH 10/16] fs: add vfs_remove_fscaps() Seth Forshee (DigitalOcean)
2023-11-29 21:50 ` [PATCH 11/16] ovl: add fscaps handlers Seth Forshee (DigitalOcean)
2023-11-30  5:56   ` Amir Goldstein
2023-11-30 16:01     ` Seth Forshee (DigitalOcean)
2023-11-29 21:50 ` [PATCH 12/16] ovl: use vfs_{get,set}_fscaps() for copy-up Seth Forshee (DigitalOcean)
2023-11-30  6:23   ` Amir Goldstein
2023-11-30 16:43     ` Seth Forshee (DigitalOcean)
2023-11-29 21:50 ` [PATCH 13/16] fs: use vfs interfaces for capabilities xattrs Seth Forshee (DigitalOcean)
2023-11-29 21:50 ` [PATCH 14/16] commoncap: remove cap_inode_getsecurity() Seth Forshee (DigitalOcean)
2023-12-05 21:25   ` Paul Moore
2023-11-29 21:50 ` [PATCH 15/16] commoncap: use vfs fscaps interfaces for killpriv checks Seth Forshee (DigitalOcean)
2023-12-11  7:57   ` kernel test robot
2023-11-29 21:50 ` [PATCH 16/16] vfs: return -EOPNOTSUPP for fscaps from vfs_*xattr() Seth Forshee (DigitalOcean)
2023-11-30  6:10   ` Amir Goldstein
2023-11-30 16:40     ` Seth Forshee (DigitalOcean)

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=ZWoTRsbZLSRkXbrd@do-x1extreme \
    --to=sforshee@kernel.org \
    --cc=amir73il@gmail.com \
    --cc=audit@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.