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

[Tetsuo Handa]

On 2026/03/24 16:46, Song Liu wrote:
> On Mon, Mar 23, 2026 at 11:12 PM Tetsuo Handa
> <penguin-kernel at i-love.sakura.ne.jp> wrote:
>>
>> On 2026/03/24 4:31, Song Liu wrote:
>>>> 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?
>>
>> I guess something like untested diff shown below would work.
> 
> I think this doesn't work with erofs on file (requires
> CONFIG_EROFS_FS_BACKED_BY_FILE). erofs may not be the
> only one that has this problem.

This is incomplete but I think this is better than now because currently
mount() operation likely fails with -ENOENT if the requested filesystem
does not interpret fc->source as a pathname despite tomoyo_mount_acl()
always interprets fc->source as a pathname when FS_REQUIRES_DEV is set.

Also, mount() operation might by error succeed because tomoyo_mount_acl()
checks permission against unintended file when e.g. "mtd0" by chance exists
in the current directory.

We could add filesystem-specific logic to e.g. CONFIG_EROFS_FS_BACKED_BY_FILE
case that copies the resolved "struct path" to fc->source_path. But even without
adding filesystem-specific logic, mount() operation will succeed because
tomoyo_mount_acl() can handle fc->source as a string rather than a canonicalized
pathname.

Being able to know whether tomoyo_mount_acl() should interpret dev_name as a
pathname (which is subjected to canonicalization, and also subjected to more
complicated permission checks based on e.g. inode's uid/gid) is appreciated.