Re: /proc/self/mountinfo versus chroot

[Rick Troth]

Thanks for the quick responses! Please forgive the length here.
Also, noticing text/plain (good!) I am not sending HTML so I hope blanks
render correctly.


On 03/02/2016 10:21 PM, Pádraig Brady wrote:
> CCing the mailing list.

Wish I had thought to do that. Oh well.


> Ironically the preference for /proc/self/mountinfo was chosen
> to give more accurate info within chroots (and for bind mounts).
> The kernel has all the info, which is why we prefer that
> dynamically generated info.

Yes, ironic.
And yes, the most visible problem is with bind mounts. (not only for
'chroot'; see sample output below)


> What inaccuracies are you seeing exactly?
> I do vaguely remember references to issues on some ubuntu kernels,
> so perhaps there is a kernel fix to provide better info?

I should not have implied "inaccuracies". Sorry.
For the 'chroot' case it's more that I don't want to expose too much
about the host system.
Sounds like the rationale for crunching /proc/self/mountinfo was to get
accurate mount info.
The current code is a big step toward being more accurate in 'chroot'.

I run on a range of kernels, many of them older. But
/proc/self/mountinfo has been there for at least five years.
(I also use Coreutils and other packages, including a lot of non-Gnu
FOSS, on *BSD, Solaris, whatever. But am not expecting
/proc/self/mountinfo issues there soon.)


> The change to use /proc/self/mountinfo was done in v8.24.
> As a hack to avoid it, you could use an LD_PRELOAD wrapper to return
> ENOENT for open("/proc/self/mountinfo"), along the lines of:
> http://git.sv.gnu.org/cgit/coreutils.git/tree/tests/df/no-mtab-status.sh?id=v8.24

Thanks for the tip. I will try to get my head wrapped around that.

Some back story:
I've been doing virtualization since before I was doing Linux.
One of the helpful hacks in that space is to share some filesystems on
(shared) block devices.
There have been a number of failed attempts. (The distros now support
read-only root, or did. That helps.)
Lately, a shared "system disk" with an otherwise normal root and others
works best, and you bind these ...

        bin, sbin, lib, lib64, opt, boot

 ... and replicate /etc and /var appropriately.
One could alternatively sym-link these particular directories, but bind
mount is cleaner.

Traditional output with a cleaned-up /etc/mtab and without
/proc/self/mountinfo:

        Filesystem     1K-blocks    Used Available Use% Mounted on
        /dev/dasda1      2365444 1157156   1088128  52% /Linux-s390
        /dev/dasdb       2365540 1683840    561532  75% /
        udev              256704       0    256704   0% /dev
        tmpfs             256704       0    256704   0% /tmp

New behavior where 'df' consults /proc/self/mountinfo:

        Filesystem     1K-blocks    Used Available Use% Mounted on
        /dev/root        2365444 1157156   1088128  52% /lib
        /dev/dasdb       2365540 1683840    561532  75% /
        udev              256704       0    256704   0% /dev
        tmpfs             256704       0    256704   0% /tmp

Obviously "/dev/root" is vestigial and "/lib" is misleading.
In both of these, /Linux-s390 is the system disk and the usual system
directories in the root are bind mounted to their counterparts under it.
With the new code, only "/lib" shows and it's not the desired master.
Here is the full /proc/mounts content:

        rootfs / rootfs rw 0 0
        /dev/root /Linux-s390 ext2 rw,relatime,errors=continue 0 0
        /dev/dasdb / ext3
rw,relatime,errors=continue,barrier=0,data=ordered 0 0
        /dev/root /lib ext2 ro,relatime,errors=continue 0 0
        /dev/root /bin ext2 ro,relatime,errors=continue 0 0
        /dev/root /sbin ext2 ro,relatime,errors=continue 0 0
        /dev/root /usr ext2 rw,relatime,errors=continue 0 0
        /dev/root /boot ext2 rw,relatime,errors=continue 0 0
        /dev/root /opt ext2 ro,relatime,errors=continue 0 0
        /sys /sys sysfs rw,relatime 0 0
        udev /dev tmpfs rw,relatime 0 0
        devpts /dev/pts devpts rw,relatime,mode=600 0 0
        tmpfs /tmp tmpfs rw,relatime 0 0
        proc /proc proc rw,relatime 0 0

(System disk and /boot are actually RW because I was servicing it. Just
being honest with a "live" snapshot.)
So in either case ('chroot' or not) the leakage of too much reality is
counter productive.
Fixing /etc/mtab is trivial. Hiding selected /proc content is layers
upon layers, something they do in Redmond.


On 03/03/2016 03:51 AM, Ruediger Meier wrote:
> FYI issues with /etc/mtab were also discussed recently on util-linux 
> mailing list
> http://www.spinics.net/lists/util-linux-ng/msg12386.html

Wow ... that brings up some painful recent memories. (Don't get me
started about subvols.)

I can't fight the distributors, but the trend of sym-link /etc/mtab to
/proc/mounts is annoying at best.
Would have been better if they checked at boot time, "is it a plain
file?", and go traditional for that case.
Easy enough to make it a sym-link at install time. Then the sysadmin can
manually alter the behavior if he needs or wants.

Rendering a proper /etc/mtab is not rocket science.

-- R; <><