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

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Samstag, dem 15.10.2022 um 19:23 -0400 schrieb Philip McGrath:
> On Saturday, October 1, 2022 12:54:27 PM EDT Ludovic Courtès wrote:
> > Hello!
> > 
> > Philip McGrath <philip@philipmcgrath.com> skribis:
> > > 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'?) […]
> > 
> > The choice of ‘bash-static’ rather than ‘bash-minimal’ is motivated
> > by
> > the fact that, in (gnu packages commencement), we want to make sure
> > ‘glibc-final’ does not retain references to its build-time
> > environment.
> > See #:allowed-references in ‘glibc-final’.
> > 
> 
> This makes sense as far as using 'bash-static' in Glibc. The aspects
> I'm unsure of are:
> 
>  1. If I'm packaging software that implements a function like
>     'system' (e.g. Racket, SML/NJ, Chez Scheme, etc.), should I use
>     'bash-minimal' or 'bash-static'?
> 
>  2. Do we really need 'bash-minimal' at all? Why not just replace it
>     with 'bash-static'?
We already explained those two to you. Racket, SML/NJ, Chez Scheme et
al. are not bootstrap-relevant, thus they can use bash-minimal.  Unlike
bash-static, bash-minimal can be grafted, i.e. a security bug in bash(-
minimal) that necessitates a version bump or similar does not cause a
world rebuild.  A security bug in bash-static does.

> In particular, AFAICT, 'bash-minimal' currently has a reference to
> 'bash-static' via Glibc:
> 
> --8<---------------cut here---------------start------------->8---
> $ guix size bash-minimal 
> store item                                                      
> total    self
> /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33             
> 38.3    36.6  50.4%
> /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib         
> 71.7    33.4  45.9%
> /gnu/store/720rj90bch716isd8z7lcwrnvz28ap4y-bash-static-5.1.8       
> 1.7     1.7   2.3%
> /gnu/store/chfwin3a4qp1znnpsjbmydr2jbzk0d6y-bash-minimal-5.1.8     
> 72.7     1.0   1.4%
> total: 72.7 MiB
> --8<---------------cut here---------------end--------------->8---
Everything has a reference to bash-static.  That doesn't mean the
static bash is ever invoked.

> > > 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.
> > 
> > This is not a viable option because build containers lack /bin/sh.
> > 
> 
> Right, this option would depend on making /bin/sh exist in the build
> environment.
> 
> I'd hoped this might be possible without having to change the daemon,
> but the ways I've tried so far haven't worked. I tried `(mkdir-p
> "/bin")`, but the build user apparently doesn't have sufficient
> permissions. Then I tried creating a nested container using `call-
> with-container` in which I could bind-mound the directory from 'bash-
> static' at '/bin', but I hit permissions errors that way, too. I also
> thought there might be a way to pass the options like 'build-chroot-
> dirs' to have it set up /bin/sh before it
> drops privileges, but I couldn't figure out how to do that.
> 
> > Overall, I think the current situation is a reasonable tradeoff. 
> > It forces us to do some patching, indeed, but I think that’s
> > acceptable: we’re talking about a handful of packages.
> > 
> > WDYT?
> > 
> > Ludo’.
> 
> The patching itself isn't so bad, and, as you say, it's limited to at
> least a relatively small number of packages. However, the fact that
> Glibc retains a reference to 'bash-static' affects nearly every
> package. It doesn't affect them very much, to be sure! But I think it
> does prevent using `guix shell --container` to create containers
> without a shell, and it likewise seems difficult to experiment with
> different shells. Or maybe it's really just that it disturbs my sense
> of aesthetics.
Functionality beats aesthetics.

Cheers