From: sashiko-bot@kernel.org
To: "Tarun Khandelwal" <tkhandelwal32@gmail.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
virtualization@lists.linux.dev,
"Eugenio Perez" <eperezma@redhat.com>
Subject: Re: [PATCH] fuse: propagate SB_POSIXACL to submounts
Date: Tue, 29 Sep 2026 09:56:32 +0000 [thread overview]
Message-ID: <20260929095632.70DDF1F00898@smtp.kernel.org> (raw)
In-Reply-To: <20260929094812.93374-1-tkhandelwal32@gmail.com>
> From: Tarun Khandelwal <tarun@supabase.io>
>
> fuse_fill_super_common() always sets SB_POSIXACL on the superblock, but
> fuse_fill_super_submount() never does. Submount superblocks are created
> from an fs_context with no sb_flags, so the superblock of an automounted
> FUSE_ATTR_SUBMOUNT directory (e.g. a virtiofs export containing another
> host mount) lacks SB_POSIXACL, even though it shares the fuse_conn, and
> thus fc->posix_acl, with its parent.
>
> Since IS_POSIXACL() is false on such a submount, the VFS:
>
> - fails setting POSIX ACLs with -EOPNOTSUPP and hides existing ACLs,
> without sending any request to the server;
> - applies the umask itself on create, so default ACLs on the server are
> not honoured for new files;
> [ ... ]
> reported by getfacl on the submount, and default ACLs and ACL-based
> access checks behave the same as on the root mount. Tested on v7.3-rc5
> in a QEMU guest.
>
> Signed-off-by: Tarun Khandelwal <tarun@supabase.io>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260929094812.93374-1-tkhandelwal32@gmail.com?part=1
prev parent reply other threads:[~2026-09-29 9:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 9:48 [PATCH] fuse: propagate SB_POSIXACL to submounts Tarun Khandelwal
2026-09-29 9:56 ` sashiko-bot [this message]
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=20260929095632.70DDF1F00898@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=eperezma@redhat.com \
--cc=mst@redhat.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=tkhandelwal32@gmail.com \
--cc=virtualization@lists.linux.dev \
/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.