From owner-freebsd-net@freebsd.org Sat Jan 9 13:17:02 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E041F4D4436 for ; Sat, 9 Jan 2021 13:17:02 +0000 (UTC) (envelope-from shamaz.mazum@gmail.com) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DCgVQ0LHhz3CqR; Sat, 9 Jan 2021 13:17:01 +0000 (UTC) (envelope-from shamaz.mazum@gmail.com) Received: by mail-oi1-x22a.google.com with SMTP id 15so14773516oix.8; Sat, 09 Jan 2021 05:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=W1XtUN9OfLZDMyLynu+HnNGYtmO9V17QUFd1TM/BLt0=; b=CLd8kXuB7SXi5+FPD1EzPYH3dzup8ndbuHeeauEoDtOlq+YiOLaTqRNR4QW3w2C0/l XExa6BYCTANLiAvuKtpeLugPmTNUMneb3UQYAm4+Uv7VJT4taORaKycOpZo3q7zVNRpu +ptpQ8AGyQPpfCl/2KWv+Jy8JLgB9gLnQtG7CoHQO+VGmTzio68YWJNyDrC10UdQ+lJ5 wWYNh52/WkIEhLUP55D7We4T7tFWiV/bHsokpR6F8Fl87Ip1dhTjzU7PrQZB9q3sMDs3 jJkYsjGMWo6jHHRnjrLfh4DzYCOo866EhSkma3ItGHt+38Y0tajoeISnKgqOjPUTHd/b Ph0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=W1XtUN9OfLZDMyLynu+HnNGYtmO9V17QUFd1TM/BLt0=; b=HVt1EspwAdPtGvzL+3JN15ebnPoKyyuc4BXotzSVdL6TiLZ7YqcRGFPybeG77VMG75 4Z0p+OJrWghIWQ+FznRaALwrEKLudnMzP1evOpiTIA9vQUOEx7mNqe4v2IeV8m0bdV9g sfZ00aDWVcr302X/8dk92RyG45f6/YzGmLRsP0PrOzK+g0k0C77nKb5QEYOZWwcbVN4b cIzSqJeLFdBFsVd+86m5Hh9k1HZB8GAw0gY1+vusZvdmMPP63i5sHC8racUoEPknuvwA H9kXRzgSAeS5S6/KMnq1L9r32rNrlCKtu6tRHZAW8rPKcnQ1YgWHrGG1GyYWCpoJ9d0M TJYg== X-Gm-Message-State: AOAM5308jGvqb8sgk8FJLfrvuuU1FFuflb51agLLC7rUH+5HO5Av3bYa K80ufzl79wkIEyxkuaJt1fI5utOpTlpBewgQFYVrKAhlptcBlw== X-Google-Smtp-Source: ABdhPJw/f75Bd+BLU8QQrqWrPBBIyL99oTqlHkDOmMwu25LOk9p2vRBcPHyJSDvinSxJfo9W5keS3dxXbykjKdKzM+s= X-Received: by 2002:a54:400e:: with SMTP id x14mr5260851oie.21.1610198220474; Sat, 09 Jan 2021 05:17:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vasily Postnicov Date: Sat, 9 Jan 2021 16:16:49 +0300 Message-ID: Subject: Re: DNS using Name Service Switch module and Casper To: Mark Johnston Cc: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4DCgVQ0LHhz3CqR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=CLd8kXuB; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of shamazmazum@gmail.com designates 2607:f8b0:4864:20::22a as permitted sender) smtp.mailfrom=shamazmazum@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::22a:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[0.999]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::22a:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::22a:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2021 13:17:02 -0000 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. Look at the screenshot, it explains where fork() gets stuck. https://photos.app.goo.gl/T1B3Fo1hg6z7r3vZ6 Oh yes, my module works if you specify -4 to ping command. =D0=BF=D1=82, 8 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3. =D0=B2 20:58, Vasily Postn= icov : > > Nevermind my last question. ZeroMQ is written on C++. Here is shown how y= ou can execute everything with almost empty main. > > https://stackoverflow.com/questions/38717534/how-do-i-start-a-c-thread-at= -program-startup > > For C the only way is to use __attribute__((constructor)) AFAIK > > =D0=BF=D1=82, 8 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3., 20:17 Vasily Postnicov = : >> >> I have noticed that after I kill stuck ping, the process spawned with >> cap_init() remains. I cannot even kill it with SIGKILL. This is the >> output of procstat on such a process. >> >> >> vasily 969 0.0 0.1 26428 6532 v0 I 22:43 0:00.00 ping >> vonbraun.local >> vasily 983 0.0 0.1 26428 6532 v0 I 22:43 0:00.00 ping >> resurrected.local >> vasily 1024 0.0 0.1 26428 6532 v0 I 22:49 0:00.00 ping >> resurrected.local >> vasily 1028 0.0 0.1 26428 6532 v0 I 22:49 0:00.00 ping >> resurrected.local >> root 1089 0.0 0.0 12976 2512 v1 S+ 22:58 0:00.01 grep pi= ng >> PID TID COMM TDNAME KSTACK >> 1028 100579 ping - mi_switch+0x155 >> sleepq_switch+0x109 sleepq_catch_signals+0x266 sleepq_wait_sig+0x9 >> _sleep+0x2aa umtxq_sleep+0x19e do_lock_umutex+0x744 >> __umtx_op_wait_umutex+0x49 sys__umtx_op+0x7a amd64_syscall+0x12e >> fast_syscall_common+0xf8 >> >> I checked ZeroMQ on which my NSS module is based. It does not use >> pthread_atfork(), but uses lots of other unusual pthread functions, >> like pthread_setaffinity_np() or pthread_setschedparam(). Do not know >> if it matters. Also I do not quite understand when the code in my >> module is executed. It should be executed after the capsicumized >> sandbox is created, should it not? And I got hang in the process of >> creating the sandbox. So I do not understand how my code affects this >> process :) >> >> >> =D0=BF=D1=82, 8 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3. =D0=B2 18:45, Mark John= ston : >> > >> > On Wed, Jan 06, 2021 at 07:08:14PM +0300, Vasily Postnicov wrote: >> > > That's what I found. >> > > >> > > At first, ping calls cap_init() in capdns_setup(). cap_init() forks = a >> > > process, then the parent returns and the child calls casper_main_loo= p(). >> > > The child and the parent both have a socket to communicate. >> > > casper_main_loop() calls zygote_init() and that one blocks on fork()= . I do >> > > not know how it could be. How can fork() block? >> > >> > Does you module somehow use pthread_atfork()? >> > >> > > The parent process later calls cap_service_open() and that function = calls >> > > cap_xfer_nvlist(). Because the child process is stuck somewhere in >> > > zygote_init() it never sends an nvlist back. So ping blocks. >> > >> > Can you show output from "procstat -kk " when this hang occurs? >> > >> > > All this is figured out by inserting printf()'s. LLDB refuses to run= ping >> > > with 'error: Child exec failed'. >> > >> > Presumably it needs to be run as root since ping(8) is a setuid >> > executable. >> > >> > > =D0=B2=D1=82, 5 =D1=8F=D0=BD=D0=B2. 2021 =D0=B3. =D0=B2 17:43, Mark = Johnston : >> > > >> > > > On Tue, Jan 05, 2021 at 10:02:37AM +0300, Vasily Postnicov wrote: >> > > > > Hello. I wrote a simple daemon called ZeroDNS which provides >> > > > functionality >> > > > > similar to multicast DNS, namely it discovers other participatin= g >> > > > machines >> > > > > over the LAN and stores their hostname and IPv4 address pairs. >> > > > > >> > > > > Here is a NSS module which allows the system to use information = from that >> > > > > daemon: >> > > > > https://github.com/shamazmazum/nss-zero-dns >> > > > > >> > > > > You need to modify /etc/nsswitch.conf, changing the line 'hosts:= files >> > > > dns' >> > > > > to 'hosts: files dns zerodns'. >> > > > > >> > > > > It all works on FreeBSD 12.2-RELEASE, but sometimes not on 13.0-= CURRENT. >> > > > > For example, ping(8) just blocks when trying to ping a host whos= e name is >> > > > > resolvable with ZeroDNS. Turns out that programs built with casp= er >> > > > support >> > > > > (like ping(8) and some others) stop working with my NSS module (= they just >> > > > > block trying to resolve the name). >> > > > >> > > > Presumably it's the casper process (i.e., cap_dns) that uses your >> > > > module? If the main ping process is blocked trying to resolve a n= ame, >> > > > it's waiting for the cap_dns process - where exactly is it getting >> > > > stuck? >> > > > >> > > > > Is there some kind of manual on how to write casper-compatible N= SS >> > > > modules? >> > > >