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

On 3/27/20 5:06 AM, Lorenz Bauer wrote:

quoted

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.