On 2026/03/23 19:16, Christian Brauner wrote: >>> 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 was expecting that "struct file_system_type"->fs_flags containing FS_REQUIRES_DEV is a sign that the dev_name argument is a pathname. But it seems that such assumption no longer holds true. For example, cramfs started treating dev_name like "mtd$num" as if /dev/mtdblock$num since 4.15. So, current TOMOYO logic causes mount request of cramfs with dev_name like "mtd0" to fail. >> 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. Then, how can LSM modules know that how the requested filesystem resolves the dev_name argument, without embedding filesystem specific resolution logic into individual LSM module? I want some flag like FS_REQUIRES_DEV that tells individual LSM module whether the dev_name argument should be interpreted as a pathname.
