Linux namespace

最新推荐文章于 2024-05-01 08:00:13 发布

懒猫gg

最新推荐文章于 2024-05-01 08:00:13 发布

阅读量1.5k

点赞数 1

分类专栏： # Linux 文章标签： linux namespace

本文链接：https://blog.csdn.net/y3over/article/details/128863060

版权

Linux 专栏收录该内容

8 篇文章 1 订阅

订阅专栏

前言

从《initrd&init进程》可知，我们通过ssh连接linux服务器，其实主是linux启动一shell进程与我们做交互。而Linux又是多租户的，这使用得用户与用户间产生了，资源的争抢。如何隔离资源，且让用户都无法察觉？

Linux Namespace 是什么

Namespace 是 Linux 内核中实现的特性，本质上是一种资源隔离方案.
其提供了一种抽象机制，将原本全局共享的资源隔离成不同的集合，集合中的成员独享其原本全局共享的资源。

举个例子：进程 A 和进程 B 分别属于两个不同的 Namespace，那么进程 A 将可以使用 Linux 内核提供的所有 Namespace 资源：如独立的主机名，独立的文件系统，独立的进程编号等等。同样地，进程 B 也可以使用同类资源，但其资源与进程 A 使用的资源相互隔离，彼此无法感知。

从用户的角度来看，每一个命名空间应该像一台单独的 Linux计算机一样，有自己的 init进程（PID为 I），其他进程的PID依次递增， A和B空间都有PID为l的init进程，子命名空间的进程映射到父命名空间的进程上，父命名空间可以知道每一个子命名空间的运行状态，而子命名空间与子命名空间之间是隔离的

当前 Linux一共实现了 7 种不同类型的 Namespace
在这里插入图片描述

User Namespace

User namespace 用于隔离安全相关的资源，包括 user IDs and group IDs(keys和 capabilities)。同样一个用户的 user ID 和 group ID 在不同的 user namespace 中可以不一样权限。换句话说，一个用户可以在一个 user namespace 中是普通用户，但在另一个 user namespace 中是超级用户。

打开两个终端

## 终端1

## 使用unshare命令进行 namespace
unshare --user /bin/bash

## 使用id命令查看
> id
uid=65534(nobody) gid=65534(nogroups) groups=65534(nogroup)

## 在新的 user namespace 中，当前用户变成了 nobody，并且 ID 也变成了 65534。
## 这是因为我们还没有映射父 user namespace 的 user ID 和 group ID 到子 user namespace 中来
## 如果没有映射，当在新的 user namespace 中用 getuid() 和 getgid() 获取 user ID 和 group ID 时，系统将返回文件 /proc/sys/kernel/overflowuid 中定义的 user ID 以及 proc/sys/kernel/overflowgid 中定义的 group ID，它们的默认值都是 65534。也就是说如果没有指定映射关系的话，会默认会把 ID 映射到 65534。

> cat /proc/sys/kernel/overflowuid
65534
> cat /proc/sys/kernel/overflowgid
65534

## 下面我们来完成 nick (外部用户)在新的 user namespace 中的映射。
## 映射ID的方法就是添加映射信息到 /proc/PID/uid_map 和 /proc/PID/gid_map (这里的 PID 是新 user namespace 中的进程 ID，刚开始时这两个文件都是空的)文件中。

## 查询当前namespace进程id 
> echo $$
16471

## 终端2

## 使用ll命令查询，uid_map，gid_map文件的归属
> ll /proc/16471/uid_map /proc/16471/gid_map

## 查看容器外用户ID
> id
uid=1000(nick) gid=1000(nick) groups=1000(nick)

## 对 uid_map 和 gid_map 文件的写入操作有着严格的权限控制，简单点说就是：这两个文件的拥有者是创建新的 user namespace 的用户
## 所以和这个用户在一个 user namespace 中的 root 账号可以写；这个用户自己是否有写 map 文件的权限还要看它有没有 CAP_SETUID 和 CAP_SETGID 的 capability（权限）

