[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1fwwzdqam.fsf@fess.ebiederm.org>
Date: Fri, 24 Sep 2010 10:06:41 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Daniel Lezcano <daniel.lezcano@...e.fr>
Cc: Andrew Lutomirski <luto@....edu>,
Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
Pavel Emelyanov <xemul@...nvz.org>,
Pavel Emelyanov <xemul@...allels.com>,
Ulrich Drepper <drepper@...il.com>, netdev@...r.kernel.org,
Jonathan Corbet <corbet@....net>, linux-kernel@...r.kernel.org,
Jan Engelhardt <jengelh@...ozas.de>,
linux-fsdevel@...r.kernel.org, netfilter-devel@...r.kernel.org,
Michael Kerrisk <mtk.manpages@...il.com>,
Linux Containers <containers@...ts.osdl.org>,
Ben Greear <greearb@...delatech.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
David Miller <davem@...emloft.net>,
Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [ABI REVIEW][PATCH 0/8] Namespace file descriptors
Daniel Lezcano <daniel.lezcano@...e.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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists