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

From: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
To: Andrei Vagin <avagin@gmail.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Cc: Kirill Tkhai <ktkhai@virtuozzo.com>,
	viro@zeniv.linux.org.uk, adobriyan@gmail.com,
	davem@davemloft.net, akpm@linux-foundation.org,
	christian.brauner@ubuntu.com, areber@redhat.com,
	serge@hallyn.com, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 00/23] proc: Introduce /proc/namespaces/ directory to expose namespaces lineary
Date: Tue, 4 Aug 2020 15:11:55 +0300	[thread overview]
Message-ID: <b64dc485-de42-cd42-a0d6-b9962d9ca4fd@virtuozzo.com> (raw)
In-Reply-To: <20200804054313.GA100819@gmail.com>

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@virtuozzo.com> 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.