---------------------------------
from http://oldwiki.linux-vserver.org/Namespaces //开源不只是代码，还有思想
Namespaces
You may have heard that alpha util-vserver use so called namespaces and wonder what namespaces are and more important, what they are good for.
This document should give you some insights (hopefully ;)).
What are namespaces?
Namespaces are a feature of the linux kernel that allow different processes to have a different view on the filesystem.
Normally there is just a single filesystem tree with different mounts here and there. Now with namespaces you can have different mounts/views for different processes.
What does this mean?
This means that if process A and process B are in different namespaces, (un-)mounting in one namespace does not affect the other namespace. When you mount something it only appears in the current namespace and if you unmount something it only disappears in the current namespace.
A namespace is automagically destroyed once all processes using that namespace have died. All mounts are automagically unmounted in that namesapce, so you don't have to take care that some dead mounts hang around somewhere you can't access them and keep you from, for example, removing a media from your cdrom drive (of course you have to take care that all processes die ;)).
How does alpha util-vserver use them?
Using the default settings alpha util-vserver creates a new namespace for each vserver. There are at least two reasons for doing this:
1. Cosmetic
The cosmetic reason is that your host's namespace isn't cluttered with all those mounts inside the vservers, i.e. /proc/mounts only contains the list of mounts in the current namespace.
2. Security
Security is added since alpha util-vserver also overlay the original root directory with the vserver's root directory (using a recursive bind mount), that way chroot break-outs fail since you end up being in the root directory which is now the vserver's root directory anyway ;) (you can also secure your vservers against chroot break-outs if you don't use namespaces, see chroot-barrier).
Drawbacks?
Yes, there are some drawbacks if you use namespaces for your vservers, but only minor ones.
Since namespaces are isolated from each other, you cannot directly add a mount to a vserver using "mount". Instead you have to switch to the vserver's namespace first. Fortunately alpha util-vserver comes with a tool that allows you to switch to a vserver's namespace easily.
# get a bash in the namespace of vserver "myvserver": vnamespace -e myvserver bash # same in context 123 vnamespace -e 123 bash # mount something in the namespace of vserver "myvserver": vnamespace -e myvserver mount /dev/somenode /path/to/mount/point # unmount something in the namespace of context 123 vnamespace -e 123 umount /path/to/mount/point # display all mounts in the namespace of 'myvserver' vnamespace -e myvserver cat /proc/mounts
Recent versions of alpha util-vserver automatically translate a vserver-name to a context id, while older tools still require the use of the correct context id. Remember that if you do bind mounts, the source of the bind mount has to be already available in the vserver's namespace.
Using the new configuration scheme you can also configure mounts for a vserver to be automatically setup while starting the vserver, see [The Great Flower Page] for details.
-----------------------------------------------------------------------
Linux Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的，而是属于特定的Namespace。每个Namespace里面的资源对其他Namespace都是透明的。要创建新的Namespace，只需要在调用clone时指定相应的flag。Linux Namespaces机制为实现基于容器的虚拟化技术提供了很好的基础，LXC（Linux containers）就是利用这一特性实现了资源的隔离。不同container内的进程属于不同的Namespace，彼此透明，互不干扰。下面我们就从clone系统调用的flag出发，来介绍各个Namespace。
当调用clone时，设定了CLONE_NEWPID，就会创建一个新的PID Namespace，clone出来的新进程将成为Namespace里的第一个进程。一个PID Namespace为进程提供了一个独立的PID环境，PID Namespace内的PID将从1开始，在Namespace内调用fork，vfork或clone都将产生一个在该Namespace内独立的PID。新创建的Namespace里的第一个进程在该Namespace内的PID将为1，就像一个独立的系统里的init进程一样。该Namespace内的孤儿进程都将以该进程为父进程，当该进程被结束时，该Namespace内所有的进程都会被结束。PID Namespace是层次性，新创建的Namespace将会是创建该Namespace的进程属于的Namespace的子Namespace。子Namespace中的进程对于父Namespace是可见的，一个进程将拥有不止一个PID，而是在所在的Namespace以及所有直系祖先Namespace中都将有一个PID。系统启动时，内核将创建一个默认的PID Namespace，该Namespace是所有以后创建的Namespace的祖先，因此系统所有的进程在该Namespace都是可见的。
当调用clone时，设定了CLONE_NEWIPC，就会创建一个新的IPC Namespace，clone出来的进程将成为Namespace里的第一个进程。一个IPC Namespace有一组System V IPC objects 标识符构成，这标识符有IPC相关的系统调用创建。在一个IPC Namespace里面创建的IPC object对该Namespace内的所有进程可见，但是对其他Namespace不可见，这样就使得不同Namespace之间的进程不能直接通信，就像是在不同的系统里一样。当一个IPC Namespace被销毁，该Namespace内的所有IPC object会被内核自动销毁。
PID Namespace和IPC Namespace可以组合起来一起使用，只需在调用clone时，同时指定CLONE_NEWPID和CLONE_NEWIPC，这样新创建的Namespace既是一个独立的PID空间又是一个独立的IPC空间。不同Namespace的进程彼此不可见，也不能互相通信，这样就实现了进程间的隔离。
当调用clone时，设定了CLONE_NEWNS，就会创建一个新的mount Namespace。每个进程都存在于一个mount Namespace里面，mount Namespace为进程提供了一个文件层次视图。如果不设定这个flag，子进程和父进程将共享一个mount Namespace，其后子进程调用mount或umount将会影响到所有该Namespace内的进程。如果子进程在一个独立的mount Namespace里面，就可以调用mount或umount建立一份新的文件层次视图。该flag配合pivot_root系统调用，可以为进程创建一个独立的目录空间。
当调用clone时，设定了CLONE_NEWNET，就会创建一个新的Network Namespace。一个Network Namespace为进程提供了一个完全独立的网络协议栈的视图。包括网络设备接口，IPv4和IPv6协议栈，IP路由表，防火墙规则，sockets等等。一个Network Namespace提供了一份独立的网络环境，就跟一个独立的系统一样。一个物理设备只能存在于一个Network Namespace中，可以从一个Namespace移动另一个Namespace中。虚拟网络设备(virtual network device)提供了一种类似管道的抽象，可以在不同的Namespace之间建立隧道。利用虚拟化网络设备，可以建立到其他Namespace中的物理设备的桥接。当一个Network Namespace被销毁时，物理设备会被自动移回init Network Namespace，即系统最开始的Namespace。
当调用clone时，设定了CLONE_NEWUTS，就会创建一个新的UTS Namespace。一个UTS Namespace就是一组被uname返回的标识符。新的UTS Namespace中的标识符通过复制调用进程所属的Namespace的标识符来初始化。Clone出来的进程可以通过相关系统调用改变这些标识符，比如调用sethostname来改变该Namespace的hostname。这一改变对该Namespace内的所有进程可见。CLONE_NEWUTS和CLONE_NEWNET一起使用，可以虚拟出一个有独立主机名和网络空间的环境，就跟网络上一台独立的主机一样。
以上所有clone flag都可以一起使用，为进程提供了一个独立的运行环境。LXC正是通过在clone时设定这些flag，为进程创建一个有独立PID，IPC，FS，Network，UTS空间的container。一个container就是一个虚拟的运行环境，对container里的进程是透明的，它会以为自己是直接在一个系统上运行的。
一个container就像传统虚拟化技术里面的一台安装了OS的虚拟机，但是开销更小，部署更为便捷。
Linux Namespaces机制本身就是为了实现container based virtualizaiton开发的。它提供了一套轻量级、高效率的系统资源隔离方案，远比传统的虚拟化技术开销小，不过它也不是完美的，它为内核的开发带来了更多的复杂性，它在隔离性和容错性上跟传统的虚拟化技术比也还有差距
————————————————————————————————————————————————————————
实现
由于Linux内核提供了PID，IPC，NS等多个Namespace，一个进程可能属于多个Namespace。为了task_struct的精简，内核引入了struct nsproxy来统一管理进程所属的Namespace，在task_struct中只需存一个指向struct nsproxy的指针就行了。struct nsproxy定义如下：
struct nsproxy {
atomic_t count;
struct uts_namespace *uts_ns;
struct ipc_namespace *ipc_ns;
struct mnt_namespace *mnt_ns;
struct pid_namespace *pid_ns;
struct net *net_ns;
};
从定义可以看出，nsproxy存储了一组指向各个类型Namespace的指针，为进程访问各个Namespace起了一个代理的作用。由于可能有多个进程所在的Namespace完全一样，nsproxy可以在进程间共享，count字段负责记录该结构的引用数。
系统预定义了一个init_nsproxy，用作默认的nsproxy。
struct nsproxy init_nsproxy = {
.count = ATOMIC_INIT(1),
.uts_ns = &init_uts_ns,
#if defined(CONFIG_POSIX_MQUEUE) || defined(CONFIG_SYSVIPC)
.ipc_ns = &init_ipc_ns,
#endif
.mnt_ns = NULL,
.pid_ns = &init_pid_ns,
#ifdef CONFIG_NET
.net_ns = &init_net,
#endif
};
其中除了mnt_ns外均指向系统默认的Namespace。
内核定义了一组函数来管理nsproxy：
task_nsproxy用于从task_struct指针在RCU保护下获得其中的nsproxy指针。
put_nsproxy用于减少一个nsproxy的引用数。
get_nsproxy用于增加一个nsproxy的引用数。
create_nsproxy用于分配一个新的nsproxy结构。
下面我们来看系统在clone时的处理。系统调用clone是通过sys_clone实现的，而sys_clone又是通过内核函数do_fork实现的，而do_fork大部分工作又是在copy_process中做的。在copy_process中，有这样的代码：
if ((retval = copy_namespaces(clone_flags, p)))
goto bad_fork_cleanup_mm;
这里我们回过头去看copy_namespaces的代码
int copy_namespaces(unsigned long flags, struct task_struct *tsk)
{
struct nsproxy *old_ns = tsk->nsproxy;
struct nsproxy *new_ns;
int err = 0;
if (!old_ns)
return 0;
get_nsproxy(old_ns);
if (!(flags & (CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWIPC |
CLONE_NEWPID | CLONE_NEWNET)))
return 0;
if (!capable(CAP_SYS_ADMIN)) {
err = -EPERM;
goto out;
}
/*
* CLONE_NEWIPC must detach from the undolist: after switching
* to a new ipc namespace, the semaphore arrays from the old
* namespace are unreachable. In clone parlance, CLONE_SYSVSEM
* means share undolist with parent, so we must forbid using
* it along with CLONE_NEWIPC.
*/
if ((flags & CLONE_NEWIPC) && (flags & CLONE_SYSVSEM)) {
err = -EINVAL;
goto out;
}
new_ns = create_new_namespaces(flags, tsk, tsk->fs);
if (IS_ERR(new_ns)) {
err = PTR_ERR(new_ns);
goto out;
}
tsk->nsproxy = new_ns;
out:
put_nsproxy(old_ns);
return err;
}
该函数首先检查flags，如果没有指定任何一个需要新建Namespace的flag，直接返回0。否则，做相应的权能检查，然后调用create_new_namespaces为进程创建新的Namespace。
我们再来看create_new_namespaces的代码
static struct nsproxy *create_new_namespaces(unsigned long flags,
struct task_struct *tsk, struct fs_struct *new_fs)
{
struct nsproxy *new_nsp;
int err;
new_nsp = create_nsproxy();
if (!new_nsp)
return ERR_PTR(-ENOMEM);
new_nsp->mnt_ns = copy_mnt_ns(flags, tsk->nsproxy->mnt_ns, new_fs);
if (IS_ERR(new_nsp->mnt_ns)) {
err = PTR_ERR(new_nsp->mnt_ns);
goto out_ns;
}
new_nsp->uts_ns = copy_utsname(flags, tsk->nsproxy->uts_ns);
if (IS_ERR(new_nsp->uts_ns)) {
err = PTR_ERR(new_nsp->uts_ns);
goto out_uts;
}
new_nsp->ipc_ns = copy_ipcs(flags, tsk->nsproxy->ipc_ns);
if (IS_ERR(new_nsp->ipc_ns)) {
err = PTR_ERR(new_nsp->ipc_ns);
goto out_ipc;
}
new_nsp->pid_ns = copy_pid_ns(flags, task_active_pid_ns(tsk));
if (IS_ERR(new_nsp->pid_ns)) {
err = PTR_ERR(new_nsp->pid_ns);
goto out_pid;
}
new_nsp->net_ns = copy_net_ns(flags, tsk->nsproxy->net_ns);
if (IS_ERR(new_nsp->net_ns)) {
err = PTR_ERR(new_nsp->net_ns);
goto out_net;
}
return new_nsp;
out_net:
if (new_nsp->pid_ns)
put_pid_ns(new_nsp->pid_ns);
out_pid:
if (new_nsp->ipc_ns)
put_ipc_ns(new_nsp->ipc_ns);
out_ipc:
if (new_nsp->uts_ns)
put_uts_ns(new_nsp->uts_ns);
out_uts:
if (new_nsp->mnt_ns)
put_mnt_ns(new_nsp->mnt_ns);
out_ns:
kmem_cache_free(nsproxy_cachep, new_nsp);
return ERR_PTR(err);
}
该函数首先为进程分配一个新的nsproxy（因为有新的Namespace创建），然后调用各个Namespace相关的函数来为进程一一创建新的Namespace（如果flags指定了的话）。具体的各个Namespace相关的创建函数比较复杂，与各自实现相关，就不在这里分析了。
我们再回到copy_process中，有以下代码：
if (pid != &init_struct_pid) {
retval = -ENOMEM;
pid = alloc_pid(p->nsproxy->pid_ns);
if (!pid)
goto bad_fork_cleanup_io;
if (clone_flags & CLONE_NEWPID) {
retval = pid_ns_prepare_proc(p->nsproxy->pid_ns);
if (retval < 0)
goto bad_fork_free_pid;
}
}
由于从do_fork中调用copy_process时，pid参数是NULL，所以这里肯定满足第一个if条件。在if内，首先为进程在其所在的Namespace分配pid，然后判断clone时是否set了CLONE_NEWPID，如果设定了就做进一步的处理。这两个函数都是pid Namespace相关的代码，这里就不去分析了。
然后有以下代码：
if (current->nsproxy != p->nsproxy) {
retval = ns_cgroup_clone(p, pid);
if (retval)
goto bad_fork_free_pid;
}
由于我们分析的是设定了clone相关flags的情况，那这个if条件肯定满足。在if里面，调用了ns_cgroup_clone，即为不同nsproxy新建了一个cgroup。这里就和之前关于cgroups ns子系统的分析关联起来了，内核这里实际上是利用cgroups ns子系统对进程做了一个自动分类，相同nsproxy（即所有Namespace都相同的进程）的进程在一个cgroup，一旦通过clone创建新的Namespace，就会在当前cgroup下创建一个新的cgroup。这样以来，通过cgroup文件系统，在挂载ns 子系统的目录下，我们就可以清楚地看出Namespace的层次关系。
大家看到这里是不是会有疑问，使用clone相应flags创建新的Namespace是不是必须要cgroups ns子系统的支持？作者可以负责任地告诉你：不需要。
在nsproxy.h中有以下代码：
#ifdef CONFIG_CGROUP_NS
int ns_cgroup_clone(struct task_struct *tsk, struct pid *pid);
#else
static inline int ns_cgroup_clone(struct task_struct *tsk, struct pid *pid)
{
return 0;
}
#endif
即在没有cgroups的情况下，ns_cgroup_clone实现是不同的。