[PATCH 0/2] vfs/security/NFS/btrfs: clean up and fix LSM option handling

Ondrej Mosnacek omosnace at redhat.com
Mon May 17 13:46:04 UTC 2021

On Fri, Apr 9, 2021 at 7:39 PM Ondrej Mosnacek <omosnace at redhat.com> wrote:
> On Fri, Apr 9, 2021 at 2:28 PM Al Viro <viro at zeniv.linux.org.uk> wrote:
> > On Fri, Apr 09, 2021 at 01:12:52PM +0200, Ondrej Mosnacek wrote:
> > > This series attempts to clean up part of the mess that has grown around
> > > the LSM mount option handling across different subsystems.
> >
> > I would not describe growing another FS_... flag
> Why is that necessarily a bad thing?
> > *AND* spreading the
> > FS_BINARY_MOUNTDATA further, with rather weird semantics at that,
> > as a cleanup of any sort.
> How is this spreading it further? The patches remove one (rather bad)
> use of it in SELinux and somewhat reduce its use in btrfs.
> Hold on... actually I just realized that with FS_HANDLES_LSM_OPTS it
> is possible to do btrfs without FS_BINARY_MOUNTDATA and also eliminate
> the need for the workaround in vfs_parse_fs_param() (i.e. [2]).
> Basically instead of setting FS_BINARY_MOUNTDATA | FS_HANDLES_LSM_OPTS
> in btrfs_fs_type and neither in btrfs_root_fs_type, it is enough to
> set neither in btrfs_fs_type and only FS_HANDLES_LSM_OPTS in
> btrfs_root_fs_type. The security opts are then applied in the outer
> vfs_get_tree() call instead of the inner one, but the net effect is
> the same.
> That should pretty much do away with both the non-legit users of
> FS_BINARY_MOUNTDATA (selinux_set_mnt_opts() and btrfs). All the rest
> seem to be in line with the semantic.
> Would [something like] the above stand any chance of getting your approval?

So I posted this variant as v2 now:

> [2] https://lore.kernel.org/selinux/20210401065403.GA1363493@infradead.org/T/

Ondrej Mosnacek
Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.

More information about the Linux-security-module-archive mailing list