On Mon, Mar 30, 2020 at 04:25:07PM +0100, Edward Cree wrote:

On 27/03/2020 23:02, Alexei Starovoitov wrote:

quoted

On Fri, Mar 27, 2020 at 10:12:05AM -0600, David Ahern wrote:

quoted

I had a thought yesterday along similar lines: bpf_link is about
ownership and preventing "accidental" deletes.

The mechanism for "human override" is tbd.

Then that's a question you really need to solve, especially if you're
 going to push bpf_link quite so... forcefully.
Everything that a human operator can do, so can any program with the
 same capabilities/wheel bits.  Especially as the API that the
 operator-tool uses *will* be open and documented.  The Unix Way does
 not allow unscriptable interfaces, and heavily frowns at any kind of
 distinction between 'humans' and 'programs'.

can you share a link on such philosophy?
I was thinking something like CAPTCHA 'confirm if you're not a robot'
type of a button.
So humans doing 'bpftool link show' followed by 'bpftool link del id 123'
will work as expected, but processes cannot use the same api to
nuke other processes.

So what will the override look like?  A bpf() syscall with a special
 BPF_F_IM_A_HUMAN_AND_I_KNOW_WHAT_IM_DOING flag?  ptracing the link
 owner, so that you can close() its fd?  Something in between?

not sure yet.

In any case, the question is orthogonal to the bpf_link vs. netlink
 issue: the netlink XDP attach could be done with a flag that means
 "don't allow replacement/removal without EXPECTED_FD".  No?

Nothing to do with netlink, of course. Both XDP and tc bpf hooks
missing the concept of owner of the attachment.
For tc it's easier to implement and understand, since it allows
multi prog. If process A attaches a tc clsbpf prog via bpf_link
another process B will not be able to nuke it.