Re: [RESEND] [PATCHv4 1/2] uapi: fuse: Add FUSE_SECURITY_CTX

[Chirantan Ekbote <chirantan@chromium.org>]

Hi Vivek,

On Tue, Jun 15, 2021 at 6:28 AM Vivek Goyal <vgoyal@redhat.com> wrote:
>
> On Wed, Jul 22, 2020 at 06:07:57PM +0900, Chirantan Ekbote wrote:
> > Add the FUSE_SECURITY_CTX flag for the `flags` field of the
> > fuse_init_out struct.  When this flag is set the kernel will append the
> > security context for a newly created inode to the request (create,
> > mkdir, mknod, and symlink).  The server is responsible for ensuring that
> > the inode appears atomically with the requested security context.
> >
> > For example, if the server is backed by a "real" linux file system then
> > it can write the security context value to
> > /proc/thread-self/attr/fscreate before making the syscall to create the
> > inode.
> >
> > Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
>
> Hi Chirantan,
>
> I am wondering what's the status of this work now. Looks like it
> was not merged.
>
> We also need the capability to set selinux security xattrs on newly
> created files in virtiofs.
>
> Will you be interested in reviving this work and send patches again
> and copy the selinux as well as linux security module list
> (linux-security-module@vger.kernel.org) as suggested by casey.
>

Not really.  We have our own local solution for this (see below) so if
you or someone else wants to pick it up, please go ahead.

> How are you managing in the meantime. Carrying patches in your own
> kernel?
>

Kind of. This patch series changes the protocol and the feature bit we
were using was claimed by FUSE_SUBMOUNTS instead so carrying it
locally is not really viable long term.  Instead we're carrying a
patch similar to the original RFC patch that doesn't change the
protocol [1].

Chirantan

[1]: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2581172