> 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? Thanks, Song
