Brilliant! It took me almost a day to dive into ZeroMQ to reassure myself that there is nothing wrong with it. When I tried to write minimal test programs which call fork after pthread_create() in all combinations. When I realized that NSS stub module is what I need.
Instructions: 1) Compile NSS stub module: cc -shared -fPIC -pthread -o nss_zerodns.so.1 test.c (Note '.1' at the end). 2) Copy nss_zerodns.so.1 to /usr/local/lib 3) Apply the patch src_sbin_ping_main.c to ping source code. With this patch ping will not quit too early when the initial call to getaddrinfo() fails. 4) Add stub module to /etc/nsswitch.conf: edit 'hosts' line to be 'hosts: files dns zerodns' 5) Ping non-existent host, like 'ping foo.bar' 6) Ping will hang. The child process which it creates cannot be killed even with killall -9 ping сб, 9 янв. 2021 г. в 19:46, Mark Johnston <ma...@freebsd.org>: > > On Sat, Jan 09, 2021 at 04:16:49PM +0300, Vasily Postnicov wrote: > > Turns out, if you do not specify either -4 or -6 to ping, unsandboxed > > getaddrinfo() will be called in /usr/src/sbin/ping/main.c, line 139. > > (what's the point in sandboxing then, lol?) This somehow affects > > sandboxing. > > Indeed, that seems to be an issue with the recent merge of ping and > ping6. > > I guess the initial call to getaddrinfo() causes nsswitch.conf to be > parsed and your module is loaded before we fork(). The module is linked > with libthr but obviously ping itself is not. I'm sure this kind of > configuration worked at some point, there might have been a regression. > > If you can provide a stub NSS module that links libthr and demonstrates > the issue, it would be useful. > > > Look at the screenshot, it explains where fork() gets stuck. > > https://photos.app.goo.gl/T1B3Fo1hg6z7r3vZ6 > > And there are no other threads in the process? _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
