Re: [lmi] Transitive bind mounts in nested chroots

[Vadim Zeitlin]

On Fri, 22 May 2020 20:57:42 +0000 Greg Chicares <address@hidden> wrote:

GC> First, for my
GC>   debian-testing [bullseye] within centos within debian-stable [buster]
GC> chroot chain, if I can treat the intermediate centos chroot exactly
GC> the way I treat the host system on our redhat server, then I can run
GC> almost the same script in each to set up a debian-testing chroot and
GC> install lmi therein.

 Yes, this is clearly a valuable goal.

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

 And so this rationale makes sense. I considered abstract "A", "B" and "C"
but in practice there are relationships between them that I didn't take
into account, but that clearly matter.


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

 I can't say that I'm completely surprised, but this definitely removes any
worries about any performance loss -- if the kernel doesn't even know about
the intermediate mounts, there can't be any.

GC> There's one question that bothers me, though, which perhaps you can
GC> answer: why must we even write '--bind'?

 Even if it could be deduced, I think --bind has the advantage of clarity.
And I'm not I really want something as low-level as "mount" to be too smart
and deduce the type of bound automatically anyhow.

GC> AIUI, we can write
GC>   mount        device directory
GC> or
GC>   mount --bind directory directory
GC> but, if all mounts are either bind or regular,

 I don't think it's a correct taxonomy. "Bind" is not the only operation
"mount" can perform: in addition to "--move" mentioned below, there is also 
"--rbind" and it wouldn't be surprising if others are added in the future.

GC> then '--bind' isn't necessary because 'mount' can tell whether its
GC> first non-option argument is a device or a directory.

 So knowing that the first argument is a directory is insufficient to infer
the operation mode.

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

 Yes, sure. I'd say that even without it deducing the operation mode
automatically would be more trouble than it's worth, but this consideration
shows that it can't be done at all.

GC> >  So I'd go with "C", just because I'm a sad disillusioned conservative (at
GC> > least concerning my file systems) but AFAIK "A+B" should also work just
GC> > fine, if you're feeling more adventurous.
GC> 
GC> It seems inappropriate to solicit your advice and then not take it,
GC> but I hope I've given a good rationale above.

 Yes, absolutely. And, in any case, my advice is purely advisory.

 Regards,
VZ

pgpzLiXmGxozE.pgp
Description: PGP signature