On Fri, Mar 27, 2020 at 9:12 AM David Ahern [off-list ref] 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.

We are talking about adding LINK_QUERY command that will return
attached BPF program and ifindex or cgroup (or whatever else) that it
is attached to.

If it's about which applications holds open FD to bpf_link, it's the
same problem as with any other FD, I'm not sure there is a
well-defined solution to this problem. Using drgn script to get this
is one possible solution that can be implemented today without
extending any of kernel APIs.