From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: "Michael Kerrisk (man-pages)"
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Serge Hallyn
<serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
Andrei Vagin <avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Containers
<containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
James Bottomley
<James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>,
Alexander Viro
<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
"linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Documenting the ioctl interfaces to discover relationships between namespaces
Date: Mon, 12 Dec 2016 11:30:38 +1300 [thread overview]
Message-ID: <87poky5ca9.fsf@xmission.com> (raw)
In-Reply-To: <CAKgNAkjJACGKJmYZ6v9v3UvPs7Kfri9HPO9QQGbW=NzVErPy8Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> (Michael Kerrisk's message of "Sun, 11 Dec 2016 12:54:56 +0100")
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
> [was: [PATCH 0/4 v3] Add an interface to discover relationships
> between namespaces]
One small comment below.
>
> Introspecting namespace relationships
> Since Linux 4.9, two ioctl(2) operations are provided to allow
> introspection of namespace relationships (see user_namespaces(7)
> and pid_namespaces(7)). The form of the calls is:
>
> ioctl(fd, request);
>
> In each case, fd refers to a /proc/[pid]/ns/* file.
>
> NS_GET_USERNS
> Returns a file descriptor that refers to the owning user
> namespace for the namespace referred to by fd.
>
> NS_GET_PARENT
> Returns a file descriptor that refers to the parent names‐
> pace of the namespace referred to by fd. This operation is
> valid only for hierarchical namespaces (i.e., PID and user
> namespaces). For user namespaces, NS_GET_PARENT is synony‐
> mous with NS_GET_USERNS.
>
> In each case, the returned file descriptor is opened with O_RDONLY
> and O_CLOEXEC (close-on-exec).
>
> By applying fstat(2) to the returned file descriptor, one obtains
> a stat structure whose st_ino (inode number) field identifies the
> owning/parent namespace. This inode number can be matched with
> the inode number of another /proc/[pid]/ns/{pid,user} file to
> determine whether that is the owning/parent namespace.
Like all fstat inode comparisons to be fully accurate you need to
compare both the st_ino and st_dev. I reserve the right for st_dev to
be significant when comparing namespaces. Otherwise I might have to
create a namespace of namespaces someday and that is ugly.
> Either of these ioctl(2) operations can fail with the following
> error:
>
> EPERM The requested namespace is outside of the caller's names‐
> pace scope. This error can occur if, for example, the own‐
> ing user namespace is an ancestor of the caller's current
> user namespace. It can also occur on attempts to obtain
> the parent of the initial user or PID namespace.
>
> Additionally, the NS_GET_PARENT operation can fail with the fol‐
> lowing error:
>
> EINVAL fd refers to a nonhierarchical namespace.
>
> See the EXAMPLE section for an example of the use of these opera‐
> tions.
>
> [...]
Eric
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>
Cc: Andrei Vagin <avagin@openvz.org>,
Containers <containers@lists.linux-foundation.org>,
Linux API <linux-api@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
"linux-fsdevel\@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
"W. Trevor King" <wking@tremily.us>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Serge Hallyn <serge.hallyn@canonical.com>
Subject: Re: Documenting the ioctl interfaces to discover relationships between namespaces
Date: Mon, 12 Dec 2016 11:30:38 +1300 [thread overview]
Message-ID: <87poky5ca9.fsf@xmission.com> (raw)
In-Reply-To: <CAKgNAkjJACGKJmYZ6v9v3UvPs7Kfri9HPO9QQGbW=NzVErPy8Q@mail.gmail.com> (Michael Kerrisk's message of "Sun, 11 Dec 2016 12:54:56 +0100")
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com> writes:
> [was: [PATCH 0/4 v3] Add an interface to discover relationships
> between namespaces]
One small comment below.
>
> Introspecting namespace relationships
> Since Linux 4.9, two ioctl(2) operations are provided to allow
> introspection of namespace relationships (see user_namespaces(7)
> and pid_namespaces(7)). The form of the calls is:
>
> ioctl(fd, request);
>
> In each case, fd refers to a /proc/[pid]/ns/* file.
>
> NS_GET_USERNS
> Returns a file descriptor that refers to the owning user
> namespace for the namespace referred to by fd.
>
> NS_GET_PARENT
> Returns a file descriptor that refers to the parent names‐
> pace of the namespace referred to by fd. This operation is
> valid only for hierarchical namespaces (i.e., PID and user
> namespaces). For user namespaces, NS_GET_PARENT is synony‐
> mous with NS_GET_USERNS.
>
> In each case, the returned file descriptor is opened with O_RDONLY
> and O_CLOEXEC (close-on-exec).
>
> By applying fstat(2) to the returned file descriptor, one obtains
> a stat structure whose st_ino (inode number) field identifies the
> owning/parent namespace. This inode number can be matched with
> the inode number of another /proc/[pid]/ns/{pid,user} file to
> determine whether that is the owning/parent namespace.
Like all fstat inode comparisons to be fully accurate you need to
compare both the st_ino and st_dev. I reserve the right for st_dev to
be significant when comparing namespaces. Otherwise I might have to
create a namespace of namespaces someday and that is ugly.
> Either of these ioctl(2) operations can fail with the following
> error:
>
> EPERM The requested namespace is outside of the caller's names‐
> pace scope. This error can occur if, for example, the own‐
> ing user namespace is an ancestor of the caller's current
> user namespace. It can also occur on attempts to obtain
> the parent of the initial user or PID namespace.
>
> Additionally, the NS_GET_PARENT operation can fail with the fol‐
> lowing error:
>
> EINVAL fd refers to a nonhierarchical namespace.
>
> See the EXAMPLE section for an example of the use of these opera‐
> tions.
>
> [...]
Eric
next prev parent reply other threads:[~2016-12-11 22:30 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-11 11:54 Documenting the ioctl interfaces to discover relationships between namespaces Michael Kerrisk (man-pages)
2016-12-11 11:54 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkjJACGKJmYZ6v9v3UvPs7Kfri9HPO9QQGbW=NzVErPy8Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-12-11 22:30 ` Eric W. Biederman [this message]
2016-12-11 22:30 ` Eric W. Biederman
[not found] ` <87poky5ca9.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2016-12-12 6:13 ` Michael Kerrisk (man-pages)
2016-12-12 6:13 ` Michael Kerrisk (man-pages)
2016-12-12 16:01 ` Michael Kerrisk (man-pages)
2016-12-12 16:01 ` Michael Kerrisk (man-pages)
[not found] ` <6771af94-9847-0277-ec1d-62bc3649a17a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-12-12 18:18 ` Eric W. Biederman
2016-12-12 18:18 ` Eric W. Biederman
[not found] ` <87r35df1u4.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2016-12-14 7:32 ` Michael Kerrisk (man-pages)
2016-12-14 7:32 ` Michael Kerrisk (man-pages)
2016-12-15 0:46 ` Andrei Vagin
2016-12-15 0:46 ` Andrei Vagin
[not found] ` <20161215004636.GB31670-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2016-12-15 9:53 ` Michael Kerrisk (man-pages)
2016-12-15 9:53 ` Michael Kerrisk (man-pages)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87poky5ca9.fsf@xmission.com \
--to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
--cc=James.Bottomley-JuX6DAaQMKPCXq6kfMZ53/egYHeGw8Jk@public.gmane.org \
--cc=avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.