Re: [PATCH 00/23] proc: Introduce /proc/namespaces/ directory to expose namespaces lineary

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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
namespaces?

There are three ways to hold namespaces.

* processes
* bind-mounts
* 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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux