☰

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

tag-icon • tag-icon containers lxc lxd
Debian 12 + LXD/LXC security.idmap.isolated 失敗

運行 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 4 則按snap預期工作：

# 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 的工作一樣，顯然這可能與新核心和/或其配置有關。

我該如何修復它？謝謝。

答案1

顯然這是新核心設計的特性。以下是 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，...），因此消除錯過某些事情的風險。

相關內容