On Fri, Apr 9, 2021 at 7:39 PM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > On Fri, Apr 9, 2021 at 2:28 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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: https://lore.kernel.org/selinux/20210517134201.29271-1-omosnace@xxxxxxxxxx/T/ > > [2] https://lore.kernel.org/selinux/20210401065403.GA1363493@xxxxxxxxxxxxx/T/ -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc.
