[lkml]   [2020]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 00/23] proc: Introduce /proc/namespaces/ directory to expose namespaces lineary

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 <> 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.

 \ /
  Last update: 2020-08-04 14:22    [W:0.214 / U:3.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site