## 给nick 用户设置权限
> sudo setcap cap_setgid,cap_setuid+ep /bin/bash
> exec bash

## 查询权限
> getcap /bin/bash
/bin/bash = cap_setgid,cap_setuid+ep

## uid_map 和 gid_map 的配置信息的格式如下(每个文件中可以有多条配置信息)：
## ID-inside-ns（容器内用户ID） ID-outside-ns（容器外用户ID） length
## 比如 0 1000 500 这条配置就表示父 user namespace 中的 1000~1500 映射到新 user namespace 中的 0~500。、
## 容器内 0 为root 对应容器外 1000 （nike用户）

> echo '0 1000 500' > /proc/16471/uid_map
> echo '0 1000 500' > /proc/16471/gid_map

## 终端1

> exec bash
> id
uid=0(root) gid=0(root) groups=65534(nogroup)

## 查看root目录仍没有权限，比如这里 root 对应父 user namespace 的用户是 nick
> ll / grep root
dxwx---- 4 nobody nogroup 4096  root/

当然也可以使用“-r” 来将当前用户自动映射root

unshare --user -r /bin/bash

或者在使用其它namespace时，使用sudo命令，直接将root映射到root

sudo unshare -m

命令解释

$$ :Shell本身的PID（ProcessID），即当前进程的PID。
setcap 设置进程特权的Linux命令。它允许普通用户运行某些需要特权的服务，而无需以root身份运行整个服务
uid(用户ID)、gid(初始组ID), groups是用户所在组(这里既可以看到初始组，如果有附加组，则也能看到附加组)

User namespace 与其它 namespace 的关系
. Linux 下的每个 namespace，都有一个 user namespace 与之关联，这个 user namespace 就是创建相应 namespace 时进程所属的 user namespace，相当于每个 namespace 都有一个 owner(user namespace)，这样保证对任何 namespace 的操作都受到 user namespace 权限的控制。

NetWork Namespace

Network Namespace 是用来隔离网络设备、 IP地址端口等网络械的 Namespace。 Network Namespace 可以让每个容器拥有自己独立的(虚拟的)网络设备，而且容器内的应用可以绑定到自己的端口，每个 Namespace 内的端口都不会互相冲突。在宿主机上搭建网桥后，就能很方便地实现容器之间的通信，而且不同容器上的应用可以使用相同的端口。

同样的打开两个终端

## 终端1

## 查看ip
> ifconfig
ens33: 192.168.3.34
lo: 127.0.0.1

## 使用 root映射的身份进入，并net 隔离
> unshare --net --user -r /bin/bash

## 再次查询，发现为空，net 隔离成功
> ifconfig

## 查看进程
> echo $$
16894

## 终端2

## Linux上创建一对veth设备
> sudo ip link add veth0 type veth peer name veth1
> ip a | grep veth
3: veth1@veth0: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default qlen 1000
4: veth0@veth1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN group default qlen 100

## 为veth0设置IP地址并启动
> sudo ip a add dev veth0 192.168.10.10/24
> sudo ip link set veth0 up
> ifconfig
ens33: 192.168.3.34
lo: 127.0.0.1
veth0: 192.168.10.10

## 将veth1移动到刚才新建的network namespace 中
sudo ip link set veth1 netns 16894

## 终端1

## 在ns1中启动veth1并设置IP地址
> ip link set dev veth1 up
> ip a add dev veth1 192.168.10.20/24
> ifcofing
veth1: 192.168.10.20

## 使用ping测试连通
> ping 192.168.10.10
PING 192.168.10.10 (192.168.10.10) 56(84) bytes of data.
64 bytes from 192.168.10.10: icmp_seq=1 ttl=64 time=0.076 ms

现在ns1还不能和公网通信。解决这个问题也很简单，在root network namespace中开启转发并设置SNAT，在ns1中添加默认路由即可。

