either if you fork into a new mount namespace, or enter an existing one.
It is possible to hold file descriptors from a foreign mount namespace. You can demonstrate this very easily, by finding a process in a foreign mount namespace such as [kdevtmpfs]
, and opening /proc/$PID/root
. (If I change to this directory and run /bin/pwd
, it seems to print the awesome error message /usr/bin/pwd: couldn't find directory entry in ‘..’ with matching i-node
, and strace
shows that getcwd()
returned (unreachable)/
).
Please define what happens to the existing references which a process holds to the current mount namespace - the current directory and current root (chroot) - when entering a new mount namespace.
If neither of these references were modified, there would not be much point entering a new mount namespace. E.g. opening a file /path/to/file
would open it from the old mount namespace, if the process' root still pointed into the old mount namespace.
Again, I would like to understand both the case of clone() with CLONENEWNS (like the unshare
command), and the case of setns() (like the nsenter
command).
/
and.
to refer to the new namespace, if the same paths did not exist in the new namespace? The answer was the kernel does not preserve the current locations of/
and.
at all : it resets both of them to point to the root directory in the new namespace. – sourcejedi May 20 '19 at 20:11