On Thu, Jun 05, 2025 at 09:47:36AM -0700, Song Liu wrote: > On Wed, Jun 4, 2025 at 12:37 PM Song Liu <song@xxxxxxxxxx> wrote: > > > > On Tue, Jun 3, 2025 at 6:46 AM Mickaël Salaün <mic@xxxxxxxxxxx> wrote: > > > > > > Landlock tests with hostfs fail: > > > > > > ok 126 layout3_fs.hostfs.tag_inode_file > > > # RUN layout3_fs.hostfs.release_inodes ... > > > # fs_test.c:5555:release_inodes:Expected EACCES (13) == test_open(TMP_DIR, O_RDONLY) (0) > > > > > > This specific test checks that an access to a (denied) mount point over > > > an allowed directory is indeed denied. > > I just realized this only fails on hostfs. AFAICT, hostfs is only used > by um. Do we really need this to behave the same on um+hostfs? Yes, this would be a regression, and in fact it is not related to hostfs and it would be a new security bug. The issue is that the path_walk_parent() doesn't return the parent dentry but the underlying mount point if any. When choose_mountpoint() returns true, path_walk_parent() should continue to the following root check and potentiall the dget_parent() call. We need to be careful with the path_put() though. This issue was only spotted by this hostfs test because this one adds a rule which is tied to the inode of the mount which is in fact the same inode of the mount point because the mount is a bind mount. I'll send a new test that check the same thing but with tmpfs (for convenience, but it would be the same for any filesystem). > > Thanks, > Song > > > > > I am having trouble understanding the test. It appears to me > > the newly mounted tmpfs on /tmp is allowed, but accesses to > > / and thus mount point /tmp is denied? What would the walk in > > is_access_to_paths_allowed look like? The test checks that a mount is not wrongly identified as the underlying mount point. > > > > > It's not clear to me the origin of the issue, but it seems to be related > > > to choose_mountpoint(). > > > > > > You can run these tests with `check-linux.sh build kselftest` from > > > https://github.com/landlock-lsm/landlock-test-tools > > > > How should I debug this test? printk doesn't seem to work. The console log level is set to warn, so you can use pr_warn(). > > > > Thanks, > > Song