veth是一种Linux内核网络设备，它通常用于在不同的网络命名空间之间创建虚拟网络接口。veth可以分为成对出现的两个设备，一个位于主机上，另一个则与容器相关联。
在容器技术中，veth设备通常用于将主机上的网络连接和容器内部的网络连接隔离开来。
SNAT（Source Network Address Translation）是一种将源IP地址和端口从一个网络地址转换为另一个网络地址的技术

UTS Namespace

uts(UNIX Time-Sharing System) namespace可隔离hostname(主机名)和NIS Domain name（域名,例如cn,edu）资源，使得一个宿主机可拥有多个主机名或Domain Name。换句话说，可让不同namespace中的进程看到不同的主机名.

同样的打开两个终端

## 终端1

## 使用 root映射的身份进入，并uts 隔离
> unshare --uts --user -r /bin/bash

## 查看hostname
> hostname
ubuntu

## 修改hostname 并重新加载shell
> hostname ns1
> exec /bin/bash

> hostname
ns1

# namespace中修改的主机名不会直接修改主机名配置文件(如/etc/hostname)，而是修改内核属性/proc/sys/kernel/hostname：

> cat /etc/hostname
ubuntu
> cat /proc/sys/kernel/hostname
ns1

## 终端2

> cat /proc/sys/kernel/hostname
ubuntu

在这里插入图片描述

Mount Namespace

Mount namespace 为进程提供独立的文件系统视图。简单点说就是，mount namespace 用来隔离文件系统的挂载点，这样进程就只能看到自己的 mount namespace 中的文件系统挂载点。
进程的 mount namespace 中的挂载点信息可以在 /proc/[pid]/mounts、/proc/[pid]/mountinfo 和 /proc/[pid]/mountstats 这三个文件中找到。

同样的打开两个终端

## 终端1

## 制作 iso 文件
> mkdir demo 
> cd demo
> mkdir -p iso1/subdir1
> mkdir -p iso2/subdir2
> mkisofs -o 1.iso ./iso1
> mkisofs -o 2.iso ./iso2

## 准备2个挂载点
>sudo mkdir /mnt/iso1 /mnt/iso2

## 挂载
>sudo mount 1.iso /mnt/iso1

## 查看挂载情况
> mount | grep 1.iso
/home/sa/demo/1.iso on /mnt/iso1 type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8)

## 终端2

## 以root身分进入ns
> sudo unshare -m

## 查看挂载情况， 发现挂载情况一样
> mount | grep iso
/home/sa/demo/1.iso on /mnt/iso1 type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8)

## 挂载2，卸载1
> mount 2.iso /mnt/iso2
> umount /mnt/iso1

## 查看挂载情况， 发现变了
> mount | grep iso
/home/sa/demo/2.iso on /mnt/iso1 type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8)

## 终端1

## 与终端2不一样了
> mount | grep iso
/home/sa/demo/1.iso on /mnt/iso1 type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048,iocharset=utf8)

Mount namespace 实现了挂载点的隔离，但对于某些应用场景，会让我们用起来很不爽。比如系统新添加了一个磁盘设备，我们打算让所有的 mount namespace 都挂载它。过去的做法只能是在每个 mount namespace 中都挂载一遍，很显然，这太不方便了。于是在 Linux 内核 2.6.15 引入了 shared subtree 的概念来解决这个问题。Shared subtree 的核心是允许在 mount namespace 之间自动地或者是受控地传播 mount 和 umount 事件。

PID Namespace

PID namespace 用来隔离进程的 PID 空间，使得不同 PID namespace 里的进程 PID 可以重复且互不影响。PID namesapce 对容器类应用特别重要，可以实现容器内进程的暂停/恢复等功能，还可以支持容器在跨主机的迁移前后保持内部进程的 PID 不发生变化。

