Re: [PATCH 00/23] proc: Introduce /proc/namespaces/ directory to expose namespaces lineary
From: Pavel Tikhomirov
Date: Tue Aug 04 2020 - 08:22:20 EST
On 8/4/20 8:43 AM, Andrei Vagin wrote:
On Thu, Jul 30, 2020 at 06:01:20PM +0300, Kirill Tkhai wrote:
On 30.07.2020 17:34, Eric W. Biederman wrote:
Kirill Tkhai <ktkhai@xxxxxxxxxxxxx> writes:
Currently, there is no a way to list or iterate all or subset of namespaces
in the system. Some namespaces are exposed in /proc/[pid]/ns/ directories,
but some also may be as open files, which are not attached to a process.
When a namespace open fd is sent over unix socket and then closed, it is
impossible to know whether the namespace exists or not.
Also, even if namespace is exposed as attached to a process or as open file,
iteration over /proc/*/ns/* or /proc/*/fd/* namespaces is not fast, because
this multiplies at tasks and fds number.
Could you describe with more details when you need to iterate
There are three ways to hold namespaces.
* file descriptors
When CRIU dumps a container, it enumirates all processes, collects file
descriptors and mounts. This means that we will be able to collect all
namespaces, doesn't it?
Yes we can. But it would be much easier for us to have all namespaces in
one place isn't it?
And this patch-set has another non-CRIU use case. It can simplify a view
to namespaces for a normal user. Lets consider some cases:
Lets assume we have an empty (no processes) mount namespace M which is
held by single open fd, which was put in a unix socket and closed, unix
socket has single open fd to it which was in it's turn put to another
unix socket and again and again until we reach unix socket max depth...
How should normal user find this mount namespace M?
Lets assume that M also has a nsfs bindmount which helds some empty
network namespace N... How should normal user find N?
Lets also assume that M has overmounted "/":
mount -t tmpfs tmpfs /
Now if you would enter M you would see single tmpfs (because of implicit
chroot to overmount on setns) in mountinfo and there is no way to see
full mountinfo if you does not know real root dentry... How should
normal user (or even CRIU) find N?
So my personal opinion is that we need this interface, maybe it should
be done somehow different but we need it.
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.