[PATCH 6/7] tomoyo: Convert from sb_mount to granular mount hooks

[Christian Brauner]

On Mon, Mar 23, 2026 at 03:32:14AM +0000, Song Liu wrote:
> 
> 
> > On Mar 22, 2026, at 3:46 AM, Tetsuo Handa <penguin-kernel at I-love.SAKURA.ne.jp> wrote:
> > 
> > On 2026/03/22 10:06, Song Liu wrote:
> >>>> @@ -70,6 +70,7 @@ static bool tomoyo_check_mount_acl(struct tomoyo_request_info *r,
> >>>> * @dir:      Pointer to "struct path".
> >>>> * @type:     Name of filesystem type.
> >>>> * @flags:    Mount options.
> >>>> + * @dev_path: Pre-resolved device/source path. Maybe NULL.
> >>> 
> >>> I guess that we can avoid passing maybe-NULL dev_name if Al Viro can accept
> >>> resolving maybe-NULL dev_path argument before calling LSM hooks.
> >> 
> >> If I understand the code correctly, tomoyo records requested_dev_name for
> >> new mount. namespace.c, OTOH, does NOT do kern_path() for new mount. This 
> >> is why we keep the maybe-NULL dev_name here. I personally think this is 
> >> the best approach without changing tomoyo behavior.
> > 
> > Well, namespace.c does kern_path() for new mount, but it happens a bit later after
> > security_mount_new() was called.
> > 
> >  do_new_mount_fc() => fc_mount() => vfs_get_tree() => fc->ops->get_tree() == e.g. ext4_get_tree()
> >  => get_tree_bdev() => get_tree_bdev_flags() => lookup_bdev() => kern_path()
> > 
> > @@ -3835,6 +3855,9 @@ static int do_new_mount(const struct path *path, const char *fstype,
> > err = parse_monolithic_mount_data(fc, data);
> > if (!err && !mount_capable(fc))
> > err = -EPERM;
> > +
> > + if (!err)
> > + err = security_mount_new(fc, path, mnt_flags, flags, data);
> > if (!err)
> > err = do_new_mount_fc(fc, path, mnt_flags);
> > 
> > 
> > Since not all filesystems need to resolve dev_name argument, conversion from dev_name
> > to "struct path" is up to individual filesystem. If we can use a flag like FS_REQUIRES_DEV
> > that tells whether that filesystem will resolve dev_name argument, I think we can resolve
> > the dev_name argument before security_mount_new() is called (and can avoid TOCTOU).
> 
> I guess we can add dev_path to fs_context?

No, when and how the path is resolved is entirely up to the individual
filesystem and we're not hoisting the block-based specific path lookup
up into the VFS while leaving the other stuff per-filesystem. And it's
not as trivial as you want it to be either.