Hi Eric,
On 07/25/2016 03:18 PM, Eric W. Biederman wrote:
"Michael Kerrisk (man-pages)" [off-list ref] writes:
quoted
Hi Andrey,
On 07/22/2016 08:25 PM, Andrey Vagin wrote:
quoted
On Thu, Jul 21, 2016 at 11:48 PM, Michael Kerrisk (man-pages)
[off-list ref] wrote:
quoted
Hi Andrey,
On 07/21/2016 11:06 PM, Andrew Vagin wrote:
quoted
On Thu, Jul 21, 2016 at 04:41:12PM +0200, Michael Kerrisk (man-pages)
wrote:
quoted
Hi Andrey,
On 07/14/2016 08:20 PM, Andrey Vagin wrote:
<snip>
quoted
Could you add here an of the API in detail: what do these FDs refer to,
and how do you use them to solve the use case? And could you you add
that info to the commit messages please.
Hi Michael,
A patch for man-pages is attached. It adds the following text to
namespaces(7).
Since Linux 4.X, the following ioctl(2) calls are supported for names‐
pace file descriptors. The correct syntax is:
fd = ioctl(ns_fd, ioctl_type);
where ioctl_type is one of the following:
14 more quoted lines
Why do you say that? It's pretty common as the default for various
APIs that create new FDs these days. (There's of course a strong argument
that the original UNIX default was a design blunder...)
quoted
quoted
quoted
quoted
In addition to generic ioctl(2) errors, the following specific ones can
occur:
EINVAL NS_GET_PARENT was called for a nonhierarchical namespace.
EPERM The requested namespace is outside of the current namespace
scope.
Perhaps add "and the caller does not have CAP_SYS_ADMIN" in the initial
user namespace"?
Having looked at that bit of code I don't think capabilities really
have a role to play.
Yes, I caught up with that now. I await to see how this plays out
in the next patch version.
quoted
quoted
quoted
quoted
ENOENT ns_fd refers to the init namespace.
Thanks for this. But still part of the question remains unanswered.
How do we (in user-space) use the file descriptors to answer any of
the questions that this patch series was designed to solve? (This
info should be in the commit message and the man-pages patch.)
I'm sorry, but I am not sure that I understand what you ask.
Here are the origin questions:
Someone else then asked me a question that led me to wonder about
generally introspecting on the parental relationships between user
namespaces and the association of other namespaces types with user
namespaces. One use would be visualization, in order to understand the
running system. Another would be to answer the question I already
mentioned: what capability does process X have to perform operations
on a resource governed by namespace Y?
Here is an example which shows how we can get the owning namespace
inode number by using these ioctl-s.
$ ls -l /proc/13929/ns/pid
lrwxrwxrwx 1 root root 0 Jul 22 21:03 /proc/13929/ns/pid -> 'pid:[4026532228]'
$ ./nsowner /proc/13929/ns/pid
user:[4026532227]
The owning user namespace for pid:[4026532228] is user:[4026532227].
The nsowner tool is cimpiled from this code:
int main(int argc, char *argv[])
{
char buf[128], path[] = "/proc/self/fd/0123456789";
int ns, uns, ret;
ns = open(argv[1], O_RDONLY);
if (ns < 0)
return 1;
26 more quoted lines
As in fstat() to get the st_ino field, right?
Cheers,
Michael
At some point we will care about migrating a migrating sub-container and we
may have to have some minor changes.
Eric
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers