On Mon, Mar 30, 2020 at 04:25:07PM +0100, Edward Cree wrote: > 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'. 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.
