Photo by Cameron Venti on Unsplash

Linux Namespaces (part 2/5)

Namespace: Mount (mnt)

Lukasz
4 min readSep 5, 2020

--

For a short presentation of the functioning of this NS, I will use the command chroot. chroot itself doesn't have anything to do with the namespaces (at least nothing I know of). Still, I hope that a short example of usage chroot without and with mnt namespace will show possibilities of the namespaces itself.

Executing the first command makes the shell process started with the directory /directory set as the main file system (in the context of only this new shell process):

The above will work, but if it is to make sense (for this exercise) /directory must include a basic file system with commands such as "ps" (and others) which we will use. How to prepare such a file system in a directory? In Debian, we can use a debootstrap, in other distributions you have to do it by yourself, or you have to omit using chroot and just improvise a bit.

When the file system is ready, and we already have executed the chroot command, we can continue:

It turns out that the above will not work, so we must first mount /proc:

Now ps works, however when we will have finished playing with chroot:

It will turn out that we must also clean up, because proc in /directory/proc is still mounted (we can check it by invoking the command mount without any parameters or just by reviewing the content of /directory/proc):

And now let’s try to make it simpler by using mnt namespace:

Unshare is a command that lets us create a new NS (we will need the administrator’s rights, that is why we use sudo). The command can start passed statement in a freshly created namespace(s). Let me remind: each process has an attributed id for each of the namespaces defined in the system. Here all of them except for NS "mnt" (-m) will be inherited from the parent's process; however NS "mnt" will be defined especially for a given process, and currently, it will be used only by this process.

After a standard:

We can check a few things:

(1) lsns will show us a new namespace “mnt” attributed to our process of our new shell (we can check it through PID – echo $$ will display the process identifier - pid - of the shell)

(2) /proc from within the chrooted environment will not be visible in the host system (mount or ls /directory/proc will not show us anything – our chrooted /proc is mounted in another namespace and isolated from the "default" "mnt" NS

(3) Finishing work with chrooted shell will cause deleting a newly created NS (if no other process is using it) and automatically unmount the /proc system mounted "inside" chroot.

However before we finish experimenting with chrobot and NS (point 3 above), I would like to present a third, and last, command which helps us working with namespaces — nsenter — this command lets us “connect” to any NS (or a group of NS). Let’s assume that we have the same situation as the one above, after executing the commands:

Now, in another terminal we execute the command:

Let’s assume that we would like to “connect” to this “mnt” namespace with another shell process — for that purpose we could use the command nsenter.

And that’s it :) The shell process that will be started after the command will use the same “mnt” NS as the process 1234 — we can check it by, for instance, looking at the mounting points:

In this particular case (after executing the command nsenter above) we are connected to NS, but we do not work in the chrooted environment – obviously it has consequences – I recommend experimenting with the above environments – that one created after the command unshare + chroot and nsenter!

And that’s all that I found interesting during my tests with “mnt” namespace — I hope you enjoyed it! Next week I will write a few words about three namespaces: utc, user and ipc.

<< Linux Namespaces (part 1/5) | Linux Namespaces (part 3/5) >>

--

--

No responses yet