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

[Liliana Marie Prikler]

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 
> '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—and on a particular Bash executable—seems like a much 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.
> >        In versions of glibc before 2.1.3, [...] system()
> >        always returned 1 [...].
Note that always returning non-zero is required by POSIX 2017.

> >        [E]ven though POSIX.1-2001 requires a conforming
> >        implementation to provide a shell, that shell may not be
> >        available or executable if the calling program has
> >        previously called chroot(2) [...].
Which does nothing to aid us in actually shelling out.

> Finally, some possible courses of action:
> 
> 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' 
> is the best mechanism I've heard of so far, though I wish it were 
> 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