Linux下的每个进程都有一个对应的 /proc/PID 目录，该目录包含了大量的有关当前进程的信息。对一个 PID namespace 而言，/proc 目录只包含当前 namespace 和它所有子孙后代 namespace 里的进程的信息。创建一个新的 PID namespace 后，如果想让子进程中的 top、ps 等依赖 /proc 文件系统的命令工作，还需要挂载 /proc 文件系统。

## 终端1

## 进入ns, 有pid的一定要加--fork
> sudo unshare --pid --mount --fork 

## 查看进程ID
> echo $$
1

## 使用ps查看进程信息，依旧是原始pid编号，不是1
> ps
  PID TTY          TIME CMD
  2475 pts/1    00:00:00 sudo
  2476 pts/1    00:00:00 unshare
  2477 pts/1    00:00:00 bash
  2492 pts/1    00:00:00 ps

## 使用mount 挂载/proc,并查看
> mount -t proc proc /proc
> ps
    PID TTY          TIME CMD
     1 pts/1    00:00:00 bash
    12 pts/1    00:00:00 ps


## 其实 unshare 命令提供了一个专门的选项 --mount-proc 来配合 PID namespce 的创建
> sudo unshare --pid --mount-proc --fork

PID namespace 可以嵌套，也就是说有父子关系，除了系统初始化时创建的根 PID namespace 之外，其它的 PID namespace 都有一个父 PID namespace。一个 PID namespace 的父是指：通过 clone 或 unshare 方法创建 PID namespace 的进程所在的 PID namespace。

在当前 namespace 里面创建的所有新的 namespace 都是当前 namespace 的子 namespace。父 namespace 里面可以看到所有子孙后代 namespace 里的进程信息，而子 namespace 里看不到祖先或者兄弟 namespace 里的进程信息。一个进程在 PID namespace 的嵌套结构中的每一个可以被看到的层中都有一个 PID。

## 终端1

## 查看当前进程
> echo $$
2351

## 连续创建3个子进程
> sudo unshare --pid --mount-proc --fork
> sudo unshare --pid --mount-proc --fork
> sudo unshare --pid --mount-proc --fork


## 终端2

## 用pstree查看进程树
> pstree -p 2351
bash(2351)
───sudo(2727)───unshare(2728)───bash(2729)
───sudo(2737)───unshare(2738)───bash(2739)
───sudo(2749)───unshare(2750)───bash(2751)

## 通过 /proc/[pid]/status 看看 2751 号进程在不同 PID namespace 中的 PID
> grep pid /proc/2751/status
NSpid:	2751	21	11	1

## 作用enter命令进入
> sudo nsenter --mount --pid -t 2739 /bin/bash
> pstree -p
bash(1)
───sudo(9)───unshare(10)───bash(11)

PID namespace 中的 init 进程
在一个新的 PID namespace 中创建的第一个进程的 PID 为 1，该进程被称为这个 PID namespace 中的 init 进程。

在 Linux 系统中，进程的 PID 从 1 开始往后不断增加，并且不能重复（当然进程退出后，PID 会被回收再利用），进程的 PID 为 1 的进程是内核启动的第一个应用层进程，被称为 init 进程(不同的 init 系统的进程名称可能不太一样)。这个进程具有特殊意义，当 init 进程退出时，系统也将退出。所以除了在 init 进程里指定了 handler 的信号外，内核会帮 init 进程屏蔽掉其他任何信号，这样可以防止其他进程不小心 kill 掉 init 进程导致系统挂掉。
不过有了 PID namespace 后，可以通过在父 PID namespace 中发送 SIGKILL 或者 SIGSTOP 信号来终止子 PID namespace 中的 PID 为 1 的进程。由于 PID 为 1 的进程的特殊性，当这个进程停止后，内核将会给这个 PID namespace 里的所有其他进程发送 SIGKILL 信号，致使其他所有进程都停止，最终 PID namespace 被销毁掉。
当一个进程的父进程退出后，该进程就变成了孤儿进程。孤儿进程会被当前 PID namespace 中 PID 为 1 的进程接管，而不是被最外层的系统级别的 init 进程接管。