From owner-freebsd-net@freebsd.org Sat Jan 9 16:46: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 83F154DBC3C for ; Sat, 9 Jan 2021 16:46:02 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 4DCm7Z36Cdz3hJh for ; Sat, 9 Jan 2021 16:46:02 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-il1-x134.google.com with SMTP id r17so13612981ilo.11 for ; Sat, 09 Jan 2021 08:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Z6vQP+M/rXS8ghAFVCueUi7OKp9uPnus6lkr/wVxE5k=; b=FdFe+1m8aE/UfShdrWr+VD2ZiVO7J3AAZnxusJguB87rC4nmgpzgBgXrkQPfjwMAwV uN2k1KcDhuzHcsLpYJlWleE6D1qHLlxfc6lWztdbz+6iHg6RYTz8vsHvhE2dF/CEJQ3j iWZGzA48Sq5HLiCW0Kursuq1ZamgMexrQrJK+1ALALo1JlIaY128T7o0OhawTzwjWtVI lkZxmAVvhj1Y0obyNXTKEuzfEnCs33OlfnJHf6slosb8CZ6zmskjVNN3gX/MyBkY/4Ra EwMHz0lwgx+ufpFrHl4VfZxhq0Di5I7Ha1kmQBR1Ys0H+Kp4/nnzwyJBFj1zhMyONGss aa4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=Z6vQP+M/rXS8ghAFVCueUi7OKp9uPnus6lkr/wVxE5k=; b=HPhSXu2AITfp4r8FebCseuJCSdnUcY/3nv3Mk01yCjBXHaF69X5C/+3Osw9b5bfC1n QqJvhKoZs4PVP+6uvSignJnhwgeabdZqZ9YIs8dRsbg5L2gjIwmufGnrxisde6CI4RKG VtyXOOArIqijLxAo+TE1vfI78s+q+b2+0LiLpQUU/p28OLX/HhtpAOckxxtPv0cItsOW MAxSNjbfRxdS3Cwr8BXCrz4VTu/+TW7Aqajo5kanapiPtCTd5VWbbnAXXrzCP0LGvJL/ Yjv7Ued/1s8spzRQ1q/IPLPJCiYBM6c1hCt2sLvBIdZSzWCCDPNLAJyRFUUjJoWpNpY3 5d8g== X-Gm-Message-State: AOAM532jzdxIbogIBypL/oW6BR5c5nbfsnVc2oeF9oAG3XrQItRe1V+b IftNcHOhhT9+y8h5GX6kpL8= X-Google-Smtp-Source: ABdhPJxMmQA9Evs2BqVgn+qBX2BQNWC8s4Y5g3n1/e7Rul9otUhcG/drhNpxTxJWKDP5aSKVFSfjhA== X-Received: by 2002:a05:6e02:1525:: with SMTP id i5mr9332234ilu.14.1610210761242; Sat, 09 Jan 2021 08:46:01 -0800 (PST) Received: from raichu ([142.126.164.150]) by smtp.gmail.com with ESMTPSA id k15sm3118940ilp.10.2021.01.09.08.45.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 09 Jan 2021 08:46:00 -0800 (PST) Sender: Mark Johnston Date: Sat, 9 Jan 2021 11:45:58 -0500 From: Mark Johnston To: Vasily Postnicov Cc: freebsd-net@freebsd.org Subject: Re: DNS using Name Service Switch module and Casper Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4DCm7Z36Cdz3hJh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] 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 16:46:02 -0000 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?