Re: [lmi] Transitive bind mounts in nested chroots

[Greg Chicares]

On 2020-05-21 17:52, Vadim Zeitlin wrote:
> On Thu, 21 May 2020 15:42:22 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Vadim--GNU/Linux bind mounts seem to work transitively. For example,
> GC> given a bullseye chroot nested in a centos chroot on a buster host,
> GC> doing this on the buster host (call this command "A"):
> GC> 
> GC>   mount --bind /srv/cache_for_lmi /srv/chroot/centos7lmi/srv/cache_for_lmi
> GC> 
> GC> and then this in the intermediate centos chroot (call this "B"):
> GC> 
> GC>   mount --bind /srv/cache_for_lmi /srv/chroot/bullseye/srv/cache_for_lmi
> GC> 
> GC> seems to accomplish the same effect in the innermost chroot as
> GC> doing this on the buster host (call this "C"):
> GC> 
> GC>   mount --bind /srv/cache_for_lmi 
> /srv/chroot/centos7lmi/srv/chroot/bullseye/srv/cache_for_lmi
> GC> 
> GC> All I want is the effect of "C". But "A+B" seems clearer to write,
> GC> because it treats the intermediate chroot as autonomous--as though
> GC> it were the ultimate host.

That autonomy is more important than I had at first realized.

First, for my
  debian-testing [bullseye] within centos within debian-stable [buster]
chroot chain, if I can treat the intermediate centos chroot exactly
the way I treat the host system on our redhat server, then I can run
almost the same script in each to set up a debian-testing chroot and
install lmi therein. (I say "almost" because RHEL-7.7 as configured by
a corporate IT department isn't quite identical to centos-7.7 as
installed by 'rinse'.) The separate centos and redhat scripts that I'd
been maintaining had diverged so much that it was hard to figure out
where they differed.

Second, without bind-mount transitivity, I'd need to either
 - bind-mount the innermost chroot's /var/cache/apt/archives/ before
   that chroot has been bootstrapped (although that actually has
   worked in the past, a future debootstrap version might refuse to
   install into a non-empty directory); or
 - split the script that's "almost" the same for centos and redhat
   (above) in two, at the point where debootstrap is run--which makes
   centos scripts (necessarily split) diverge from redhat scripts
   (which don't want to be split).

That's why I've taken the path you call "adventurous" below.

> GC> However...is "A+B" considered harmful?
> 
>  I'm not aware of any real drawbacks of doing it like this. Perhaps there
> might be a theoretical performance advantage in avoiding the intermediate
> bind but I'm pretty sure it would be unnoticeable even if it did exist (and
> I'm not even sure about this, the kernel might dereference the mount point
> only once, when mounting it -- which could probably be tested by unmounting
> the intermediate mount point and seeing if the final one still works).

Wow...the intermediate mount point doesn't even seem to exist.

Commit 7832140d fixed a problem with an intended mount chain,
one of whose links had failed to exist. I'll show the output of
this command, which uses 'sed' to make it terser:

findmnt -alR -o SOURCE,TARGET |grep archives |sed -e's,/srv/chroot,/S/C,g' 
-e's,[a-z0-9/]*[[]\([^]]*\)[]],\1,' 

Here's the output of that command, following the actual mount commands,
for the successful method committed as 7832140d:

  in debian-stable host:
mount --bind /var/cache/bullseye /srv/chroot/centos7lmi/var/cache/bullseye
  in centos intermediate chroot:
mount --bind /var/cache/bullseye 
/srv/chroot/lmi_bullseye_2/var/cache/apt/archives

/var/cache/bullseye                 /S/C/lmi_bullseye_2/var/cache/apt/archives
/var/cache/bullseye  /S/C/centos7lmi/S/C/lmi_bullseye_2/var/cache/apt/archives

I had anticipated that the second line would have been:

/S/C/lmi_bullseye_2/var/cache/apt/archives  
/S/C/centos7lmi/S/C/lmi_bullseye_2/var/cache/apt/archives

but evidently the kernel applied transitivity to rewrite the input
  A <-- B
  B <-- C
as simply
  A <-- B
  A <-- C

>  But you should keep in mind that I'm absolutely not an expert on Linux
> kernel or file systems and, moreover, I've never actually done something
> like this (although I use bind mounts themselves extensively).

There's one question that bothers me, though, which perhaps you can
answer: why must we even write '--bind'? AIUI, we can write
  mount        device directory
or
  mount --bind directory directory
but, if all mounts are either bind or regular, then '--bind' isn't
necessary because 'mount' can tell whether its first non-option
argument is a device or a directory.

My hypothesis is that that syllogism fails because not all mounts
are either bind or regular: the possibilities include
  mount [--regular] device directory
  mount --bind      directory directory
  mount --move      directory directory
where the nonexistent "--regular" option would always be elided,
and '--bind' is necessary to distinguish "bind" from "move" mounts.
Is that valid reasoning?

>  So I'd go with "C", just because I'm a sad disillusioned conservative (at
> least concerning my file systems) but AFAIK "A+B" should also work just
> fine, if you're feeling more adventurous.

It seems inappropriate to solicit your advice and then not take it,
but I hope I've given a good rationale above.