Debian 12 + LXD/LXC security.idmap.isolated schlägt fehl

Debian 12 + LXD/LXC security.idmap.isolated schlägt fehl

Unter Debian 12.1 (6.1.0-11-amd64) mit LXD/LXC und einer nicht privilegierten Containereinstellung security.idmap.isolated=truescheint die Aktualisierung des Besitzers/der Gruppe der Containerdateien fehlzuschlagen.

Hier ist ein Beispiel:

# 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

Wenn ich jetzt die Dateien auf dem Container-Volume aufliste, erhalte ich die Meldung, dass sie alle dem Host- rootBenutzer gehören:

# 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

Ich habe mehrere Versionen von LXD/LXC ausprobiert. Dies passiert sowohl mit 5.0.2 aptals auch mit 4.0 und 5.17 (aktuellste) von snap.

Interessanterweise habe ich ein weiteres Debian 10 (4.19.0-25-amd64) und ein älteres LXD 4 am Laufen und snapdarauf funktioniert alles wie erwartet:

# 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

Wie Sie auf diesem System sehen können, sind alle Dateien Eigentum von 1065536:1065536.


Aktualisieren:

Ich habe versucht, die Karten auf beiden Maschinen zu untersuchen lxc config show debianund habe Folgendes gesehen:

Maschine mit 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}]'

Maschine mit 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: '[]'

Aktualisieren:

Ich habe auch versucht, eine Neuinstallation vonDebian 11 (5.10.0-25-amd64) und es funktioniert wie erwartet:

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

Warum wurde es nicht ausgefüllt volatile.last_state.idmap: '[]'? Da es sowohl mit Debian 10 als auch mit 11 funktioniert, kann dies anscheinend mit dem neuen Kernel und/oder seiner Konfiguration zusammenhängen.

Wie kann ich das Problem beheben? Danke.

Antwort1

Dies ist offenbar ein von Grund auf neu entwickeltes Feature neuerer Kernel. Hier ist eine gute Erklärung von Stéphane Graber, dem Betreuer von LXC:

Bevor VFS idmap verfügbar war, mussten wir die Dateieigentümerschaft umgehen, indem wir LXD den Besitzer jeder einzelnen Datei auf der Festplatte manuell neu schreiben ließen. Das ist, was Sie hier auf einem älteren Kernel zeigen.

Bei neueren Kerneln ist dies nicht mehr erforderlich, da der Kernel die Berechtigungen auf der Festplatte unverändert lassen und nur im Kernel verschieben kann, sodass die Eigentumsverhältnisse innerhalb des Containers korrekt aussehen.

Was Sie oben zeigen, sieht wie ein perfekt funktionierendes Setup auf einem Kernel aus, der VFS-IDmap unterstützt.

Ich könnte dies tatsächlich auf dem Hostcomputer konfigurieren:

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

Und innerhalb von Containern wird der Stammeinhängepunkt auch wie folgt angezeigt idmapped(letzte Zeile):

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

Um dies zu deaktivieren, können Sie:

Es gibt eine Umgebungsvariable, die an LXD übergeben werden kann, indem in seiner Systemd-Einheit eine Überschreibung hinzugefügt wird. LXD_IDMAPPED_MOUNTS_DISABLE=1

Das sollten wir jedoch nicht tun, meint Herr Graber:

Okay, Ihr System läuft also momentan völlig normal und mit dem geringstmöglichen Overhead, Sie müssen sich also keine Sorgen machen.

Die alte Methode zum Verschieben vor dem Start war sehr langsam und sehr riskant, da ein Absturz oder ein Fehler beim Verschieben eines bestimmten Metadatenteils (ACL, xattr, …) ein Sicherheitsproblem mit dem Container verursachen konnte. Es war auch schrecklich für CoW-Dateisysteme, da es effektiv so aussah, als wäre jede einzelne Datei im Container geändert worden, was möglicherweise zu einer Duplizierung von GBs an Daten führte.

shiftfs (ein Ubuntu-spezifischer Hack) und jetzt die richtige VFS-IDmap-Verschiebung. Lassen Sie den Kernel einfach das umgekehrte UIDmap/GIDmap auf jeden Dateisystemvorgang auf eine als IDmapped markierte Einbindung anwenden. Dies ist ein äußerst trivial durchzuführender Vorgang, der dynamische Änderungen an den Containerzuordnungen ermöglicht (sehr nützlich für isolierte), das Teilen von Daten zwischen Containern ermöglicht und alles, was eine UID/GID enthalten kann (ioctl, xattr, acl, …), ordnungsgemäß unterstützt. Dadurch wird das Risiko eliminiert, etwas übersehen zu haben.

verwandte Informationen