On Mon, Mar 23, 2026 at 03:32:14AM +0000, Song Liu wrote: > > > > On Mar 22, 2026, at 3:46 AM, Tetsuo Handa > > <[email protected]> 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.
