On 1/23/17 8:37 PM, Andy Lutomirski wrote: > Yes, it is a bug because cgroup+bpf causes unwitting programs to be > subject to BPF code installed by a different, potentially unrelated > process. That's a new situation. The failure can happen when a > privileged supervisor (whoever runs ip vrf) runs a clueless or > unprivileged program (the thing calling unshare()).
There are many, many ways to misconfigure networking and to run programs in a context or with an input argument that causes the program to not work at all, not work as expected or stop working. This situation is no different. For example, the only aspect of BPF_PROG_TYPE_CGROUP_SOCK filters that are namespace based is the ifindex. You brought up the example of changing namespaces where the ifindex is not defined. Alexei mentioned an example where interfaces can be moved to another namespace breaking any ifindex based programs. Another example is the interface can be deleted. Deleting an interface with sockets bound to it does not impact the program in any way - no notification, no wakeup, nothing. The sockets just don't work. The point of using a management tool like ip is to handle the details to make things sane -- which is the consistent with the whole point of ip netns vs running unshare -n. > > If the way cgroup+bpf worked was that a program did a prctl() or > similar to opt in to being managed by a provided cgroup-aware BPF > program, then I'd agree with everything you're saying. But that's not > at all how this code works. I don't want an opt-in approach. The program does not need to know or even care that it has some restriction. Today, someone runs 'ip netns exec NAME COMMAND' the command does not need to know or care that the network namespace was changed on it. Same with 'ip vrf exec' -- it is a network policy that is forced on the program by the user.
