[Dnsmasq-discuss] Multicast Netlink Crash on gVisor Kernel

[shamrock_sesame214 at simplelogin.com]

At this time the ip monitor command does not function in a gVisor container, although it is a WIP per gVisor. By nfset, I assume you mean the nftables equivalent of ipset. I don't believe this works either due to the architecture of namespaces that gVisor uses, with assumptions it should be used on the host OS.

My container will be run in a stub namespace without any L2 bridging, so it will not be receiving multicast anyway. I was thus hoping to see if it would be safe to compile out or perhaps open a bug report if the code may benefit from a restructure.

Thank you

On Tuesday, March 19th, 2024 at 5:09 AM, Nicolas Cavallari - nicolas.cavallari at green-communications.fr <nicolas.cavallari at green-communications.fr> wrote:

> 
> 
> On 16/03/2024 10:09, shamrock_sesame214--- via Dnsmasq-discuss wrote:
> 
> > Hello,
> > 
> > I am attempting to run dnsmasq DNS resolver in gVisor. gVisor is a hardened userspace kernel compatible with Kubernetes and Docker containers. At the moment, gVisor does not seem to support some routing features such as those found in linux/rtnetlink.h, including multicast related netlink subscriptions.
> > 
> > When I run dnsmasq in gVisor, I get this crash on startup:
> > 
> > cannot create netlink socket: Permission denied
> > 
> > Checking strace debugger, this was the attempted call made:
> > 
> > dnsmasq X bind(0x3 socket:[1], 0x7ee5d298ca58 {Family: AF_NETLINK, PortID: 0, Groups: 1360}, 0xc) = 0 (0x0) errno=13 (permission denied) (19.017µs)
> > 
> > The next call writes an error message to the terminal and begins exiting the program. I believe this to be caused by multicast route subscription near this line 73 in src/netlink.c: https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=blob;f=src/netlink.c;h=ef4b5fec3197ec1a855fca3bcf8d86eaa29ca479;hb=HEAD#l73
> > 
> > I noticed the comment in the code:
> > 
> > /* May not be able to have permission to set multicast groups don't die in that case */
> > 
> > I am unsure if line 79 will trigger this error anyway, and if this is intended behavior, as the program seems to crash anyway.
> 
> 
> Line 79 basically retries the bind without subscribing to any
> route/ifaddr groups. There is no reason for it to fail. Actually, i
> think the second call is a no-op and it could just be omitted, the
> kernel will autobind on the first sendmsg(). I'm not the maintainer so i
> don't know why this call was added.
> 
> Anyway, as of 2024, both calls do not require any privileges (try "ip
> monitor" as a simple user, which requests even more rtnetlink groups).
> Not being able to use rtnetlink multicast groups is a severe limitation,
> this should really be fixed in gVisor.
> 
> Out of curiosity, does dnsmasq's nfset support works inside gVisor ?