linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Daniel Lezcano <daniel.lezcano@free.fr>
Cc: Andrew Lutomirski <luto@mit.edu>,
	Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>,
	Pavel Emelyanov <xemul@openvz.org>,
	Pavel Emelyanov <xemul@parallels.com>,
	Ulrich Drepper <drepper@gmail.com>,
	netdev@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
	linux-kernel@vger.kernel.org, Jan Engelhardt <jengelh@medozas.de>,
	linux-fsdevel@vger.kernel.org, netfilter-devel@vger.kernel.org,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Linux Containers <containers@lists.osdl.org>,
	Ben Greear <greearb@candelatech.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	David Miller <davem@davemloft.net>,
	Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [ABI REVIEW][PATCH 0/8] Namespace file descriptors
Date: Fri, 24 Sep 2010 10:06:41 -0700	[thread overview]
Message-ID: <m1fwwzdqam.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <4C9CAC7C.2080900@free.fr> (Daniel Lezcano's message of "Fri, 24 Sep 2010 15:49:48 +0200")

Daniel Lezcano <daniel.lezcano@free.fr> writes:

> On 09/24/2010 03:02 PM, Andrew Lutomirski wrote:
>> Eric W. Biederman wrote:
>>> Introduce file for manipulating namespaces and related syscalls.
>>> files:
>>> /proc/self/ns/<nstype>
>>>
>>> syscalls:
>>> int setns(unsigned long nstype, int fd);
>>> socketat(int nsfd, int family, int type, int protocol);
>>>
>>
>> How does security work?  Are there different kinds of fd that give (say) pin-the-namespace permission, socketat permission, and setns permission?
>
> AFAICS, socketat, setns and "set netns by fd" only accept fd from
> /proc/<pid>/ns/<ns>.
>
> setns does :
>
> 	file = proc_ns_fget(fd);
> 	if (IS_ERR(file))
> 		return PTR_ERR(file);
>
> proc_ns_fget checks if (file->f_op != &ns_file_operations)
>
>
> socketat and get_net_ns_by_fd:
>
> 	net = get_net_ns_by_fd(fd);
>
> this one calls proc_ns_fget.
>
> We have the guarantee here, the fd is resulting from an open of the file with
> the right permissions.

In particular the default /proc permissions say you have to be the owner
of the process (or root) to access the file.  If you are the owner of
the process with a namespace (or root) you already have permission to
access and manipulate the namespace.

Additionally setns like unshare requires CAP_SYS_ADMIN (aka root magic).

> Another way to pin the namespace, would be to mount --bind /proc/<pid>/ns/<ns>
> but we have to be root to do that ...

Simply keeping the process running, pins the namespace. That requires no
new permissions.

Similarly socketat.  It is possible to use unix domain sockets to
implement it today without any kernel changes.  It is just an
unnecessary pain to run a server process to pin a namespace or to serve
up file descriptors in other network namespaces.

The primary change of this patchset is the ability to do everything
with file descriptors, and with the mount namespace.  That moves
everything from a bizarre hard to understand and manipulate interface
to one where things can be done much more easily, and cheaply.
Resulting in a much more powerful and usable interface.

Eric


      reply	other threads:[~2010-09-24 17:07 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-23  8:45 [ABI REVIEW][PATCH 0/8] Namespace file descriptors Eric W. Biederman
2010-09-23  8:46 ` [PATCH 1/8] ns: proc files for namespace naming policy Eric W. Biederman
2010-09-23  8:46 ` [PATCH 2/8] ns: Introduce the setns syscall Eric W. Biederman
2010-09-23  8:47 ` [PATCH 3/8] ns proc: Add support for the network namespace Eric W. Biederman
2010-09-23 11:27   ` Louis Rilling
2010-09-23 16:00     ` Eric W. Biederman
2010-09-23  8:48 ` [PATCH 4/8] ns proc: Add support for the uts namespace Eric W. Biederman
2010-09-23  8:49 ` [PATCH 5/8] ns proc: Add support for the ipc namespace Eric W. Biederman
2010-09-23  8:50 ` [PATCH 6/8] ns proc: Add support for the mount namespace Eric W. Biederman
2010-09-23  8:51 ` [PATCH 7/8] net: Allow setting the network namespace by fd Eric W. Biederman
2010-09-23  9:41   ` Eric Dumazet
2010-09-23 16:03     ` Eric W. Biederman
2010-09-23 11:22   ` jamal
2010-09-23 14:58     ` David Lamparter
2010-09-24 11:51       ` jamal
2010-09-24 12:57         ` David Lamparter
2010-09-24 13:32           ` jamal
2010-09-24 14:09             ` David Lamparter
2010-09-24 14:16               ` jamal
2010-09-23 15:14     ` Eric W. Biederman
2010-09-23 14:22   ` Brian Haley
2010-09-23 16:16     ` Eric W. Biederman
2010-09-24 13:46   ` Daniel Lezcano
2010-09-23  8:51 ` [PATCH 8/8] net: Implement socketat Eric W. Biederman
2010-09-23  8:56   ` Pavel Emelyanov
2010-09-23 11:19     ` jamal
2010-09-23 11:33       ` Pavel Emelyanov
2010-09-23 11:40         ` jamal
2010-09-23 11:53           ` Pavel Emelyanov
2010-09-23 12:11             ` jamal
2010-09-23 12:34               ` Pavel Emelyanov
2010-09-23 14:54                 ` David Lamparter
2010-09-23 15:00                 ` Eric W. Biederman
2010-10-02 21:13             ` Daniel Lezcano
2010-10-03 13:44               ` jamal
2010-10-04 10:13                 ` Daniel Lezcano
2010-10-04 19:07                 ` Eric W. Biederman
2010-10-15 12:30                 ` netns patches WAS( " jamal
2010-10-26 20:52                   ` jamal
2010-10-27  0:27                     ` Eric W. Biederman
2010-09-23 15:18 ` [ABI REVIEW][PATCH 0/8] Namespace file descriptors David Lamparter
2010-09-23 16:32   ` Eric W. Biederman
2010-09-23 16:49     ` David Lamparter
2010-09-24 13:02 ` Andrew Lutomirski
2010-09-24 13:49   ` Daniel Lezcano
2010-09-24 17:06     ` Eric W. Biederman [this message]

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=m1fwwzdqam.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=containers@lists.osdl.org \
    --cc=corbet@lwn.net \
    --cc=daniel.lezcano@free.fr \
    --cc=davem@davemloft.net \
    --cc=drepper@gmail.com \
    --cc=greearb@candelatech.com \
    --cc=jengelh@medozas.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=mtk.manpages@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=sukadev@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    --cc=xemul@openvz.org \
    --cc=xemul@parallels.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;
as well as URLs for NNTP newsgroup(s).