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

Song Liu songliubraving at meta.com
Mon Mar 23 03:32:14 UTC 2026



> 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?

Thanks,
Song




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