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

Alexei Starovoitov
2020-03-27T23:02:59Z

On Fri, Mar 27, 2020 at 10:12:05AM -0600, David Ahern wrote:
> On 3/27/20 5:06 AM, Lorenz Bauer wrote:
> > 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. This means that if
> > there is a netdevice in my network namespace, and I have CAP_NET_ADMIN
> > or whatever, I can break the association.
> >
> > So, to be constructive: I'd prefer bpf_link to replace a netlink attachment and
> > vice versa. If you need to restrict control, use network namespaces
> > to hide the devices, instead of hiding the bpffs.
>
> I had a thought yesterday along similar lines: bpf_link is about
> ownership and preventing "accidental" deletes. What's the observability
> wrt to learning who owns a program at a specific attach point and can
> that ever be hidden.

Absolutely. all links should be visible somehow.
idr for links with equivalent get_next_id and get_fd_from_id will be available.
The mechanism for "human override" is tbd.