On 2026/03/24 16:46, Song Liu wrote: > On Mon, Mar 23, 2026 at 11:12 PM Tetsuo Handa > <[email protected]> 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.
