bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: ebiederm@xmission.com (Eric W. Biederman),
	Carlos Neira <cneirabustos@gmail.com>
Cc: netdev@vger.kernel.org, yhs@fb.com, brouer@redhat.com,
	bpf@vger.kernel.org
Subject: Re: [PATCH V11 0/4] BPF: New helper to obtain namespace data from current task
Date: Thu, 26 Sep 2019 09:16:33 -0700	[thread overview]
Message-ID: <5d8ce461cbb96_34102b0cab5805c4b9@john-XPS-13-9370.notmuch> (raw)
In-Reply-To: <87ef033maf.fsf@x220.int.ebiederm.org>

Eric W. Biederman wrote:
> Carlos Neira <cneirabustos@gmail.com> writes:
> 
> > Currently bpf_get_current_pid_tgid(), is used to do pid filtering in bcc's
> > scripts but this helper returns the pid as seen by the root namespace which is
> > fine when a bcc script is not executed inside a container.
> > When the process of interest is inside a container, pid filtering will not work
> > if bpf_get_current_pid_tgid() is used.
> > This helper addresses this limitation returning the pid as it's seen by the current
> > namespace where the script is executing.
> >
> > In the future different pid_ns files may belong to different devices, according to the
> > discussion between Eric Biederman and Yonghong in 2017 Linux plumbers conference.
> > To address that situation the helper requires inum and dev_t from /proc/self/ns/pid.
> > This helper has the same use cases as bpf_get_current_pid_tgid() as it can be
> > used to do pid filtering even inside a container.
> 
> I think I may have asked this before.  If I am repeating old gound
> please excuse me.
> 
> Am I correct in understanding these new helpers are designed to be used
> when programs running in ``conainers'' call it inside pid namespaces
> register bpf programs for tracing?
> 
> If so would it be possible to change how the existing bpf opcodes
> operate when they are used in the context of a pid namespace?
> 
> That later would seem to allow just moving an existing application into
> a pid namespace with no modifications.   If we can do this with trivial
> cost at bpf compile time and with no userspace changes that would seem
> a better approach.
> 
> If not can someone point me to why we can't do that?  What am I missing?

We have some management/observabiliity bpf programs loaded from privileged
containers that end up getting triggered in multiple container context. Here
we want the root namespace pid otherwise there would be collisions (same pid
in multiple containers) when its used as a key and we would have difficulty
finding the pid from the root namespace.

I guess at load time if its an unprivileged program we could convert it to
use the pid of the current namespace?

Or if the application is moved into a unprivileged container?

Our code is outside bcc so not sure exactly how the bcc case works. Just
wanted to point out we use the root namespace pid for various things
so I think it might need to be a bit smarter than just the moving an
existing application into a pid namespace.

.John

  parent reply	other threads:[~2019-09-26 16:16 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 15:20 [PATCH V11 0/4] BPF: New helper to obtain namespace data from current task Carlos Neira
2019-09-24 15:20 ` [PATCH bpf-next v11 1/4] fs/nsfs.c: added ns_match Carlos Neira
2019-09-24 15:20 ` [PATCH bpf-next v11 2/4] bpf: added new helper bpf_get_ns_current_pid_tgid Carlos Neira
2019-09-27 16:15   ` Andrii Nakryiko
2019-09-27 16:59     ` Yonghong Song
2019-09-27 17:24       ` Andrii Nakryiko
2019-09-28  1:42         ` Carlos Antonio Neira Bustos
2019-09-24 15:20 ` [PATCH bpf-next v11 3/4] tools: Added bpf_get_ns_current_pid_tgid helper Carlos Neira
2019-09-25  3:27   ` Yonghong Song
2019-09-24 15:20 ` [PATCH bpf-next v11 4/4] tools/testing/selftests/bpf: Add self-tests for new helper Carlos Neira
2019-09-25 16:07   ` Yonghong Song
2019-09-25 20:33     ` Carlos Antonio Neira Bustos
2019-09-24 18:01 ` [PATCH V11 0/4] BPF: New helper to obtain namespace data from current task Daniel Borkmann
2019-09-24 18:14   ` Carlos Antonio Neira Bustos
2019-09-26  0:59 ` Eric W. Biederman
2019-09-26 15:51   ` Yonghong Song
2019-09-26 16:16   ` John Fastabend [this message]
2019-09-26 17:01     ` Yonghong Song

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=5d8ce461cbb96_34102b0cab5805c4b9@john-XPS-13-9370.notmuch \
    --to=john.fastabend@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=brouer@redhat.com \
    --cc=cneirabustos@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=netdev@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).