[Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for

[Henrique de Moraes Holschuh]

On Fri, 20 Jan 2012, Goswin von Brederlow wrote:
> Henrique de Moraes Holschuh <hmh at debian.org> writes:
> > The kernel has to return all entries that are visible to the current
> > namespace, otherwise you pretty much cannot know about the existence of
> > shadowed entries in the first place, and that has all sort of nasty
> > implications for security and troubleshooting.
> >
> > The kernel should NOT include entries that are out of reach due to
> > namespaces or chrooting, but I don't think this is quite correct right now.

...

> But isn't the rootfs out of reach because the initramfs "chroots" to the
> real root and starts /sbin/init? Back when pivot_root was used that
> was combined with an actual call to chroot. Before run-init combined the
> two.

That's what I meant with "I don't think this is quite correct right
now".

> I'm not realy disagreeing with you but argue that the duplicate rootfs
> entry is not visible to the namespace.

I am not sure how /proc/mounts and friends should play with chroot().  I
suppose it depends on whether one can actually reach that path somehow.
If it is forever unacessible, IMO it is effectively outside the
namespace and I believe it should not be visible.  But that's where I
reach the limits of my knowledge, and I can't really argue about it.

> What it should show is only the last entry, the tmpfs the chroot is
> on. All other entries are not visible to the processes inside the
> chroot.

I think you're correct in this.

> Note that in a chroot any mountpoints inside the chroot have their
> prefix removed (/home/mrvn/chroot becomes /) while others are left as
> is. That is wrong too IMHO. The filesystem the chroots / is on should
> become / even if the chroot is a directory instead of a mountpoint and
> entries outside the chroot should not be listed at all.

I also think you're correct here, but as I said, chroot() is tricky, and
I am wary of arguing too much about it without strong knowledge about
the nuances, which I don't have.

Maybe this thread really ought to move to linux-fsdevel or LKML?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh