0

I was reading up on this and my initial (incorrect) thought was that it was to do with mount namespaces and chroot.

It got me wondering... I know that if no process exists with access to a file system1, Linux will automatically clean it up if it can. Amongst other things this allows implicit cleanup of initramfs file systems after pivot_root and chroot.

I also understand that PID namespaces have one parent namespace and others which are children of it, so all processes are visible to PID 1 started by the kernel.

But I'm less certain about whether or not there is a master mount namespace or even master root file system. There is, of course a root file system used by PID 1, but other than that is any filesystem meaningfully the root file system?


I think my concern comes from so many answers on SO, documentation and blogs all using terminology like "processes have their own view of the file system".

My problem is I don't understand in what sense there is any single file tree to refer to as the file tree...

...name spaces are copied, individually modified, implicitly destroyed. And even the root file system that we all think of as the main one isn't even the first because initramfs (usually) runs first with a different tree and then calls chroot.

So is this terminology technically incorrect, or is there somehow a single file tree that is the master / main one.


1Correct me if I'm wrong but

  • unshare -m mount /foo /bar has no effect because when the mount command line utility exits, no process will exist in the new namespace, so the new mount will be unmounted automatically.
  • If PID 1 is the only process and it has three mount points / /foo /bar and then it calls chroot /foo then both the original / and /bar will be unmounted. Again no process exists with access to either
7
  • 3
    Could you clarify what you mean by “if no process exists with access to a file system, Linux will automatically clean it up if it can”? May 15 at 10:22
  • @StephenKitt Correct me if I'm wrong. Firstly unshare -m mount /foo /bar has no effect because when the mount command line utility exits, no process will exist in the new namespace, so the new mount will be unmounted automatically.
    – ARF
    May 15 at 10:33
  • @StephenKitt Secondly if PID 1 is the only process and it has three mount points / /foo /bar and then it calls chroot into /foo then both / and /bar will be unmounted. Again no process exists with access to either.
    – ARF
    May 15 at 10:34
  • 1
    The root of the filesystem hierarchy, i.e. /, is part of a process environment, just like a process' current working directory is. A process can have a root directory separate from any other process (via chroot). I don't understand what you're saying about unmounting when a filesystem is no longer in use. Is that a Linux thing? Usually, a filesystem don't have to be in use to stay mounted.
    – Kusalananda
    May 15 at 10:43
  • 2
    I don't know why this is downvoted -- this is a totally legitimate question that could raise good answers (and the answer already existing succeed in answering some of the underlying misconception). I'm guessing this is because of the title? May 15 at 21:57
2

On Linux, each process has its own file system view, constrained by its mount namespace (and associated capabilities). Each mount namespace is associated with a user namespace. Since user namespaces constitute a rooted hierarchy, there is a single root user namespace. Among the mount namespaces associated with that user namespace, one of them has (or at least, had at some point) to contain everything required to access (transitively) everything mounted in the other mount namespaces; that is arguably the host system’s root mount namespace, and that namespace’s root could be considered as the host system’s root file system.

2
  • Just to clarify, are you saying that each user namespace only has one mount namespace? so unshare -m creates a new user namespace as well?
    – ARF
    May 15 at 19:37
  • 1
    No, and my answer is wrong in that regard; unshare -m only creates a new mount namespace. May 15 at 21:14
1

In Unixy systems like Linux, each process has it's view of the filessytem, a tree starting at (what it deeems to be) /. There are several ways in which a process can see a different set of files as another one, notably chroot(1) (and the underlying system call), the whole container machinery exands on this.

Note that when using e.g. containers (take a peek at Docker, for example), the processes running inside those can have a view of a filessystem that is totally inaccessible to other processes (unless they share/access explicitly). I.e., the /bin/ls a process inside a Docker container running Alpine Linux is nowhere outside a file.

1
  • I think you've highlighted my concern. Like your answer many discuss this as something like "view of the filesystem". That infers there is a single file system to refer to as the file system. Yet with mount namespaces and chroot, is that a technically accurate description? Should that not be "view of a filesystem"? I'll edit to clarify.
    – ARF
    May 15 at 20:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.