Quoting Michael Kerrisk (man-pages) (mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org):

Hi Eric,

On 07/25/2016 03:18 PM, Eric W. Biederman wrote:

quoted

"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:

NS_GET_USERNS
     Returns a file descriptor that refers to an owning  user  names‐
     pace.

NS_GET_PARENT
     Returns  a  file  descriptor  that refers to a parent namespace.
     This ioctl(2) can be used for pid and user namespaces. For  user
     namespaces,  NS_GET_PARENT and NS_GET_USERNS have the same mean‐
     ing.

For each of the above, I think it is worth mentioning that the
close-on-exec flag is set for the returned file descriptor.

Hmm.  That is an odd default.

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

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.

Thanks - that had caught my eye but I hadn't had time to look into the
justification for this.  Hiding this kind of thing indeed seems wrong to
me, unless there is a really good justification for it, i.e. a way
to use that info in an exploit.