Re: /etc/mtab and per-process namespaces

From: Ram Pai (linuxram_at_us.ibm.com)
Date: 11/01/05

  • Next message: Andrew Morton: "Re: New (now current development process)" 
    To: Rob Landley <rob@landley.net>
Date:	Mon, 31 Oct 2005 16:01:23 -0800

    On Mon, 2005-10-31 at 15:27, Rob Landley wrote:
    > On Monday 31 October 2005 13:11, Ram Pai wrote:
    > > > The big thing I've never figured out how to do is make umount -a work in
    > > > the presence of multiple namespaces. (Should it just umount what it
    > > > sees? I don't know how to umount everything because I can't find
    > > > everything...)
    > >
    > > Yes you won't find everything, since some of them are in a different
    > > namespaces. Instead unmount whatever you see. Or use /proc/mounts
    > > to unmount whatever is there in its namespace.
    >
    > But /proc/mounts is a symlink to self/mounts, and self is a symlink to $PID,
    > so after burrowing through the symlinks you wind up looking
    > at /proc/$PID/mounts.
    >
    > My concern is that if I have init, as root, try to perform a umount -a, it
    > _still_ won't get the mounts belonging to child processes with a separate
    > namespace. There's no "global view" of mounts available anywhere.

    and having a "global view" is a debatable issue. What you are asking for
    is a way for a process to be able to access all the mounts irrespective
    of which namespace it belongs to.

    I think 'umount -a' semantics has to be refined and made as 'unmount all
    the mounts belonging its namespace'. And if you agree with the
    semantics, than unmouting whatever is found in /proc/mounts would
    suffice.

    >
    > On the other hand, if we fork a child process with its own namespace, the
    > child performs a private mount, and then we kill that child process, does
    > that hidden mount get umounted cleanly via refcounting? (Or does it leak?)

    yes all the mounts in the namespace will get cleaned up if no processes
    have access to that namespace.

    >
    > If killing the processes umounts their private mounts, all init has to do is
    > make sure all child processes are dead before doing a umount -a on what's
    > left. (Then, of course, there's FUSE. Does killing the FUSE helper prevent
    > the mount from being umounted?)

    Again as I said above, 'umount -a' has just to restrict itself to its
    own namespace.

    RP
    >
    > It's a bit conceptually persnickety, so far...
    >
    > Rob

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Andrew Morton: "Re: New (now current development process)"

    Relevant Pages

    • Re: Devlabel and Fstab with usb pendrive
      ... /etc/updfstab and now my TinyDisk pendrive mounts on /mnt/flash (which ... another user comes along they can umount it. ... Anyone know how to either use updfstab to get it to set these options ... Problem is this occurs even if the file browser ...
      (Fedora)
    • Re: [RFC] FUSE permission modell (Was: fuse review bits)
      ... >> Shared subtrees and more support in userspace tools is needed before ... >> private namespaces can become really useful. ... I've been looking at the namespace code quite a bit and was ... > mount (and I guess that would impact any subsequent mounts from the ...
      (Linux-Kernel)
    • Re: [patch 0/8] unprivileged mount syscall
      ... make the mount tree under /$what as slave ... in the new namespace make the tree under ... Private namespaces are only good for keeping a bunch of mounts ...
      (Linux-Kernel)
    • Re: [RCF] [PATCH] unprivileged mount/umount
      ... > I also tried bind mounting from the child's namespace to the parent's, ... make un-removable mounts like the above, ... redundant for "normal" namespace operations). ... And leave it to adminstration to ensure that a tree isn't visible from ...
      (Linux-Kernel)
    • Re: [RFC] shared subtrees
      ... >> The major concern for automounting is that currently, ... >> any mounts in the second namespace. ... The same way we currently expire mounts. ... namespaces(provided all the umount-points belong to vfstructs belonging ...
      (Linux-Kernel)