主页 / server / 问题 / 1143118
Accepted
TCB13
Asked: 2023-09-05 23:15:50 +0800 CST

Debian 12 + LXD/LXC security.idmap.isolated 失败

  • 772

运行 LXD/LXC 并在非特权容器设置上的 Debian 12.1 (6.1.0-11-amd64)security.idmap.isolated=true似乎无法更新容器文件的所有者/组。

这是一个例子：

# lxc launch images:debian/12 debian
(...)

# lxc config get debian volatile.idmap.base
296608

# lxc stop debian
Error: The instance is already stopped

# lxc config set debian security.idmap.isolated true

# lxc config get debian security.idmap.isolated
true

# lxc start debian

现在，如果我列出容器卷上的文件，我会发现它们全部归主机root 用户所有：

# ls -la /mnt/NVME1/lxd/containers/debian/rootfs/
total 24
drwxr-xr-x 1 root   root  154 Sep  5 06:28 .
d--x------ 1 296608 root   78 Sep  5 15:59 ..
lrwxrwxrwx 1 root   root    7 Sep  5 06:25 bin -> usr/bin
drwxr-xr-x 1 root   root    0 Jul 14 17:00 boot
drwxr-xr-x 1 root   root    0 Sep  5 06:28 dev
drwxr-xr-x 1 root   root 1570 Sep  5 06:28 etc

我尝试了 LXD/LXC 的多个版本。5.0.2apt以及 4.0 和 5.17（最新）都会发生这种情况snap。

有趣的是，我有另一个 Debian 10 (4.19.0-25-amd64) 正在运行，而较旧的 LXD 4snap则按预期工作：

# ls -la /mnt/NVME1/lxd/containers/debian/rootfs/
total 0
drwxr-xr-x 1 1065536 1065536  138 Oct 29  2020 .
d--x------ 1 1065536 root      78 Oct 14  2020 ..
drwxr-xr-x 1 1065536 1065536 1328 Jul 24 19:07 bin
drwxr-xr-x 1 1065536 1065536    0 Sep 19  2020 boot
drwxr-xr-x 1 1065536 1065536    0 Oct 14  2020 dev
drwxr-xr-x 1 1065536 1065536 1716 Jul 24 19:08 etc

正如您在该系统上看到的，所有文件都属于1065536:1065536.

更新：

我尝试在两台机器中探测地图lxc config show debian，我看到了这一点：

运行 Debian 10 的机器：

security.idmap.isolated: "true"
(...)
volatile.idmap.base: "1065536"
volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":1065536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1065536,"Nsid":0,"Maprange":65536}]'
volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":1065536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1065536,"Nsid":0,"Maprange":65536}]'
volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":1065536,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":1065536,"Nsid":0,"Maprange":65536}]'

运行 Debian 12 的机器：

security.idmap.isolated: "true"
(...)
volatile.idmap.base: "231072"
volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":231072,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":231072,"Nsid":0,"Maprange":65536}]'
volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":231072,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":231072,"Nsid":0,"Maprange":65536}]'
volatile.last_state.idmap: '[]'

更新：

我还尝试了全新安装Debian 11 (5.10.0-25-amd64)，它按预期工作：

root@vm-debian-11-cli:~# ls -la /mnt/NVME1/lxd/containers/debian/rootfs/
total 24
drwxr-xr-x 1 1065536 1065536  154 Sep  6 06:28 .
d--x------ 1 1065536 root      78 Sep  6 15:31 ..
lrwxrwxrwx 1 1065536 1065536    7 Sep  6 06:25 bin -> usr/bin
drwxr-xr-x 1 1065536 1065536    0 Jul 14 17:00 boot
drwxr-xr-x 1 1065536 1065536    0 Sep  6 06:28 dev
drwxr-xr-x 1 1065536 1065536 1570 Sep  6 06:28 etc

为什么没有填充volatile.last_state.idmap: '[]'？与 Debian 10 和 11 的工作一样，显然这可能与新内核和/或其配置有关。

我该如何修复它？谢谢。

containers

1 个回答

  1. Best Answer

    显然这是新内核设计的一个特性。以下是 LXC 维护者 Stéphane Graber 的精彩解释：

    在 VFS idmap 可用之前，我们需要通过让 LXD 手动重写磁盘上每个文件的所有者来解决文件所有权问题。这就是您在旧内核上显示的内容。

    在较新的内核上，不再需要这样做，因为我们可以让内核保持磁盘上的权限不变，而只是在内核中移动，以便所有权在容器内部看起来是正确的。

    上面显示的内容看起来像是在支持 VFS idmap 的内核上完美运行的设置。

    我确实可以在主机上配置它：

    root@vm-debian-12-cli:~# lxc info | grep 'shift\|idmap'
- storage_shifted
    idmapped_mounts: "true"
    shiftfs: "false"
    idmapped_mounts_v2: "true"

    在容器内部，根挂载点也显示为idmapped（最后一行）：

    root@debian:~# cat /proc/self/uid_map
         0     231072      65536

root@debian:~# cat /proc/self/gid_map
         0     231072      65536

root@debian:~# cat /proc/self/mountinfo
490 460 0:24 /@rootfs/mnt/NVME1/lxd/containers/debian/rootfs / rw,relatime,idmapped shared:251 master:1 - btrfs /dev/sda1 rw,space_cache=v2,user_subvol_rm_allowed,subvolid=259,subvol=/@rootfs/mnt/NVME1/lxd/containers/debian

    要禁用此功能可能：

    有一个环境变量可以通过在其 systemd 单元中添加覆盖来传递给 LXD。LXD_IDMAPPED_MOUNTS_DISABLE=1

    然而，根据 Graber 先生的说法，我们不应该这样做：

    好的，所以您的系统现在运行得非常正常，并且开销可能最低，无需担心。

    旧的预启动转移方法非常缓慢且风险很大，因为转移特定元数据位（ACL、xattr 等）的崩溃或失败可能会导致容器出现安全问题。这对于 CoW 文件系统来说也是可怕的，因为它实际上让容器中的每个文件看起来都被修改了，可能会复制 GB 的数据。

    shiftfs（这是 Ubuntu 特定的 hack）和现在正确的 VFS idmap 移位，只需让内核将任何文件系统操作上的反向 uidmap/gidmap 应用到标记为 idmapped 的安装上。这是一个非常简单的操作，允许动态更改容器映射（对于隔离非常有用），允许在容器之间共享数据并正确支持可以保存 uid/gid 的所有内容（ioctl、xattr、acl，...），因此消除错过某些事情的风险。

    • 0

相关问题