On 3/30/20 6:32 PM, Alexei Starovoitov wrote: >> >> This is not a large feature, and there is no reason for CREATE/UPDATE - >> a mere 4 patch set - to go in without something as essential as the >> QUERY for observability. > > As I said 'bpftool cgroup' covers it. Observability is not reduced in any way. You want a feature where a process can prevent another from installing a program on a cgroup. How do I learn which process is holding the bpf_link reference and preventing me from installing a program? Unless I have missed some recent change that is not currently covered by bpftool cgroup, and there is no way reading kernel code will tell me. ### To quote Lorenz from an earlier response: "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." ### That is my point. You are restricting what root can do and people will not want to resort to killing random processes trying to find the one holding a reference. This is an essential missing piece and should go in at the same time as this set.
