On Fri, Jul 08, 2016 at 07:35:33AM -0700, James Bottomley wrote:
On Fri, 2016-07-08 at 02:44 -0500, Eric W. Biederman wrote:
quoted
Andrew Vagin [off-list ref] writes:
quoted
On Wed, Jul 06, 2016 at 10:46:33AM -0500, Eric W. Biederman wrote:
quoted
"Serge E. Hallyn" [off-list ref] writes:
quoted
On Wed, Jul 06, 2016 at 10:41:48AM +0200, Michael Kerrisk (man
-pages) wrote:
quoted
[Rats! Doing now what I should have down to start with.
Looping some
lists and CRIU and other possibly relevant people into this
conversation]
Hi Eric,
On 5 July 2016 at 23:47, Eric W. Biederman <
ebiederm@xmission.com> wrote:
quoted
"Michael Kerrisk (man-pages)" [off-list ref]
writes:
quoted
Hi Eric,
I have a question. Is there any way currently to discover
which user namespace a particular nonuser namespace is
governed by? Maybe I am missing something, but there does
not seem to be a way to do this. Also, can one discover
which userns is the parent of a given userns? Again, I
can't see a way to do this.
The point here is introspecting so that a process might
determine what its capabilities are when operating on
some resource governed by a (nonuser) namespace.
To the best of my knowledge that there is not an interface
to get that information. It would be good to have such an
interface for no other reason than the CRIU folks are going
to need it at some point. I am a bit surprised they have
not complained yet.
I don't think they need it. They do in fact have what they
39 more quoted lines
I'm agree with this.
Once we actually have the information, we can also add a set of proc
links, say either
/proc/<pid>/ns/X-userns
Which might be a bit messy since it doubles the number of files, or
perhaps in a simple directory.
In this case we will need to enter into each namespace to build a full
chain of dependencies.
It's tricky, because if we enter into a child userns, we can't to enter
into a parent userns from the same process, so to get the next branch,
we will need to create a new process.
process A
|
init_user_ns->child_user_ns_1->child_userns_2
fork() -> B
B: setns(/proc/A/ns/userns-parent)
readlink(/proc/B/ns/userns)
fork() -> C
C: setns(/proc/B/ns/userns-parent)
readlink(/proc/C/ns/userns)
quoted
Well I suppose we could print an device number and inode number pair.
But then someone would still have to scour processes looking for a
user namespace so that is likely less than ideal.
There's no reason any of the proposed methods so far have to be
exclusive: nsfs.c has a lot of flexibility.
What do you think about the idea to mount nsfs and be able to look up
any alive namespace by inum:
$ tree .
.
├── mnt{inum}
│ └── user -> ../user{inum}
├── pid{inum}
│ ├── pid{inum}
│ │ └── user -> ../../user{inum}/user{inum}
│ └── user -> ../user{inum}
└── user{inum}
└── user{inum}
https://lkml.org/lkml/2016/7/8/59
I think it solves all requirements which were mentioned in this thread.
quoted
Starting with 4.8 we are also going to need to be able to retrieve
the user namespace owner of filesystems. That will be an interesting
mix.
This is per mount point, isn't it? so it can't be in /proc/fs/ and it
would have to be per local mount tree. Yes, that is a bit nasty.
Sounds like we might need to unfold mount or mountinfo into something
that has one directory per entry?
If we will be able to look up namespaces in nsfs by inum, we can print
an userns inum in mountinfo.
James
quoted
Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers