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

[Song Liu]

On Mon, Mar 23, 2026 at 3:33 AM Tetsuo Handa
<penguin-kernel at i-love.sakura.ne.jp> wrote:
>
> 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?

IIUC, if an LSM cares about the dev_name of a new mount, it will have to look
into each individual filesystem. We can add a LSM hook for the filesystems to
call. But this will require changes to individual filesystem code. OTOH,
dev_name can probably bridge the gap as we change filesystems.

Would this work?

Thanks,
Song