On Mon, Mar 23, 2026 at 3:33 AM Tetsuo Handa <[email protected]> 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
