tetst teste tetet tetest tetetttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt
On 01/26/2017 01:46 PM, Eric W. Biederman wrote: > Alexei Starovoitov <a...@fb.com> writes: > >> in cases where bpf programs are looking at sockets and packets >> that belong to different netns, it could be useful to read netns inode, >> so that programs can make intelligent decisions. >> For example to disallow raw sockets in all non-init netns the program can do: >> if (sk->type == SOCK_RAW && sk->netns_inum != 0xf0000075) >> return 0; >> where 0xf0000075 inode comes from /proc/pid/ns/net >> >> Similarly TC cls_bpf/act_bpf and socket filters can do >> if (skb->netns_inum == expected_inode) > > Nacked-by: "Eric W. Biederman" <ebied...@xmission.com> > > Particularly you need to compare more than the inode number. > Further I have never guaranteed there will be exactly one inode > per network namespace, just that if the device number and the inode > number pair match they are the same. > > Beyond that the entire concept is complete rubbish. > > The only sane thing is to interpret whatever your bpf program in the > context of the program which installs it. > > If you can't do that you have a very broken piece of userspace > interface. Which appears to be the case here. > > Eric >
