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.cavall...@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 ?
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
