bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
	Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrey Ignatov <rdna@fb.com>, Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link
Date: Mon, 30 Mar 2020 18:57:44 -0600	[thread overview]
Message-ID: <58cea4c7-e832-2632-7f69-5502b06310b2@gmail.com> (raw)
In-Reply-To: <20200331003222.gdc2qb5rmopphdxl@ast-mbp>

On 3/30/20 6:32 PM, Alexei Starovoitov wrote:
>>
>> This is not a large feature, and there is no reason for CREATE/UPDATE -
>> a mere 4 patch set - to go in without something as essential as the
>> QUERY for observability.
> 
> As I said 'bpftool cgroup' covers it. Observability is not reduced in any way.

You want a feature where a process can prevent another from installing a
program on a cgroup. How do I learn which process is holding the
bpf_link reference and preventing me from installing a program? Unless I
have missed some recent change that is not currently covered by bpftool
cgroup, and there is no way reading kernel code will tell me.

###
To quote Lorenz from an earlier response:

"However, this behaviour concerns me. It's like Windows not
letting you delete a file while an application has it opened, which just
leads to randomly killing programs until you find the right one. It's
frustrating and counter productive.

You're taking power away from the operator. In your deployment scenario
this might make sense, but I think it's a really bad model in general.
If I am privileged I need to be able to exercise that privilege."
###

That is my point. You are restricting what root can do and people will
not want to resort to killing random processes trying to find the one
holding a reference. This is an essential missing piece and should go in
at the same time as this set.

  reply	other threads:[~2020-03-31  0:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30  2:59 [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link Andrii Nakryiko
2020-03-30  2:59 ` [PATCH v3 bpf-next 1/4] bpf: implement bpf_link-based cgroup BPF program attachment Andrii Nakryiko
2020-03-31  0:05   ` Andrey Ignatov
2020-03-31  0:38     ` Alexei Starovoitov
2020-03-31  1:06       ` Andrii Nakryiko
2020-03-30  2:59 ` [PATCH v3 bpf-next 2/4] bpf: implement bpf_prog replacement for an active bpf_cgroup_link Andrii Nakryiko
2020-03-30  3:00 ` [PATCH v3 bpf-next 3/4] libbpf: add support for bpf_link-based cgroup attachment Andrii Nakryiko
2020-03-30  3:00 ` [PATCH v3 bpf-next 4/4] selftests/bpf: test FD-based " Andrii Nakryiko
2020-03-30 14:49 ` [PATCH v3 bpf-next 0/4] Add support for cgroup bpf_link David Ahern
2020-03-30 20:20   ` Andrii Nakryiko
2020-03-30 20:45     ` David Ahern
2020-03-30 20:50       ` Alexei Starovoitov
2020-03-30 22:50       ` Alexei Starovoitov
2020-03-30 23:43         ` David Ahern
2020-03-31  0:32           ` Alexei Starovoitov
2020-03-31  0:57             ` David Ahern [this message]
2020-03-31  1:17               ` Alexei Starovoitov
2020-04-01  1:42                 ` David Ahern
2020-04-01  2:04                   ` Alexei Starovoitov
2020-03-31  3:54               ` Andrii Nakryiko
2020-03-31 16:54                 ` David Ahern
2020-03-31 17:03                   ` Andrii Nakryiko
2020-03-31 17:11                   ` Alexei Starovoitov
2020-03-31 21:51                 ` Edward Cree
2020-03-31 22:44                   ` David Ahern
2020-04-01  0:45                     ` Andrii Nakryiko
2020-04-01  0:22                   ` Andrii Nakryiko
2020-04-01 14:26                     ` Edward Cree
2020-04-01 17:39                       ` Andrii Nakryiko

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=58cea4c7-e832-2632-7f69-5502b06310b2@gmail.com \
    --to=dsahern@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.com \
    --cc=netdev@vger.kernel.org \
    --cc=rdna@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).