From: Alexey Gladkov <legion@kernel.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Hou Tao <houtao@huaweicloud.com>,
bpf@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>
Subject: Re: [PATCH v1] fs: Add kfuncs to handle idmapped mounts
Date: Tue, 4 Jul 2023 17:05:22 +0200 [thread overview]
Message-ID: <ZKQ1Mkf5G9CA1/9J@example.org> (raw)
In-Reply-To: <20230704-anrollen-beenden-9187c7b1b570@brauner>
On Tue, Jul 04, 2023 at 03:01:21PM +0200, Christian Brauner wrote:
> On Tue, Jul 04, 2023 at 07:42:53PM +0800, Hou Tao wrote:
> > Hi,
> >
> > On 6/30/2023 7:08 PM, Alexey Gladkov wrote:
> > > Since the introduction of idmapped mounts, file handling has become
> > > somewhat more complicated. If the inode has been found through an
> > > idmapped mount the idmap of the vfsmount must be used to get proper
> > > i_uid / i_gid. This is important, for example, to correctly take into
> > > account idmapped files when caching, LSM or for an audit.
> >
> > Could you please add a bpf selftest for these newly added kfuncs ?
> > >
> > > Signed-off-by: Alexey Gladkov <legion@kernel.org>
> > > ---
> > > fs/mnt_idmapping.c | 69 ++++++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 69 insertions(+)
> > >
> > > diff --git a/fs/mnt_idmapping.c b/fs/mnt_idmapping.c
> > > index 4905665c47d0..ba98ce26b883 100644
> > > --- a/fs/mnt_idmapping.c
> > > +++ b/fs/mnt_idmapping.c
> > > @@ -6,6 +6,7 @@
> > > #include <linux/mnt_idmapping.h>
> > > #include <linux/slab.h>
> > > #include <linux/user_namespace.h>
> > > +#include <linux/bpf.h>
> > >
> > > #include "internal.h"
> > >
> > > @@ -271,3 +272,71 @@ void mnt_idmap_put(struct mnt_idmap *idmap)
> > > kfree(idmap);
> > > }
> > > }
> > > +
> > > +__diag_push();
> > > +__diag_ignore_all("-Wmissing-prototypes",
> > > + "Global functions as their definitions will be in vmlinux BTF");
> > > +
> > > +/**
> > > + * bpf_is_idmapped_mnt - check whether a mount is idmapped
> > > + * @mnt: the mount to check
> > > + *
> > > + * Return: true if mount is mapped, false if not.
> > > + */
> > > +__bpf_kfunc bool bpf_is_idmapped_mnt(struct vfsmount *mnt)
> > > +{
> > > + return is_idmapped_mnt(mnt);
> > > +}
> > > +
> > > +/**
> > > + * bpf_file_mnt_idmap - get file idmapping
> > > + * @file: the file from which to get mapping
> > > + *
> > > + * Return: The idmap for the @file.
> > > + */
> > > +__bpf_kfunc struct mnt_idmap *bpf_file_mnt_idmap(struct file *file)
> > > +{
> > > + return file_mnt_idmap(file);
> > > +}
> >
> > A dummy question here: the implementation of file_mnt_idmap() is
> > file->f_path.mnt->mnt_idmap, so if the passed file is a BTF pointer, is
> > there any reason why we could not do such dereference directly in bpf
> > program ?
> > > +
> > > +/**
> > > + * bpf_inode_into_vfs_ids - map an inode's i_uid and i_gid down according to an idmapping
> > > + * @idmap: idmap of the mount the inode was found from
> > > + * @inode: inode to map
> > > + *
> > > + * The inode's i_uid and i_gid mapped down according to @idmap. If the inode's
> > > + * i_uid or i_gid has no mapping INVALID_VFSUID or INVALID_VFSGID is returned in
> > > + * the corresponding position.
> > > + *
> > > + * Return: A 64-bit integer containing the current GID and UID, and created as
> > > + * such: *gid* **<< 32 \|** *uid*.
> > > + */
> > > +__bpf_kfunc uint64_t bpf_inode_into_vfs_ids(struct mnt_idmap *idmap,
> > > + const struct inode *inode)
> > > +{
> > > + vfsuid_t vfsuid = i_uid_into_vfsuid(idmap, inode);
> > > + vfsgid_t vfsgid = i_gid_into_vfsgid(idmap, inode);
> > > +
> > > + return (u64) __vfsgid_val(vfsgid) << 32 |
> > > + __vfsuid_val(vfsuid);
> > > +}
> > > +
> > > +__diag_pop();
> > > +
> > > +BTF_SET8_START(idmap_btf_ids)
> > > +BTF_ID_FLAGS(func, bpf_is_idmapped_mnt)
> > > +BTF_ID_FLAGS(func, bpf_file_mnt_idmap)
> > > +BTF_ID_FLAGS(func, bpf_inode_into_vfs_ids)
> > > +BTF_SET8_END(idmap_btf_ids)
> > > +
> > > +static const struct btf_kfunc_id_set idmap_kfunc_set = {
> > > + .owner = THIS_MODULE,
> > > + .set = &idmap_btf_ids,
> > > +};
> > > +
> > > +static int __init bpf_idmap_kfunc_init(void)
> > > +{
> > > + return register_btf_kfunc_id_set(BPF_PROG_TYPE_UNSPEC, &idmap_kfunc_set);
> > > +}
> > > +
> > Is BPF_PROG_TYPE_TRACING sufficient for your use case ? It seems
> > BPF_PROG_TYPE_UNSPEC will make these kfuncs be available for all bpf
> > program types.
> > > +late_initcall(bpf_idmap_kfunc_init);
> >
>
> I don't want any of these helpers as kfuncs as they are peeking deeply
> into implementation details that we reserve to change. Specifically in
> the light of:
>
> 3. kfunc lifecycle expectations part b):
>
> "Unlike with regular kernel symbols, this is expected behavior for BPF
> symbols, and out-of-tree BPF programs that use kfuncs should be considered
> relevant to discussions and decisions around modifying and removing those
> kfuncs. The BPF community will take an active role in participating in
> upstream discussions when necessary to ensure that the perspectives of such
> users are taken into account."
>
> That's too much stability for my taste for these helpers. The helpers
> here exposed have been modified multiple times and once we wean off
> idmapped mounts from user namespaces completely they will change again.
> So I'm fine if they're traceable but not as kfuncs with any - even
> minimal - stability guarantees.
I thought that the mnt_idmap interface is already quite stable. I wanted
to give a minimal interface to bpf programs.
Would it be better if I hide the mnt_idmap inside the helper or are you
against using kfuncs at the moment ?
Like that:
__bpf_kfunc uint64_t bpf_get_file_vfs_ids(struct file *file)
{
struct mnt_idmap *idmap = file_mnt_idmap(file);
vfsuid_t vfsuid = i_uid_into_vfsuid(idmap, file->f_inode);
vfsgid_t vfsgid = i_gid_into_vfsgid(idmap, file->f_inode);
return (u64) __vfsgid_val(vfsgid) << 32 |
__vfsuid_val(vfsuid);
}
--
Rgrds, legion
next prev parent reply other threads:[~2023-07-04 15:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-30 11:08 [PATCH v1] fs: Add kfuncs to handle idmapped mounts Alexey Gladkov
2023-07-04 11:42 ` Hou Tao
2023-07-04 13:01 ` Christian Brauner
2023-07-04 15:05 ` Alexey Gladkov [this message]
2023-07-06 1:10 ` Alexei Starovoitov
2023-07-06 7:22 ` Christian Brauner
2023-07-07 1:04 ` Alexei Starovoitov
2023-07-06 14:37 ` Christoph Hellwig
2023-07-04 15:11 ` Alexey Gladkov
2023-07-04 15:28 ` Christian Brauner
2023-07-05 13:43 ` Alexey Gladkov
2023-07-05 14:18 ` Christian Brauner
2023-07-05 15:28 ` Alexey Gladkov
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=ZKQ1Mkf5G9CA1/9J@example.org \
--to=legion@kernel.org \
--cc=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=houtao@huaweicloud.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).