Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP

Edward Cree
2020-03-30T15:25:23Z

On 27/03/2020 23:02, Alexei Starovoitov wrote:
> On Fri, Mar 27, 2020 at 10:12:05AM -0600, David Ahern wrote:
>> 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'.
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?

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?

-ed