From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id gNRGBaB3MWNGPgEAbAwnHQ (envelope-from ) for ; Mon, 26 Sep 2022 11:57:52 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id sL9jBKB3MWMRBAEAG6o9tA (envelope-from ) for ; Mon, 26 Sep 2022 11:57:52 +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 8EB35EB81 for ; Mon, 26 Sep 2022 11:57:51 +0200 (CEST) Received: from localhost ([::1]:59390 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ocks2-0006t9-6V for larch@yhetil.org; Mon, 26 Sep 2022 05:57:50 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49024) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ockc5-0000mg-Lc for guix-devel@gnu.org; Mon, 26 Sep 2022 05:41:21 -0400 Received: from mailrelay.tugraz.at ([129.27.2.202]:1648) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ockc1-0001l1-GJ for guix-devel@gnu.org; Mon, 26 Sep 2022 05:41:20 -0400 Received: from lprikler-laptop.ist.intra (gw.ist.tugraz.at [129.27.202.101]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4Mbd6m6KRNz3wch; Mon, 26 Sep 2022 11:41:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1664185265; bh=lc7Fsd2ANPnpJqtKZB8O7ohvmL8V1lW+VkVQ2/STYi4=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=FYws97SGyHg3Z4CRxWik0bEDR8aINgmiyeHKz7fizdlEpWy8h+cNLfjOD0Mfa4aWO HQMYhuwTztNR6+IlQX/4SIJEuGZI9vVVryetPTVrMssMJkGkRwztq50oR/iNYWaKHF Q96ndPdskUebwlhbK01jSpSqbNaQPMYGArD6p09g= Message-ID: <2c48543b291f059f58e8c8200bd2d34a88b31c1d.camel@ist.tugraz.at> Subject: Re: What 'sh' should 'system' use? From: Liliana Marie Prikler To: Philip McGrath , Maxime Devos , guix Cc: Liliana Marie Prikler Date: Mon, 26 Sep 2022 11:41:04 +0200 In-Reply-To: References: <2284386.8hzESeGDPO@bastet> <84acf321-e5b8-a138-0fc4-14e4e849f774@telenet.be> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.0 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=1664186271; 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=lc7Fsd2ANPnpJqtKZB8O7ohvmL8V1lW+VkVQ2/STYi4=; b=RNcIfrSMINFP+rcQOSkRN6Q/SKi5on8xEUATXPq/VbmulktbdhX3Nqe9Vd5vlh9SIf8CnU c0YM4wY5VF2b9BseEmUHrsWIeWw6+ZEQYE2Qi2JqSysct5CRe577vyQ3aYioSuvdjBOEzl RBJWe8mDpCDLx494vgJFopBy7APd+zgFCC7rKtsC0RCjCc/mQJbZQ2P3FQX9vVOalgDMnQ HcOKudZgf0LoZnm5adfT6cmO6cm1IpBdQ0mIx6ZQCQpjilHVBHggfWAnt6LitdHd07DqoJ iqpQhcsHqALXyxvPFoDfPpFiiMzs4fFu1Y95z5OBLJP0y8PWiKzwTeaI8CTvaQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1664186271; a=rsa-sha256; cv=none; b=PzyeARRH2b1sP7NyEnovAYm2oTjhNBzsn31v+GUlIpLJXIedk94Gb6rwF822AYPLFdXiTp 471VgbsX8fymSZX3ER6j6Pxk302yTU6TrPFbgll1aVR3qSObO+Ep0W3VjCOLN3l3UPNZzf pmAnZk11ix3pr9HJpsnswh2yUzPnOLAW7Jwj/6/RmxVFzKCai01JBONBCPJ1IGoHdvJt4s PQ7tdV8ygEtkqS0xV7YoUfd4beK8cr3PQF3AOxtotNi122RDSkN27or4KfFWxLpeGEXf+1 b0SymHinjK9ECvggZsI0dRO04DCivtL4U2e2pgUoDmhLcN6fpHIV47h8/l4enw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=FYws97SG; 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: -1.04 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=tugraz.at header.s=mailrelay header.b=FYws97SG; 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: 8EB35EB81 X-Spam-Score: -1.04 X-Migadu-Scanner: scn1.migadu.com X-TUID: 8ZtXwSv7j5Nd Hi Am Montag, dem 26.09.2022 um 03:04 -0400 schrieb Philip McGrath: > I definitely advocate 'system*'-like functions in general. Still, > 'system'-like functions exist: I'm advocating that Guix should should > have a consistent answer for how such functions should behave. How is the current answer inconsistent? > From a different perspective, this is part of why I've recently been > thinking we should find 'sh' dynamically: most programs/environments > don't, and shouldn't, need bash{-minimal,-static}, so it seems wrong > to make it a mandatory dependency of libc. Wrong in which sense? Technically, morally, philosophically? I don't think any of the values upheld by the GNU project, such as the four freedoms or the FSDG, nor our code of contract are violated by having bash-static in libc. > I think you're probably referring to the status quo, where "sh" is > looked up in the 'inputs' or a G-expression equivalent and an > absolute reference to that particular "sh" is embedded into the > package being built. (But, when cross-compiling, that "sh" would not > be in the$PATH in the build environment.) You still get an implicit bash-minimal in native-inputs. It's just not a regular input. > First, we have other POSIX-like shells packaged in Guix, such as > dash, zsh, and gash. Currently, to create an environment where one of > these shells is used to run 'system'-like functions (e.g. because > dash is supposed to be faster than bash), you would have to recompile > everything that depends on glibc. (Maybe you could craft a very ugly > graft.) The performance benefits of dash are irrelevant when you compare it to fork and exec. Thus I highly question the point you're trying to make. > Second, sometimes people may want to create environments, images, > etc. without an "sh" available. In some sense this is a special case > of using an alternate shell, but the consequences of the status quo > are especially notable. Currently, practically any environment or > image Guix creates will include bash-static, because glibc refers to > it. And yet, this bash-static will only be inside the container; with even its exact file name unknown and outside of PATH (and even _CS_PATH while we're at it). If your concern is that an attacker might break your containerized application and do arbitrary code execution in bash afterwards, I think you got your priorities mixed up; said attacker could probably side-load a static bash anyway. And I hardly doubt that any concern not related to security is critical either. > Programs in practice seem to look at "/bin/sh", and environments=20 > configuring it by choosing what (possibly nothing) to put at > "/bin/sh" from the perspective of programs in that environment. I mean, both are valid solutions. You're not going to put an unreliable shell as /bin/sh or attempt to shadow sh in your $PATH.=20 confstr and _CS_PATH are for paranoid people who believe you might (and even if you do use it, how sure are you that you're not just getting /bin/sh). > > > I think we should document the decision (for example, why=20 > > > 'bash-static' vs. 'bash- minimal'?) > >=20 > > Because cycles -- bash-minimal is linked to a (shared) glibc, which > > is a separate package from bash-minimal, so glibc cannot use=20 > > bash-minimal, it uses bash-static instead which is linked to a=20 > > (static) glibc (which might use a bootstrap bash (not 100% sure), > > but it's statically linked, so no reference to the bootstrap bash > > remains IIUC). > >=20 > > Also, why?=C2=A0 This is an implementation detail.=C2=A0 Who would the = target > > audience be for this documentation? > >=20 >=20 > I don't mean "document the decision" to necessarily imply something=20 > elaborate or formal, but I think the next person packaging a language > with a function like 'system' in its standard library shouldn't have > to reevaluate these questions from scratch. Also, if we decided the > right thing were to advocate for upstreams to do something > differently for the sake of portability (e.g. trying to get people to > use _CS_PATH---which I'm not suggesting), it would help to have a > rationale to point to. >=20 > Specifically with respect to bash-minimal vs. bash-static, I'm still > not clear on when I should use which.=C2=A0 You're not going to need bash-static. For most intents and purposes, you can ignore its existence. In fact, if it bothers you that much, I suggest hiding it like gcc. > The package descriptions are identical, and I haven't found a clear > (to me, at least) explanation in the source code comments. For > example, if bash-static is needed to avoid a cycle as you say, what > is the benefit of also having bash-minimal? bash-minimal is to be used in shell wrappers, as they don't need a full-blown bash (with among others the ability to load extensions, which bash-minimal lacks). Unlike bash-static, bash-minimal can be grafted (both itself and its dependents), so fixing a safety-critical bug in any of those does not cause a world rebuild. Cheers