linux-kernel - Re: Documenting the ioctl interfaces to discover relationships between namespaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 14 Dec 2016 08:32:45 +0100
From:   "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     mtk.manpages@...il.com, Andrei Vagin <avagin@...nvz.org>,
        Containers <containers@...ts.linux-foundation.org>,
        Linux API <linux-api@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        "W. Trevor King" <wking@...mily.us>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        "Serge E. Hallyn" <serge@...lyn.com>
Subject: Re: Documenting the ioctl interfaces to discover relationships
 between namespaces

On 12/12/2016 07:18 PM, Eric W. Biederman wrote:
> "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com> writes:
> 
>> On 12/11/2016 11:30 PM, Eric W. Biederman wrote:
>>> "Michael Kerrisk (man-pages)" <mtk.manpages@...il.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.
>>
>> So, after playing with this a bit, I have a question. 
>>
>> I gather that in order to, for example, elaborate the tree of user
>> namespaces on the system, one would use NS_GET_PARENT on each of
>> the /proc/*/ns/user files and match up the results. Right?
>> 	   
>> What happens if one of the parent user namespaces contains no
>> processes? That is, the parent namespace exists by virtue of being
>> pinned because a proc/PID/ns/user file is open or bind mounted.
>> (Chrome seems to do this sort of dance with user namespaces, for
>> example.) How do we find the ancestor of *that* user namespace?
> 
> What is returned from NS_GET_USERNS and NS_GET_PARENT is a file
> descriptor, that you can call NS_GET_PARENT on.

Thanks, Eric. While trying to solve the small task I set myself,
and probably confused by past discussions[1], I was overlooking
the obvious.

Cheers,

Michael

[1] https://lkml.org/lkml/2016/7/28/365

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/