On Fri, Mar 27, 2020 at 9:12 AM David Ahern <dsahern@xxxxxxxxx> 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. 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.
