On 2026/03/25 4:03, Song Liu wrote: > On Tue, Mar 24, 2026 at 2:59 AM Tetsuo Handa > <[email protected]> wrote: >> >> 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. > > If I understand Christian correctly, the main challenge here is that > FS_REQUIRES_DEV doesn't imply fc->source is the path of a device.
Correct. FS_REQUIRES_DEV no longer implies that fc->source is a pathname. > Changing this assumption is a major change between VFS and many > filesystems. Wrong. I'm not trying to change this assumption. I'm trying to move LSM hook to a location after fc->source was interpreted by individual filesystem. > > I was thinking about something like: > > diff --git i/fs/super.c w/fs/super.c > index 378e81efe643..91ce3003bc23 100644 > --- i/fs/super.c > +++ w/fs/super.c > @@ -1676,6 +1676,9 @@ int get_tree_bdev_flags(struct fs_context *fc, > errorf(fc, "%s: Can't lookup blockdev", fc->source); > return error; > } > + error = security_mount_dev(fc, dev); > + if (error) > + return error; > fc->sb_flags |= SB_NOSEC; > s = sget_dev(fc, dev); > if (IS_ERR(s)) > > This allows the LSMs to monitor the dev being mounted in a new mount. Splitting into multiple LSM hooks does not work, for TOMOYO wants to check all parameters (parameters currently passed to security_mount_new() + the "struct path" which was resolved by individual filesystem from fc->source parameter) in one location. I'm not sure how security_mount_new() is called for fsconfig() case. Does https://man7.org/linux/man-pages/man2/fsconfig.2.html#EXAMPLES mean TOMOYO cannot check all parameters until move_mount() is called?
