From: Al Viro <viro@zeniv.linux.org.uk>
To: Hao Luo <haoluo@google.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
Yonghong Song <yhs@fb.com>, KP Singh <kpsingh@kernel.org>,
Shakeel Butt <shakeelb@google.com>,
Joe Burton <jevburton.kernel@gmail.com>,
Tejun Heo <tj@kernel.org>,
joshdon@google.com, sdf@google.com, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next v1 1/9] bpf: Add mkdir, rmdir, unlink syscalls for prog_bpf_syscall
Date: Sat, 12 Mar 2022 03:46:37 +0000 [thread overview]
Message-ID: <YiwXnSGf9Nb79wnm@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <20220225234339.2386398-2-haoluo@google.com>
On Fri, Feb 25, 2022 at 03:43:31PM -0800, Hao Luo wrote:
> This patch allows bpf_syscall prog to perform some basic filesystem
> operations: create, remove directories and unlink files. Three bpf
> helpers are added for this purpose. When combined with the following
> patches that allow pinning and getting bpf objects from bpf prog,
> this feature can be used to create directory hierarchy in bpffs that
> help manage bpf objects purely using bpf progs.
>
> The added helpers subject to the same permission checks as their syscall
> version. For example, one can not write to a read-only file system;
> The identity of the current process is checked to see whether it has
> sufficient permission to perform the operations.
>
> Only directories and files in bpffs can be created or removed by these
> helpers. But it won't be too hard to allow these helpers to operate
> on files in other filesystems, if we want.
In which contexts can those be called?
> +BPF_CALL_2(bpf_rmdir, const char *, pathname, int, pathname_sz)
> +{
> + struct user_namespace *mnt_userns;
> + struct path parent;
> + struct dentry *dentry;
> + int err;
> +
> + if (pathname_sz <= 1 || pathname[pathname_sz - 1])
> + return -EINVAL;
> +
> + err = kern_path(pathname, 0, &parent);
> + if (err)
> + return err;
> +
> + if (!bpf_path_is_bpf_dir(&parent)) {
> + err = -EPERM;
> + goto exit1;
> + }
> +
> + err = mnt_want_write(parent.mnt);
> + if (err)
> + goto exit1;
> +
> + dentry = kern_path_locked(pathname, &parent);
This can't be right. Ever. There is no promise whatsoever
that these two lookups will resolve to the same place.
> +BPF_CALL_2(bpf_unlink, const char *, pathname, int, pathname_sz)
> +{
> + struct user_namespace *mnt_userns;
> + struct path parent;
> + struct dentry *dentry;
> + struct inode *inode = NULL;
> + int err;
> +
> + if (pathname_sz <= 1 || pathname[pathname_sz - 1])
> + return -EINVAL;
> +
> + err = kern_path(pathname, 0, &parent);
> + if (err)
> + return err;
> +
> + err = mnt_want_write(parent.mnt);
> + if (err)
> + goto exit1;
> +
> + dentry = kern_path_locked(pathname, &parent);
> + if (IS_ERR(dentry)) {
> + err = PTR_ERR(dentry);
> + goto exit2;
> + }
Ditto. NAK; if you want to poke into fs/namei.c guts, do it right.
Or at least discuss that on fsdevel. As it is, it's completely broken.
It's racy *and* it blatantly leaks both vfsmount and dentry references.
NAKed-by: Al Viro <viro@zeniv.linux.org.uk>
next prev parent reply other threads:[~2022-03-12 3:46 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-25 23:43 [PATCH bpf-next v1 0/9] Extend cgroup interface with bpf Hao Luo
2022-02-25 23:43 ` [PATCH bpf-next v1 1/9] bpf: Add mkdir, rmdir, unlink syscalls for prog_bpf_syscall Hao Luo
2022-02-27 5:18 ` Kumar Kartikeya Dwivedi
2022-02-28 22:10 ` Hao Luo
2022-03-02 19:34 ` Alexei Starovoitov
2022-03-03 18:50 ` Hao Luo
2022-03-04 18:37 ` Hao Luo
2022-03-05 23:47 ` Alexei Starovoitov
2022-03-08 21:08 ` Hao Luo
2022-03-02 20:55 ` Yonghong Song
2022-03-03 18:56 ` Hao Luo
2022-03-03 19:13 ` Yonghong Song
2022-03-03 19:15 ` Hao Luo
2022-03-12 3:46 ` Al Viro [this message]
2022-03-14 17:07 ` Hao Luo
2022-03-14 23:10 ` Al Viro
2022-03-15 17:27 ` Hao Luo
2022-03-15 18:59 ` Alexei Starovoitov
2022-03-15 19:03 ` Alexei Starovoitov
2022-03-15 19:00 ` Al Viro
2022-03-15 19:47 ` Hao Luo
2022-02-25 23:43 ` [PATCH bpf-next v1 2/9] bpf: Add BPF_OBJ_PIN and BPF_OBJ_GET in the bpf_sys_bpf helper Hao Luo
2022-02-25 23:43 ` [PATCH bpf-next v1 3/9] selftests/bpf: tests mkdir, rmdir, unlink and pin in syscall Hao Luo
2022-02-25 23:43 ` [PATCH bpf-next v1 4/9] bpf: Introduce sleepable tracepoints Hao Luo
2022-03-02 19:41 ` Alexei Starovoitov
2022-03-03 19:37 ` Hao Luo
2022-03-03 19:59 ` Alexei Starovoitov
2022-03-02 21:23 ` Yonghong Song
2022-03-02 21:30 ` Alexei Starovoitov
2022-03-03 1:08 ` Yonghong Song
2022-03-03 2:29 ` Alexei Starovoitov
2022-03-03 19:43 ` Hao Luo
2022-03-03 20:02 ` Alexei Starovoitov
2022-03-03 20:04 ` Alexei Starovoitov
2022-03-03 22:06 ` Hao Luo
2022-02-25 23:43 ` [PATCH bpf-next v1 5/9] cgroup: Sleepable cgroup tracepoints Hao Luo
2022-02-25 23:43 ` [PATCH bpf-next v1 6/9] libbpf: Add sleepable tp_btf Hao Luo
2022-02-25 23:43 ` [PATCH bpf-next v1 7/9] bpf: Lift permission check in __sys_bpf when called from kernel Hao Luo
2022-03-02 20:01 ` Alexei Starovoitov
2022-03-03 19:14 ` Hao Luo
2022-02-25 23:43 ` [PATCH bpf-next v1 8/9] bpf: Introduce cgroup iter Hao Luo
2022-02-26 2:32 ` kernel test robot
2022-02-26 2:32 ` kernel test robot
2022-02-26 2:53 ` kernel test robot
2022-03-02 21:59 ` Yonghong Song
2022-03-03 20:02 ` Hao Luo
2022-03-02 22:45 ` Kumar Kartikeya Dwivedi
2022-03-03 2:03 ` Yonghong Song
2022-03-03 3:03 ` Kumar Kartikeya Dwivedi
2022-03-03 4:00 ` Alexei Starovoitov
2022-03-03 7:33 ` Yonghong Song
2022-03-03 8:13 ` Kumar Kartikeya Dwivedi
2022-03-03 21:52 ` Hao Luo
2022-02-25 23:43 ` [PATCH bpf-next v1 9/9] selftests/bpf: Tests using sleepable tracepoints to monitor cgroup events Hao Luo
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=YiwXnSGf9Nb79wnm@zeniv-ca.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=haoluo@google.com \
--cc=jevburton.kernel@gmail.com \
--cc=joshdon@google.com \
--cc=kafai@fb.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sdf@google.com \
--cc=shakeelb@google.com \
--cc=songliubraving@fb.com \
--cc=tj@kernel.org \
--cc=yhs@fb.com \
/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.