In this video, I'll tell you about containing namespaces.
Linux kernel namespaces, this is where it starts, because namespaces are a feature of
the Linux kernel.
And they provide isolation at different levels, for mounts, for processors, for users.
What does that mean?
If you're in a mount namespace, you can only see the files within that specific mount,
which is normally a directory, and you can't see the entire host operating system.
If you're in a process namespace, you can only see local processes.
And if you're in a user namespace, you have dedicated users within that namespace, as
if you were in a separate computer.
Now, the cool thing is that each container that is started by Poppin gets its own namespaces
to provide a strictly isolated environment.
Now, in order to fully understand how it works in Poppin, I would like to tell you a bit
about how it works on Linux.
And to start with, you can use LSNS.
LSNS is for list namespaces.
It's a Linux command.
And then you use grep pid to get a list of all namespaces and the processes that are
started in that namespace.
Now, if your container is in a namespace, an important command is a poppin unshare command.
Poppin unshare allows you to run commands within a specific namespace.
And that's going to be a very important command.
I will further explain.
Now, as containers are used in a namespace, so when a user starts a container, the user
account within the container is mapped to the user that started the container.
And as a result, within the container namespace, you may see a root prompt.
However, back in the namespace of the user that started the container, you'll get back
to the ordinary non-root user account.
As a result, the fact that you are a root in your rootless container doesn't mean anything.
And it's not dangerous for the host operating system.
Now, if a container is started with a specific user ID, this UID is mapped to a dynamically
generated UID in the user namespace.
And working with these mappings is important to arrange for permissions.
And that's what you want to do if you need persistent storage.
Now, how do namespaces, user accounts, and permissions come together?
Well, let's work on an example.
MariaDB by default starts with user ID 27.
If that needs write access to the bank-mounted directory MariaDB in the user home directory,
it needs to be assigned.
Oh, hang on.
What's going on?
Well, you want to make sure that your container can write files persistently.
As I will tell you in the next lesson, in order to do so, you are going to organize
a bind mount.
You give the container access to a directory in the root user home directory.
But hey, this container runs as user ID 27.
The user is user student.
How are you going to connect these together?
Well, that is what we are talking about.
You need to do something to give them the right permissions.
So in this case of MariaDB, a dynamic user ID is generated in the user namespace, and
this dynamic user ID can get permissions.
And in order to set these permissions within the container namespace from the user namespace,
you use Potman Unshare.
Potman Unshare can be used to run commands inside the container namespace without actually
entering the container.
Let's start with a simple demo before bringing this all to persistent storage and what is
needed for that.
So I'm still user student, and I'm using mkdir myfiles.
And then I'm using ls-ld myfiles.
And there I can see that myfiles, completely as expected, according to regular Linux permissions,
is owned by user and group student and permission mode is set to 755.
Next I'm using Potman Unshare, ls-ld myfiles.
And what do we see here?
Well, we see the default user mapping.
So these containers are running in their own namespace, and the default mapping is that
user student in the normal system environment is mapped to user root within the container,
and that is why Potman Unshare is giving me ls-ld myfiles, user root and group root
are the owner.
Now that's something that you can change.
So I'm using Potman Unshare shown 27 colon 27 myfiles.
So what does that mean?
Well, I'm going inside the container namespace to change ownership.
And then we need to verify that that worked.
Potman Unshare ls-ld on myfiles is showing that inside the container namespace, the owner
is now set to ID 27 and group ID 27.
What is this user and group ID 27?
Well, the container that I'm going to run, MariaDB is what we're running in our example.
This MariaDB by default is using the MariaDB user, which is user ID 27.
User ID 27 cannot be found in etcpasswd, and that is why I'm setting the user ID instead
of the user name as the owner.
And that works, because once the user ID can be found, the relation is automatically created.
Now the interesting thing is what has it done if you use in the normal user environment?
So ls-ld myfiles is showing what?
It's showing a dynamically used user ID.
This is this dynamic user mapping that I was talking about.
So myfiles is currently owned by user 524314.
That's the dynamic user ID.
And that is what we need for container storage configuration.
And you will learn in the next video how to deal with that.