On 12/19/16 5:25 PM, Andy Lutomirski wrote:
> net.socket_create_filter = "none": no filter
> net.socket_create_filter = "bpf:baadf00d": bpf filter
> net.socket_create_filter = "disallow": no sockets created period
> net.socket_create_filter = "iptables:foobar": some iptables thingy
> net.socket_create_filter = "nft:blahblahblah": some nft thingy
> net.socket_create_filter = "address_family_list:1,2,3": allow AF 1, 2, and 3
Such a scheme works for the socket create filter b/c it is a very simple use
case. It does not work for the ingress and egress which allow generic bpf
filters.
...
>> you're ignoring use cases I described earlier.
>> In vrf case there is only one ifindex it needs to bind to.
>
> I'm totally lost. Can you explain what this has to do with the cgroup
> hierarchy?
I think the point is that a group hierarchy makes no sense for the VRF use
case. What I put into iproute2 is
cgrp2/vrf/NAME
where NAME is the vrf name. The filter added to it binds ipv4 and ipv6 sockets
to a specific device index. cgrp2/vrf is the "default" vrf and does not have a
filter. A user can certainly add another layer cgrp2/vrf/NAME/NAME2 but it
provides no value since VRF in a VRF does not make sense.
...
>>> I like this last one, but IT'S NOT A POSSIBLE FUTURE EXTENSION. You
>>> have to do it now (or disable the feature for 4.10). This is why I'm
>>> bringing this whole thing up now.
>>
>> We don't have to touch user visible api here, so extensions are fine.
>
> Huh? My example in the original email attaches a program in a
> sub-hierarchy. Are you saying that 4.11 could make that example stop
> working?
Are you suggesting sub-cgroups should not be allowed to override the filter of
a parent cgroup?
