Re: PROBLEM: nf_conntrack_events autodetect mode invalidates NETLINK_LISTEN_ALL_NSID netlink socket option

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Bryce Kahle <bryce.kahle@xxxxxxxxxxxxx> wrote:
> I have posted the reproducer at
> https://github.com/brycekahle/netfilter-reproducer

Thanks.  Resolving this in a backwards compatible way is
intrusive because at the time the ctnetlink subscription happens
nsid isn't set yet.

We'd need a new callback in netlink_kernel_cfg so that ctnetlink
can be informed about activation of 'allnet' option on an existing
socket.

We'd also need a new flag in netfilter/core.c for that and not in
ctnetlink because else we'd create an unwanted module dependency in
nf_conntrack.

I can think of 3 alternative solutions:
1. revert back to 'default 1'.
   I don't want to do that because for almost all conntrack use
   cases the extension allocation is unecessary.

2. Switch netns creation behaviour to enable the extensions if
   init_net has nf_conntrack_events=1.
   This would require user intervention, but probably fine.
   Downside is that this will be different from all the other
   settings.

3. Add a module param to conntrack to override the default
   setting.  We already have such params for accounting and timestamps.

I'd go with 3).  Bryce, would that work for you?

Pablo, whats your take on this?
If you prefer I can work on the new netlink_kernel_cfg callback
to see how intrusive it really is.

Breakage scenario is:

1. Parent netns opens ctnetlink event sk
2. Parent netns sets ALL_NSID flag
3. No events from child netns, because no ctnetlink
   event sockets were created in this netns and thus
   conntrack objects get no event extension.

Extending the existing bind callback doesn't work because
ALL_NSID flag is set after event subscription.



[Index of Archives]     [Netfitler Users]     [Berkeley Packet Filter]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux