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.
