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

[Maxime Devos]

On 19-09-2022 02:13, Philip McGrath wrote:
> 1) If we want to continue to hard-code a specific shell into Glibc,

We do, for reproducibility -- otherwise, the behaviour of the 'system' 
function depends on whatever is the current /bin/sh, and sometimes 
/bin/sh is updated (and on some foreign systems it might not even be the 
bash we are used to).

 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?

> 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.

I consider _not_ using it, and using (4) instead, to be best.
If not suitable (for example, because a shell is needed to run an actual 
shell script), then a plain "sh" looked up in the $PATH (like other 
binaries) and substitute*-ed by Guix should suffice.

> 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.

See (1) (reproducibility) -- also, you would need to modify the daemon 
for that, so there are compatibility concerns, and then we're stuck with 
the /bin/sh special case forever (unless breaking compatibility would 
later be considered acceptable).

> 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.

How about $PATH?

> 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.
> What do you think?

(4) Stop using 'system' in applications -- instead use whatever the 
language's equivalent of Guile's system*, execl ... or Guix' 'invoke'. 
Why?  Because 'system'-like functions requires quoting the command line 
arguments whereas in 'system*'-like functions you could just pass a list 
of command line arguments, and it's easy to get the quoting wrong, 
especially if some of the arguments are generated dynamically.

As a bonus, this could often remove a dependency on bash{-minimal,-static,}.

Maybe we can eventually remove _PATH_BSHELL and 'system' from our glibc 
(and Guile, ...).

Greetings,
Maxime.

OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature