On 3/9/24 11:10 AM, Alexei Starovoitov wrote:
On Sat, Mar 9, 2024 at 10:40 AM Yonghong Song <yonghong.song@xxxxxxxxx> wrote:
On 3/8/24 5:06 PM, Andrii Nakryiko wrote:
On Thu, Mar 7, 2024 at 3:27 PM Yonghong Song <yonghong.song@xxxxxxxxx> wrote:
Currently bpf_get_current_pid_tgid() is allowed in tracing, cgroup
and sk_msg progs while bpf_get_ns_current_pid_tgid() is only allowed
in tracing progs.
We have an internal use case where for an application running
in a container (with pid namespace), user wants to get
the pid associated with the pid namespace in a cgroup bpf
program. Currently, cgroup bpf progs already allow
bpf_get_current_pid_tgid(). Let us allow bpf_get_ns_current_pid_tgid()
as well.
With auditing the code, bpf_get_current_pid_tgid() is also used
by sk_msg prog. So I added bpf_get_ns_current_pid_tgid()
support for sk_msg prog, so now for all places where
bpf_get_current_pid_tgid() can be used, bpf_get_ns_current_pid_tgid()
can be used as well.
If tracing can call both bpf_get_current_pid_tgid() and
bpf_get_ns_current_pid_tgid(), can't we just add both into
bpf_base_func_proto() and have them available for all types of BPF
programs? If it's safe for tracing, it's safe for any program type, so
why not?
Do we need any capability to control bpf_get_[ns_]current_pid_tgid()?
nothing or CAP_BPF or CAP_PERFMON? In my opinion, pid/tgid
is available to user space and there is no leaking kernel private
data here, so bpf prog should be able to use it in all prog types.
I will wait for a few days. If no people object, I will incorporate
this in v2.
Yeah. It's safe without extra cap-s.
There is ns_match() inside. Nothing can leak.
Let's just move it to base_func_proto.
Sounds good. Will move both helpers to base_func_proto.
