On 08/19/16 at 06:21pm, Pablo Neira Ayuso wrote: > On Fri, Aug 19, 2016 at 12:35:14PM +0200, Daniel Mack wrote: > > Also true. A cgroup can currently only hold one bpf program for each > > direction, and they are supposed to be set from one controlling instance > > in the system. However, it is possible to create subcgroups, and install > > own programs in them, which will then be effective instead of the one in > > the parent. They will, however, replace each other in runtime behavior, > > and not be stacked. This is a fundamentally different approach than how > > nf_tables works of course. > > I see, this looks problematic indeed, thanks for confirming this.
What exactly is problematic? I think the proposed mechanism is very clean in allowing sub groups to provide the entire program. This allows for delegation. Different orchestrators can manage different cgroups. It's different as Daniel stated. I don't see how this is problematic though. You brought up multiple tables which reflect the cumulative approach. This sometimes works but has its issues as well. Users must be aware of each other and anticipate what rules other users might inject before or after their own tables. The very existence of firewalld which aims at democratizing this collaboration proves this point. So in that sense I would very much like for both models to be made available to users. nftables+cgroups for a cumulative approach as well as BPF+cgroups for the delegation approach. I don't see why the cgroups based filtering capability should not be made available to both.
