public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Vagin <avagin@virtuozzo.com>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	Linux API <linux-api@vger.kernel.org>,
	Containers <containers@lists.linux-foundation.org>,
	lkml <linux-kernel@vger.kernel.org>, <criu@openvz.org>,
	"Michael Kerrisk \(man-pages\)" <mtk.manpages@gmail.com>
Subject: Re: [CRIU] Introspecting userns relationships to other namespaces?
Date: Sat, 09 Jul 2016 13:29:20 -0500	[thread overview]
Message-ID: <871t32ll6n.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <87eg72llu0.fsf@x220.int.ebiederm.org> (Eric W. Biederman's message of "Sat, 09 Jul 2016 13:15:19 -0500")

ebiederm@xmission.com (Eric W. Biederman) writes:

> Andrew Vagin <avagin@virtuozzo.com> writes:
>
>> All these thoughts about security make me thinking that kcmp is what we
>> should use here. It's maybe something like this:
>>
>> kcmp(pid1, pid2, KCMP_NS_USERNS, fd1, fd2)
>>
>> - to check if userns of the fd1 namepsace is equal to the fd2 userns
>>
>> kcmp(pid1, pid2, KCMP_NS_PARENT, fd1, fd2)
>>
>> - to check if a parent namespace of the fd1 pidns is equal to fd pidns.
>>
>> fd1 and fd2 is file descriptors to namespace files.
>>
>> So if we want to build a hierarchy, we need to collect all namespaces
>> and then enumerate them to check dependencies with help of kcmp.
>
> That is certainly one way to go.
>
> There is a funny case where we would want to compare a user namespace
> file descriptor to a parent user namespace file descriptor.
>
>
> Grumble, Grumble.  I think this may actually a case for creating ioctls
> for these two cases.  Now that random nsfs file descriptors are bind
> mountable the original reason for using proc files is not as pressing.
>
> One ioctl for the user namespace that owns a file descriptor.
> One ioctl for the parent namespace of a namespace file descriptor.
>
> We also need some way to get a command file descriptor for a file system
> super block.  Al Viro has a pet project for cleaning up the mount API
> and this might be the idea excuse to start looking at that.
>
> (In principle we might be able to run commands through the namespace
>  file descriptor and using an ioctl feels dirty.  But an ioctl that
>  only uses the fd and request argument does not suffer from the same
>  problems that ioctls that have to pass additional arguments suffer
>  from.)

Of course it should be an error perhaps -EINVAL to get a user
namespace owner or parent namespace that is outside of a processes
current user namespace or pid namespace.  That way thing stay bounded
within the current namespaces the process is in.  Which prevents any
leak possibilities, and keeps CRIU working.

Eric

  reply	other threads:[~2016-07-09 18:41 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <c2a26220-69f2-f2f5-491a-e43abd9a6f92@gmail.com>
     [not found] ` <87r3b7pxja.fsf@x220.int.ebiederm.org>
2016-07-06  8:41   ` Introspecting userns relationships to other namespaces? Michael Kerrisk (man-pages)
2016-07-06 14:13     ` Serge E. Hallyn
2016-07-06 15:46       ` Eric W. Biederman
2016-07-08  1:57         ` [CRIU] " Andrew Vagin
2016-07-08  7:44           ` Eric W. Biederman
2016-07-08 14:35             ` James Bottomley
2016-07-08 20:38               ` Andrew Vagin
2016-07-08 20:50                 ` W. Trevor King
2016-07-08 22:19                 ` James Bottomley
2016-07-08 22:19                 ` James Bottomley
2016-07-08 23:52                   ` Eric W. Biederman
2016-07-09  0:15                     ` James Bottomley
2016-07-09  3:05                       ` Eric W. Biederman
2016-07-09  7:26                         ` Andrew Vagin
2016-07-09 10:31                           ` James Bottomley
2016-07-09 10:32                           ` James Bottomley
2016-07-09 18:15                           ` Eric W. Biederman
2016-07-09 18:29                             ` Eric W. Biederman [this message]
2016-07-13  0:08                               ` Andrew Vagin
2016-07-13  3:59                                 ` W. Trevor King
2016-07-07  8:15       ` Michael Kerrisk (man-pages)
2016-07-07 13:36         ` Serge E. Hallyn
2016-07-07 15:01           ` James Bottomley
2016-07-07 18:21             ` Michael Kerrisk (man-pages)
2016-07-07 18:24               ` Serge E. Hallyn
2016-07-07 19:17               ` James Bottomley
2016-07-08  2:16                 ` [CRIU] " Andrew Vagin
2016-07-08  3:00                   ` Andrew Vagin
2016-07-08  3:26                     ` James Bottomley
2016-07-08  5:26                       ` W. Trevor King
2016-07-08  6:16                         ` W. Trevor King
2016-07-08  6:54                         ` Andrew Vagin
2016-07-08  7:18                           ` W. Trevor King
2016-07-08  5:41                       ` [CRIU] " Andrei Vagin
2016-07-08  5:47                         ` Andrei Vagin
2016-07-08  6:07                         ` James Bottomley
2016-07-08 11:17                       ` Michael Kerrisk (man-pages)
2016-07-08  3:20                   ` James Bottomley
2016-07-08  6:09                     ` Andrew Vagin
2016-07-08 11:11                 ` Michael Kerrisk (man-pages)
2016-07-09  3:15             ` W. Trevor King
2016-07-09  3:13               ` Eric W. Biederman
2016-07-10  5:36                 ` [CRIU] " Andrew Vagin
2016-07-10 20:29                   ` Eric W. Biederman
2016-07-10 21:06                     ` James Bottomley
2016-07-11 20:55                       ` Andrew Vagin

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=871t32ll6n.fsf@x220.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=avagin@virtuozzo.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=criu@openvz.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox