On 7/31/20 1:13 AM, Eric W. Biederman wrote:
Kirill Tkhai <ktk...@virtuozzo.com> writes:
On 30.07.2020 17:34, Eric W. Biederman wrote:
Kirill Tkhai <ktk...@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.
I am very dubious about this.
I have been avoiding exactly this kind of interface because it can
create rather fundamental problems with checkpoint restart.
restart/restore :)
You do have some filtering and the filtering is not based on current.
Which is good.
A view that is relative to a user namespace might be ok. It almost
certainly does better as it's own little filesystem than as an extension
to proc though.
The big thing we want to ensure is that if you migrate you can restore
everything. I don't see how you will be able to restore these files
after migration. Anything like this without having a complete
checkpoint/restore story is a non-starter.
There is no difference between files in /proc/namespaces/ directory and
/proc/[pid]/ns/.
CRIU can restore open files in /proc/[pid]/ns, the same will be with
/proc/namespaces/ files.
As a person who worked deeply for pid_ns and user_ns support in CRIU, I don't
see any
problem here.
An obvious diffference is that you are adding the inode to the inode to
the file name. Which means that now you really do have to preserve the
inode numbers during process migration.
Which means now we have to do all of the work to make inode number
restoration possible. Which means now we need to have multiple
instances of nsfs so that we can restore inode numbers.
I think this is still possible but we have been delaying figuring out
how to restore inode numbers long enough that may be actual technical
problems making it happen.
Now maybe CRIU can handle the names of the files changing during
migration but you have just increased the level of difficulty for doing
that.
Yes adding /proc/namespaces/<ns_name>:[<ns_ino>] files may be a problem
to CRIU.
First I would like to highlight that open files are not a problem.
Because open file from /proc/namespaces/* are exactly the same as open
files from /proc/<pid>/ns/<ns_name>. So when we c/r an nsfs open file fd
on dump we readlink the fd and get <ns_name>:[<ns_ino>] and on restore
we recreate each dumped namespace and open an fd to each, so we can
'dup' it when restoring open file. It will be an fd to topologically
same namespace though ns_ino would be newly generated.
But the problem I see is with readdir. What if some task is reading
/proc/namespaces/ directory at the time of dump, after restore directory
will contain new names for namespaces and possibly in different order,
this way if process continues to readdir it can miss some namespaces or
read some twice.
May be instead of multiple files in /proc/namespaces directory, we can
leave just one file /proc/namespaces and when we open it we would return
e.g. a unix socket filled with all the fds of all namespacess visible at
this point. It looks like a possible solution to the above problem.
CRIU can restore unix sockets with fds inside, so we should be able to
dump process using this functionality.
If you have a specific worries about, let's discuss them.
I was asking and I am asking that it be described in the patch
description how a container using this feature can be migrated
from one machine to another. This code is so close to being problematic
that we need be very careful we don't fundamentally break CRIU while
trying to make it's job simpler and easier.
CC: Pavel Tikhomirov CRIU maintainer, who knows everything about namespaces C/R.
Further by not going through the processes it looks like you are
bypassing the existing permission checks. Which has the potential
to allow someone to use a namespace who would not be able to otherwise.
I agree, and I wrote to Christian, that permissions should be more strict.
This just should be formalized. Let's discuss this.
So I think this goes one step too far but I am willing to be persuaded
otherwise.
Eric
--
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.
