From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id 8LXjFmkVKGNvgwEAbAwnHQ (envelope-from ) for ; Mon, 19 Sep 2022 09:08:25 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id HXHOFmkVKGMUGQAAauVa8A (envelope-from ) for ; Mon, 19 Sep 2022 09:08:25 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id ED3E03C402 for ; Mon, 19 Sep 2022 09:08:24 +0200 (CEST) Received: from localhost ([::1]:60410 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oaAtE-00014C-2g for larch@yhetil.org; Mon, 19 Sep 2022 03:08:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52332) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oaAsD-000129-9W for guix-devel@gnu.org; Mon, 19 Sep 2022 03:07:21 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:6255) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oaAs8-0005tk-Lf for guix-devel@gnu.org; Mon, 19 Sep 2022 03:07:20 -0400 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4MWG2G5GfMz3wGC; Mon, 19 Sep 2022 09:07:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1663571224; bh=zsB0qgHBlOecLS1EGGQq8ri3L9zO0s+698XV13dtPLk=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=LAkNyGhR31fxyQcUX+rFPjOLylhBVmgfcrEPyHJsfV+EBVTvk8caw0KFBCtwFrSJ8 6zfQ1EujJ1bDIOyYWpFyhCPfcsSAEnImBF7sQr7JfkBB7LQIylQsfL6uaSXJbivgle vVt0fIyG4svxVdNS5+5oYVvWsmcAXYO7aYj26AV4= Message-ID: <3147250c1695e9ff0885cec9b2ba847a31071bb1.camel@ist.tugraz.at> Subject: Re: What 'sh' should 'system' use? From: Liliana Marie Prikler To: Philip McGrath , guix Cc: Maxime Devos , Liliana Marie Prikler Date: Mon, 19 Sep 2022 09:07:02 +0200 In-Reply-To: <2284386.8hzESeGDPO@bastet> References: <2284386.8hzESeGDPO@bastet> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.45.3 MIME-Version: 1.0 X-TUG-Backscatter-control: waObeELIUl4ypBWmcn/8wQ X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 Received-SPF: none client-ip=129.27.2.202; envelope-from=liliana.prikler@ist.tugraz.at; helo=mailrelay.tugraz.at X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1663571305; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=zsB0qgHBlOecLS1EGGQq8ri3L9zO0s+698XV13dtPLk=; b=sKBfzDKETPfzjgX/1/nfroBl2rq9f/tGLuaXQFgVsf+dQ+g+IceghRe7AXcHNzbb1+cvar mVws4EcD54JVNoV8lz5nwCRGzPt40Q2kXk4wq4ujHEWuM7eWZXxD0nyzi6acH7Dgdns4fG xUxVxW1J5oLsL6PfHYaU2GHVyAD8YqLlv4UBUvB8S8gwXH+Yx8yCxheGI0T8Vse1KJZSSd pvqeHx2yfYIlL9DmSMQCoHKdb5KbZl6sJvJEgCx/z66XJiI8WDDQQJ0YD4JggQ70RMPbUb jLLk1PpcPBe1o4aWBb/rNUxIuEx7E6+Wv6z1xNPwAsQxtwreIWZBWm008FVozw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1663571305; a=rsa-sha256; cv=none; b=K+oBbbVfbPpzOtZWSo86W+D+qcyI0HHIiEskxfEy3FbfA3i8zCzYqJYeKUGhS6LZjDnhGq 2ame1P2EBuBslRXbjpci/OAJyp61HMYj4VnCtAa0OrgGTBX70kwZqj8GjSPzIVxvFu/EV8 kAGNFHPDt3jX/cHO9Dq2RjP4ks5N/j0rSDWANKsyzSW9yAuCy6o9ZJD6qUWS0BrMbnkn/v BxM7wr3CvPNQ2luUgLBaKEyThMzogbhYLKG0iuolUBRo3bHrraPyi9b98TvJ35aegjWCdW 4m9vOI4ea3J/vEsCxbSFiXYx4nweaSkzl3Kuqv4FEfMeZl1XROadLnygyAehMw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=LAkNyGhR; dmarc=pass (policy=none) header.from=tugraz.at; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -4.64 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=LAkNyGhR; dmarc=pass (policy=none) header.from=tugraz.at; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: ED3E03C402 X-Spam-Score: -4.64 X-Migadu-Scanner: scn0.migadu.com X-TUID: GRkuYSi9e6zC Am Sonntag, dem 18.09.2022 um 20:13 -0400 schrieb Philip McGrath: > On the other hand, even Nix puts '/bin/sh' at its usual path: we are > really quite an outlier in this respect. (IIUC, Nix also has > '/usr/bin/env', but no other utilities at FHS paths.) We are not. We provide both /bin/sh and /usr/bin/env. If you're talking about the build container then that's a much smaller distinction. > First, a test program I tried in [9] seemed to indicate that > '_PATH_BSHELL' refered to 'bash-static', but 'system("echo $BASH")' > referred to 'bash-minimal'. It's possible that my test gave an > incorrect answer: I just tried 'guix size glibc' (I hadn't thought of > that earlier), and it doesn't list a reference to 'bash-minimal'. > But, if we are embedding references in libc to two different copies > of Bash, that seems clearly bad. We aren't embedding two references though; if we did, you'd see bash- minimal in the closure. > More broadly, I now think it would be better in we embedded zero > references to copies of Bash in libc. I don't think we can do that without breaking system. > I have changed my mind on this before, and I could be persuaded > otherwise. When I wrote the Racket patch for '/bin/sh' that had > been in place before the latest change, I initially was going to use > a hard-coded Bash only when '/bin/sh' did not exist, but the > discussion persuaded me it would make more sense to always use the > 'sh' from the package's inputs.[10] For Racket, a dependency on=20 > 'sh' didn't seem too unreasonable. It certainly isn't the largest package racket pulls in, no. > However, giving every program using Glibc a hard dependency on > Bash=E2=80=94and on a particular Bash executable=E2=80=94seems like a muc= h bigger > imposition. We're talking 1.7 MiB here. Certainly a "big" imposition, but nothing in comparison to the things you need in the store for bootstrapping purposes. Also note that bash-minimal, while only taking up 1.0 MiB for itself, requires both glibc and gcc:lib, which apart from creating a cycle does blow up its closure size quite a bit. > I now think it would be better to find 'sh' dynamically at run time Stop it. Get some help. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In versions of glibc before 2.1.3,= [...] system() > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 always returned 1 [...]. Note that always returning non-zero is required by POSIX 2017. > > =C2=A0 [E]ven though POSIX.1-2001 requires a conforming > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 implementation to provide a shell,= that shell may not be > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 available or executable if the cal= ling program has > > previously called chroot(2) [...]. Which does nothing to aid us in actually shelling out. > Finally, some possible courses of action: >=20 > 1) If we want to continue to hard-code a specific shell into Glibc, I > think we should document the decision (for example, why 'bash-static' > vs. 'bash-minimal'?) and recommendations for how packages should use > it: '_PATH_BSHELL'=20 > is the best mechanism I've heard of so far, though I wish it were=20 > standardized, and the fact that it can't be portably assumed to be a > string constant could be surprising. Note, that _PATH_BSHELL is only required for programs that want to be portable to other *nix systems. For most programs written with only the common Linux distros in mind, substituting "/bin/sh" is more than enough in terms of compatibility. > 2) If we want to make 'sh' a weak/dynamic reference, I think we > should strongly consider arranging to make it available at '/bin/sh' > when present. I expect this option would require less patching of > other packages *by far* than any other approach. How about no? > 3) If we want a dynamic 'sh' not located at '/bin/sh', I think we > should implement a function similar to '__bionic_get_shell_path()' > and use it for '_PATH_BSHELL', 'system', etc. That begs the question > of how the function should find 'sh', and I don't have an answer for > that. In principle, we could design a configuration mechanism for > 'confstr(_CS_PATH, buf, sizeof(buf))' and use it to find the shell: > that has some appeal, but making the mechanism extensible enough to > support "all of the standard utilities of POSIX.1-2017" seems like a > challenge. This sounds like a very long and convoluted way to hard-code a string. Remember that _PATH_BSHELL ought to be resolved to a compile-time pseudo-constant string. > What do you think? If you're really annoyed by the confstr thing, make it so that it hard- codes the #$bash-static/bin. Cheers