> On Mar 21, 2026, at 5:54 AM, Tetsuo Handa > <[email protected]> wrote: > > On 2026/03/19 3:43, Song Liu wrote: >> Replace tomoyo_sb_mount() with granular mount hooks. Each hook >> reconstructs the MS_* flags expected by tomoyo_mount_permission() >> using the original flags parameter where available. >> >> Key changes: >> - mount_bind: passes the pre-resolved source path to >> tomoyo_mount_acl() via a new dev_path parameter, instead of >> re-resolving dev_name via kern_path(). This eliminates a TOCTOU >> vulnerability. >> - mount_new, mount_remount, mount_reconfigure: use the original >> mount(2) flags for policy matching. >> - mount_move: passes pre-resolved paths for both source and >> destination. >> - mount_change_type: passes raw ms_flags directly. >> >> Also removes the unused data_page parameter from >> tomoyo_mount_permission(). >> >> Code generated with the assistance of Claude, reviewed by human. >> >> Signed-off-by: Song Liu <[email protected]> > > Basically OK. One question to Al Viro. > > Do you still refuse the idea of resolving dev_path argument before calling > LSM hooks > (the proposal you NAKed at > https://lkml.kernel.org/r/20250709102410.GU1880847@ZenIV ) > despite this series removes security_sb_mount() and security_move_mount() > hooks? > >> diff --git a/security/tomoyo/mount.c b/security/tomoyo/mount.c >> index 322dfd188ada..82ffe7d02814 100644 >> --- a/security/tomoyo/mount.c >> +++ b/security/tomoyo/mount.c >> @@ -70,6 +70,7 @@ static bool tomoyo_check_mount_acl(struct >> tomoyo_request_info *r, >> * @dir: Pointer to "struct path". >> * @type: Name of filesystem type. >> * @flags: Mount options. >> + * @dev_path: Pre-resolved device/source path. Maybe NULL. > > I guess that we can avoid passing maybe-NULL dev_name if Al Viro can accept > resolving maybe-NULL dev_path argument before calling LSM hooks.
If I understand the code correctly, tomoyo records requested_dev_name for new mount. namespace.c, OTOH, does NOT do kern_path() for new mount. This is why we keep the maybe-NULL dev_name here. I personally think this is the best approach without changing tomoyo behavior. Thanks, Song
