Please pull the namespace file descriptor git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/linux-2.6-nsfd.git
Because other syscall work has happened in other trees there
are conflicts on alpha and m68k.
For alpha all that is needed is a simple incrementing of the syscall
number in my tree and adding of my syscall to the end of the list.
For m68k please just delete all of the syscall entries the conflict will
add to arch/m68k/kernel/entry_mm.S. The m68k tree has consolidated
everything in arch/m68k/kernel/syscalltable.S
This tree adds the files /proc/<pid>/ns/net, /proc/<pid>/ns/ipc,
/proc/<pid>/ns/uts that can be opened to refer to the namespaces of a
process at the time those files are opened, and can be bind mounted to
keep the specified namespace alive without a process.
This tree adds the setns system call that can be used to change the
specified namespace of a process to the namespace specified by a system
call.
This tree adds a new rtnetlink attribute that allows for moving a
network device into a network namespace specified by a file descriptor.
Support for the other namespaces is planned but is not ready for 2.6.40.
These changes dramatically simplify what a userspace process has to do
to keep a namespace alive, and to execute system calls in it.
The shortlog:
Stephen Rothwell (1):
net: fix get_net_ns_by_fd for !CONFIG_NET_NS
Eric W. Biederman (11):
ns: proc files for namespace naming policy.
ns: Introduce the setns syscall
ns proc: Add support for the network namespace.
ns proc: Add support for the uts namespace
ns proc: Add support for the ipc namespace
net: Allow setting the network namespace by fd
Merge commit '2e7bad5f34b5beed47542490c760ed26574e38ba' into HEAD
Merge commit '7143b7d41218d4fc2ea33e6056c73609527ae687' into HEAD
ns: Wire up the setns system call
ns: Declare sys_setns in syscalls.h
ns proc: Return -ENOENT for a nonexistent /proc/self/ns/ entry.
The diffstat:
arch/alpha/include/asm/unistd.h | 3 +-
arch/alpha/kernel/systbls.S | 1 +
arch/arm/include/asm/unistd.h | 1 +
arch/arm/kernel/calls.S | 1 +
arch/avr32/include/asm/unistd.h | 3 +-
arch/avr32/kernel/syscall_table.S | 1 +
arch/blackfin/include/asm/unistd.h | 3 +-
arch/blackfin/mach-common/entry.S | 1 +
arch/cris/arch-v10/kernel/entry.S | 1 +
arch/cris/arch-v32/kernel/entry.S | 1 +
arch/cris/include/asm/unistd.h | 3 +-
arch/frv/include/asm/unistd.h | 3 +-
arch/frv/kernel/entry.S | 1 +
arch/h8300/include/asm/unistd.h | 3 +-
arch/h8300/kernel/syscalls.S | 1 +
arch/ia64/include/asm/unistd.h | 3 +-
arch/ia64/kernel/entry.S | 1 +
arch/m32r/include/asm/unistd.h | 3 +-
arch/m32r/kernel/syscall_table.S | 1 +
arch/m68k/include/asm/unistd.h | 3 +-
arch/m68k/kernel/syscalltable.S | 1 +
arch/microblaze/include/asm/unistd.h | 3 +-
arch/microblaze/kernel/syscall_table.S | 1 +
arch/mips/include/asm/unistd.h | 15 ++-
arch/mips/kernel/scall32-o32.S | 1 +
arch/mips/kernel/scall64-64.S | 1 +
arch/mips/kernel/scall64-n32.S | 1 +
arch/mips/kernel/scall64-o32.S | 1 +
arch/mn10300/include/asm/unistd.h | 3 +-
arch/mn10300/kernel/entry.S | 1 +
arch/parisc/include/asm/unistd.h | 4 +-
arch/parisc/kernel/syscall_table.S | 1 +
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.h | 3 +-
arch/s390/include/asm/unistd.h | 3 +-
arch/s390/kernel/syscalls.S | 1 +
arch/sh/include/asm/unistd_32.h | 3 +-
arch/sh/include/asm/unistd_64.h | 3 +-
arch/sh/kernel/syscalls_32.S | 1 +
arch/sh/kernel/syscalls_64.S | 1 +
arch/sparc/include/asm/unistd.h | 3 +-
arch/sparc/kernel/systbls_32.S | 2 +-
arch/sparc/kernel/systbls_64.S | 4 +-
arch/x86/ia32/ia32entry.S | 1 +
arch/x86/include/asm/unistd_32.h | 3 +-
arch/x86/include/asm/unistd_64.h | 2 +
arch/x86/kernel/syscall_table_32.S | 1 +
arch/xtensa/include/asm/unistd.h | 4 +-
fs/proc/Makefile | 1 +
fs/proc/base.c | 20 ++--
fs/proc/inode.c | 7 +
fs/proc/internal.h | 18 +++
fs/proc/namespaces.c | 198 ++++++++++++++++++++++++++++++++
include/asm-generic/unistd.h | 4 +-
include/linux/if_link.h | 1 +
include/linux/proc_fs.h | 21 ++++
include/linux/syscalls.h | 1 +
include/net/net_namespace.h | 1 +
ipc/namespace.c | 37 ++++++
kernel/nsproxy.c | 42 +++++++
kernel/utsname.c | 39 ++++++
net/core/net_namespace.c | 65 +++++++++++
net/core/rtnetlink.c | 5 +-
63 files changed, 525 insertions(+), 42 deletions(-)
Thanks,
Eric
On Mon, May 23, 2011 at 4:05 PM, Eric W. Biederman
<[email protected]> wrote:
>
> This tree adds the files /proc/<pid>/ns/net, /proc/<pid>/ns/ipc,
> /proc/<pid>/ns/uts that can be opened to refer to the namespaces of a
> process at the time those files are opened, and can be bind mounted to
> keep the specified namespace alive without a process.
>
> This tree adds the setns system call that can be used to change the
> specified namespace of a process to the namespace specified by a system
> call.
i just have a quick question regarding these, apologies if wrong place
to respond -- i trimmed to lists only.
if i understand correctly, mount namespaces (for example), allow one
to build such constructs as "private /tmp" and similar that even
`root` cannot access ... and there are many reasons `root` does not
deserve to completely know/interact with user processes (FUSE makes a
good example ... just because i [user] have SSH access to a machine,
why should `root`?)
would these /proc additions break such guarantees? IOW, would it now
become possible for `root` to inject stuff into my private namespaces,
and/or has these guarantees never existed and i am mistaken? is there
any kind of ACL mechanism that endows the origin process (or similar)
with the ability to dictate who can hold and/or interact with these
references?
Thanks for your time,
--
C Anthony
Quoting C Anthony Risinger ([email protected]):
> On Mon, May 23, 2011 at 4:05 PM, Eric W. Biederman
> <[email protected]> wrote:
> >
> > This tree adds the files /proc/<pid>/ns/net, /proc/<pid>/ns/ipc,
> > /proc/<pid>/ns/uts that can be opened to refer to the namespaces of a
> > process at the time those files are opened, and can be bind mounted to
> > keep the specified namespace alive without a process.
> >
> > This tree adds the setns system call that can be used to change the
> > specified namespace of a process to the namespace specified by a system
> > call.
>
> i just have a quick question regarding these, apologies if wrong place
> to respond -- i trimmed to lists only.
>
> if i understand correctly, mount namespaces (for example), allow one
> to build such constructs as "private /tmp" and similar that even
> `root` cannot access ... and there are many reasons `root` does not
> deserve to completely know/interact with user processes (FUSE makes a
> good example ... just because i [user] have SSH access to a machine,
> why should `root`?)
>
> would these /proc additions break such guarantees? IOW, would it now
> become possible for `root` to inject stuff into my private namespaces,
> and/or has these guarantees never existed and i am mistaken? is there
> any kind of ACL mechanism that endows the origin process (or similar)
> with the ability to dictate who can hold and/or interact with these
> references?
If for instance you have a file open in your private /tmp, then root
in another mounts ns can open the file through /proc/$$/fd/N anyway.
If it's a directory, he can now traverse the whole fs.
-serge
On Wed, May 25, 2011 at 4:38 PM, Serge E. Hallyn <[email protected]> wrote:
> Quoting C Anthony Risinger ([email protected]):
>> On Mon, May 23, 2011 at 4:05 PM, Eric W. Biederman
>> <[email protected]> wrote:
>> >
>> > This tree adds the files /proc/<pid>/ns/net, /proc/<pid>/ns/ipc,
>> > /proc/<pid>/ns/uts that can be opened to refer to the namespaces of a
>> > process at the time those files are opened, and can be bind mounted to
>> > keep the specified namespace alive without a process.
>> >
>> > This tree adds the setns system call that can be used to change the
>> > specified namespace of a process to the namespace specified by a system
>> > call.
>>
>> i just have a quick question regarding these, apologies if wrong place
>> to respond -- i trimmed to lists only.
>>
>> if i understand correctly, mount namespaces (for example), allow one
>> to build such constructs as "private /tmp" and similar that even
>> `root` cannot access ... and there are many reasons `root` does not
>> deserve to completely know/interact with user processes (FUSE makes a
>> good example ... just because i [user] have SSH access to a machine,
>> why should `root`?)
>>
>> would these /proc additions break such guarantees? IOW, would it now
>> become possible for `root` to inject stuff into my private namespaces,
>> and/or has these guarantees never existed and i am mistaken? is there
>> any kind of ACL mechanism that endows the origin process (or similar)
>> with the ability to dictate who can hold and/or interact with these
>> references?
>
> If for instance you have a file open in your private /tmp, then root
> in another mounts ns can open the file through /proc/$$/fd/N anyway.
> If it's a directory, he can now traverse the whole fs.
aaah right :-( ... there's always another way isn't there ... curse
you Linux for being so flexible! (just kidding baby i love you)
this seems like a more fundamental issue then? or should i not expect
to be able to achieve separation like this? i ask in the context of
OS virt via cgroups + namespaces, eg. LXC et al, because i'm about to
perform a massive overhaul to our crusty sub-2.6.18 infrastructure and
i've used/followed these technologies for couple years now ... and
it's starting to feel like "the right time".
C Anthony
2011/5/25 C Anthony Risinger <[email protected]>:
> On Wed, May 25, 2011 at 4:38 PM, Serge E. Hallyn <[email protected]> wrote:
>> Quoting C Anthony Risinger ([email protected]):
[...]
>>> if i understand correctly, mount namespaces (for example), allow one
>>> to build such constructs as "private /tmp" and similar that even
>>> `root` cannot access ... and there are many reasons `root` does not
>>> deserve to completely know/interact with user processes (FUSE makes a
>>> good example ... just because i [user] have SSH access to a machine,
>>> why should `root`?)
>> If for instance you have a file open in your private /tmp, then root
>> in another mounts ns can open the file through /proc/$$/fd/N anyway.
>> If it's a directory, he can now traverse the whole fs.
> aaah right :-( ... there's always another way isn't there ... curse
> you Linux for being so flexible! (just kidding baby i love you)
>
> this seems like a more fundamental issue then? or should i not expect
> to be able to achieve separation like this? i ask in the context of
> OS virt via cgroups + namespaces, eg. LXC et al, because i'm about to
> perform a massive overhaul to our crusty sub-2.6.18 infrastructure and
> i've used/followed these technologies for couple years now ... and
> it's starting to feel like "the right time".
You either trust the admin or don't use the machine. There is no third way.
Best Regards,
Michał Mirosław
C Anthony Risinger <[email protected]> writes:
> On Wed, May 25, 2011 at 4:38 PM, Serge E. Hallyn <[email protected]> wrote:
>> Quoting C Anthony Risinger ([email protected]):
>>> On Mon, May 23, 2011 at 4:05 PM, Eric W. Biederman
>>> <[email protected]> wrote:
>>> >
>>> > This tree adds the files /proc/<pid>/ns/net, /proc/<pid>/ns/ipc,
>>> > /proc/<pid>/ns/uts that can be opened to refer to the namespaces of a
>>> > process at the time those files are opened, and can be bind mounted to
>>> > keep the specified namespace alive without a process.
>>> >
>>> > This tree adds the setns system call that can be used to change the
>>> > specified namespace of a process to the namespace specified by a system
>>> > call.
>>>
>>> i just have a quick question regarding these, apologies if wrong place
>>> to respond -- i trimmed to lists only.
>>>
>>> if i understand correctly, mount namespaces (for example), allow one
>>> to build such constructs as "private /tmp" and similar that even
>>> `root` cannot access ... and there are many reasons `root` does not
>>> deserve to completely know/interact with user processes (FUSE makes a
>>> good example ... just because i [user] have SSH access to a machine,
>>> why should `root`?)
>>>
>>> would these /proc additions break such guarantees? IOW, would it now
>>> become possible for `root` to inject stuff into my private namespaces,
>>> and/or has these guarantees never existed and i am mistaken? is there
>>> any kind of ACL mechanism that endows the origin process (or similar)
>>> with the ability to dictate who can hold and/or interact with these
>>> references?
>>
>> If for instance you have a file open in your private /tmp, then root
>> in another mounts ns can open the file through /proc/$$/fd/N anyway.
>> If it's a directory, he can now traverse the whole fs.
>
> aaah right :-( ... there's always another way isn't there ... curse
> you Linux for being so flexible! (just kidding baby i love you)
Even more significant the access to the new files is guarded by the
ptrace access checks. And if root can ptrace your process root
can remote control your process.
> this seems like a more fundamental issue then? or should i not expect
> to be able to achieve separation like this? i ask in the context of
> OS virt via cgroups + namespaces, eg. LXC et al, because i'm about to
> perform a massive overhaul to our crusty sub-2.6.18 infrastructure and
> i've used/followed these technologies for couple years now ... and
> it's starting to feel like "the right time".
I don't think anything really new is allowed, but we haven't designed
anything that radically reduces the power of root either.
At some point we may have the user namespace done and that should
give you a root like user with vastly reduced powers, but we aren't
there yet.
Eric
On Wed, May 25, 2011 at 6:40 PM, Eric W. Biederman
<[email protected]> wrote:
> C Anthony Risinger <[email protected]> writes:
>
>> On Wed, May 25, 2011 at 4:38 PM, Serge E. Hallyn <[email protected]> wrote:
>>> Quoting C Anthony Risinger ([email protected]):
>>>> On Mon, May 23, 2011 at 4:05 PM, Eric W. Biederman
>>>> <[email protected]> wrote:
>>>> >
>>>> > This tree adds the files /proc/<pid>/ns/net, /proc/<pid>/ns/ipc,
>>>> > /proc/<pid>/ns/uts that can be opened to refer to the namespaces of a
>>>> > process at the time those files are opened, and can be bind mounted to
>>>> > keep the specified namespace alive without a process.
>>>> >
>>>> > This tree adds the setns system call that can be used to change the
>>>> > specified namespace of a process to the namespace specified by a system
>>>> > call.
>>>>
>>>> i just have a quick question regarding these, apologies if wrong place
>>>> to respond -- i trimmed to lists only.
>>>>
>>>> if i understand correctly, mount namespaces (for example), allow one
>>>> to build such constructs as "private /tmp" and similar that even
>>>> `root` cannot access ... and there are many reasons `root` does not
>>>> deserve to completely know/interact with user processes (FUSE makes a
>>>> good example ... just because i [user] have SSH access to a machine,
>>>> why should `root`?)
>>>>
>>>> would these /proc additions break such guarantees? IOW, would it now
>>>> become possible for `root` to inject stuff into my private namespaces,
>>>> and/or has these guarantees never existed and i am mistaken? is there
>>>> any kind of ACL mechanism that endows the origin process (or similar)
>>>> with the ability to dictate who can hold and/or interact with these
>>>> references?
>>>
>>> If for instance you have a file open in your private /tmp, then root
>>> in another mounts ns can open the file through /proc/$$/fd/N anyway.
>>> If it's a directory, he can now traverse the whole fs.
>>
>> aaah right :-( ... there's always another way isn't there ... curse
>> you Linux for being so flexible! (just kidding baby i love you)
>
> Even more significant the access to the new files is guarded by the
> ptrace access checks. And if root can ptrace your process root
> can remote control your process.
>
>> this seems like a more fundamental issue then? or should i not expect
>> to be able to achieve separation like this? i ask in the context of
>> OS virt via cgroups + namespaces, eg. LXC et al, because i'm about to
>> perform a massive overhaul to our crusty sub-2.6.18 infrastructure and
>> i've used/followed these technologies for couple years now ... and
>> it's starting to feel like "the right time".
>
> I don't think anything really new is allowed, but we haven't designed
> anything that radically reduces the power of root either.
>
> At some point we may have the user namespace done and that should
> give you a root like user with vastly reduced powers, but we aren't
> there yet.
ok -- i knew there was some user namespace work still left for a
namespaced root -- i was specifically thinking of the root user in the
host. i was under the impression that namespaces could achieve
separation even from the host (save the kernel itself) ... but it
seems i was mistaken ... still much to learn about Linux i suppose,
even though i use it everyday for years and years :-) it kind of
makes sense i guess, since maybe the host needs supervisory powers
over the guests? could be some merit for real separation in the
future (not only malevolent root host user, but say an attacker/script
that manages to break thru container?), though how possible i dont
know. i wouldnt expect the root user to be prevented from killing/etc
the container, but maybe only prevented from snooping, eg. the
container looks like a black box that he may only resource control or
kill completely. either way, what we have is just fine for my (and
likely many other's) uses.
anyways, thanks for all the answers and all the work on
namespacing/cgroups ... very useful constructs for a wide array of
problems.
--
C Anthony