Re: What 'sh' should 'system' use?

[Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>]

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 
> 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. 
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 
> > > 'bash-static' vs. 'bash- minimal'?)
> > 
> > Because cycles -- bash-minimal is linked to a (shared) glibc, which
> > is a separate package from bash-minimal, so glibc cannot use 
> > bash-minimal, it uses bash-static instead which is linked to a 
> > (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).
> > 
> > Also, why?  This is an implementation detail.  Who would the target
> > audience be for this documentation?
> > 
> 
> I don't mean "document the decision" to necessarily imply something 
> 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.
> 
> Specifically with respect to bash-minimal vs. bash-static, I'm still
> not clear on when I should use which. 
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