On Mon, Dec 5, 2016 at 6:29 PM, Willem de Bruijn <willemb@xxxxxxxxxx> wrote: > On Mon, Dec 5, 2016 at 6:22 PM, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: >> On Mon, Dec 05, 2016 at 06:06:05PM -0500, Willem de Bruijn wrote: >> [...] >>> Eric also suggests a private variable to avoid being subject to >>> changes to PATH_MAX. Then we can indeed also choose an arbitrary lower >>> length than current PATH_MAX. >> >> Good. >> >>> FWIW, there is a workaround for users with deeply nested paths: the >>> path passed does not have to be absolute. It is literally what is >>> passed on the command line to iptables right now, including relative >>> addresses. >> >> If iptables userspace always expects to have the bpf file repository >> in some given location (suggesting to have a directory that we specify >> at ./configure time, similar to what we do with connlabel.conf), then >> I think we can rely on relative paths. Would this be flexible enough >> for your usecase? > > As long as it accepts relative paths, I think it will always work. > Worst case, a user has to cd. No need for hardcoding the bpf mount > point at compile time. > > I have the matching iptables patch for pinned objects, btw. Not for > elf objects, which requires linking to libelf and parsing the object, > which is more work (and perhaps best punted on by expanding libbpf in > bcc to include this functionality. it already exists under samples/bpf > and iproute2). While we're discussing the patch, another question, about revisions: I tested both modified and original iptables binaries on both standard and modified kernels. It all works as expected, except for the case where both binaries are used on a single kernel. For instance: iptables -A OUTPUT -m bpf --bytecode "`./nfbpf_compile RAW 'udp port 8000'`" -j LOG ./iptables.new -L Here the new binary will interpret the object as xt_bpf_match_v1, but iptables has inserted xt_bpf_match. The same problem happens the other way around. A new binary can be made robust to detect old structs, but not the other way around. Specific to bpf, the existing xt_bpf code has an unfortunate bug that it always prints at least one line of code, even if ->bpf_program_num_elems == 0. I notice that other extensions also do not necessarily only extend struct vN in vN+1. Is the above a known issue? -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
