From: "Mickaël Salaün" <mic@digikod.net>
To: Song Liu <song@kernel.org>
Cc: bpf@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, kernel-team@meta.com,
andrii@kernel.org, eddyz87@gmail.com, ast@kernel.org,
daniel@iogearbox.net, martin.lau@linux.dev,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
kpsingh@kernel.org, mattbobrowski@google.com,
amir73il@gmail.com, repnop@google.com, jlayton@kernel.org,
josef@toxicpanda.com, gnoack@google.com, m@maowtm.org
Subject: Re: [PATCH v2 bpf-next 2/4] landlock: Use path_walk_parent()
Date: Fri, 6 Jun 2025 12:46:29 +0200 [thread overview]
Message-ID: <20250606.zo5aekae6Da6@digikod.net> (raw)
In-Reply-To: <CAPhsuW7MtxryseFsHF2xqBFS2UWammJatjf8UxBhytgn_nA4=g@mail.gmail.com>
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@kernel.org> wrote:
> >
> > On Tue, Jun 3, 2025 at 6:46 AM Mickaël Salaün <mic@digikod.net> 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
next prev parent reply other threads:[~2025-06-06 10:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-03 6:59 [PATCH v2 bpf-next 0/4] bpf path iterator Song Liu
2025-06-03 6:59 ` [PATCH v2 bpf-next 1/4] namei: Introduce new helper function path_walk_parent() Song Liu
2025-06-06 11:10 ` Mickaël Salaün
2025-06-06 14:40 ` Al Viro
2025-06-06 17:01 ` Song Liu
2025-06-03 6:59 ` [PATCH v2 bpf-next 2/4] landlock: Use path_walk_parent() Song Liu
2025-06-03 13:46 ` Mickaël Salaün
2025-06-04 19:37 ` Song Liu
2025-06-05 16:47 ` Song Liu
2025-06-06 10:46 ` Mickaël Salaün [this message]
2025-06-03 6:59 ` [PATCH v2 bpf-next 3/4] bpf: Introduce path iterator Song Liu
2025-06-03 15:13 ` Alexei Starovoitov
2025-06-04 17:22 ` Christian Brauner
2025-06-03 18:40 ` Andrii Nakryiko
2025-06-03 20:49 ` Yonghong Song
2025-06-03 21:10 ` Song Liu
2025-06-03 21:09 ` Song Liu
2025-06-03 21:44 ` Andrii Nakryiko
2025-06-03 23:20 ` Song Liu
2025-06-04 20:37 ` Andrii Nakryiko
2025-06-05 19:27 ` Matt Bobrowski
2025-06-05 21:14 ` Song Liu
2025-06-03 6:59 ` [PATCH v2 bpf-next 4/4] selftests/bpf: Add tests for bpf " Song Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250606.zo5aekae6Da6@digikod.net \
--to=mic@digikod.net \
--cc=amir73il@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=gnoack@google.com \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=josef@toxicpanda.com \
--cc=kernel-team@meta.com \
--cc=kpsingh@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=m@maowtm.org \
--cc=martin.lau@linux.dev \
--cc=mattbobrowski@google.com \
--cc=repnop@google.com \
--cc=song@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.