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.
