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

[Tetsuo Handa]

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.