Hi Pablo, On Tue, Jan 14, 2020 at 11:38:35AM +0100, Pablo Neira Ayuso wrote: > On Tue, Jan 14, 2020 at 11:25:16AM +0100, Phil Sutter wrote: > > On Sun, Jan 12, 2020 at 11:40:27AM +0100, Pablo Neira Ayuso wrote: > > > On Sun, Jan 12, 2020 at 11:28:02AM +0100, Pablo Neira Ayuso wrote: > > > > On Fri, Jan 10, 2020 at 01:53:11PM +0100, Phil Sutter wrote: > > > > > On Thu, Jan 09, 2020 at 06:21:13PM +0100, Pablo Neira Ayuso wrote: [...] > > > > > > struct nft_ctx *nft_ctx_new(uint32_t flags); > > > > > > void nft_ctx_free(struct nft_ctx *ctx); > > > > > > > > > > > > +int nft_ctx_set_netns(struct nft_ctx *ctx, const char *netns); > > > > > > > > > > Is there a way to select init ns again? > > > > > > > > AFAIK, setns() does not let you go back to init ns once set. FWIW, I found interesting Python code[1] dealing with that. The logic is to open /proc/$$/ns/net before switching netns and storing the fd for later. To exit the netns again, it is passed to setns() and then closed. Note that the code there is much simpler and doesn't deal with mounts or non-existing entries in /var/run/netns/. Maybe libnftables doesn't need to either and it is OK to just bail if given netns doesn't exist? > > I noticed something I find worse, namely that libnftables as a library > > changes the application's netns. Anything it does after changing the > > context's netns applies to that netns only, no matter if it's creating a > > new nft context with NFT_CtX_DEFAULT flag or call iproute via system(). > > > > If we can't find a way to exit the netns again, one can safely assume > > that we are trapping a user's application in a netns with this feature. > > IIRC, you can fork(), then let the child enter the netns while parent > remain in the original netns. Yes, that's also the only way to operate in multiple netns in parallel. > > Maybe we should restrict per-netns operation to nft utility and perform > > the netns switch there? Maybe we could provide a "switch_netns()" > > routine in libnftables which is not bound to nft context so users may > > use it in their application? > > That's another possibility, yes. In that case, there is no need for > NFT_CTX_NETNS, which is just there to skip the socket initialization. I just think that a routine which affects things outside of nft scope shouldn't be tied as closely with nft context. Cheers, Phil [1] https://github.com/larsks/python-netns/blob/master/netns.py
