Hinzufügen von LXC-id mapping reversiert das Eigentümerschaft aller Benutzerdateien innerhalb des Containers

poisonborz

New Member
May 8, 2020
15
1
3
51
Wie viele andere habe ich einige Bind-Mounts, die ich zwischen mehreren LXC-Containern teilen würde. Wie viele andere auch, bin ich über das Problem der kollidierenden UIDs gestolpert. Ich versuche, ein Mapping einzurichten, aber so viel ich auch lese, ich scheine ein großes Missverständnis zu haben. Immer wenn ich ein Mapping hinzufüge, wird jeder Ordner, der dem gemappten Benutzer gehört (z. B. das Home-Verzeichnis), plötzlich Eigentum von 65534/"nobody". Wie ist das möglich? Ich dachte, Maps wirken sich nur auf den Host/außerhalb des Containers aus? (als in Dateien in Bind-Mounts)

Ich versuche, Mapping wie folgt zu verwenden (generiert von einem Python-Tool)

Code:
lxc.idmap: u 0 100000 999 
lxc.idmap: g 0 100000 999 
lxc.idmap: u 999 999 1 
lxc.idmap: g 999 999 1 
lxc.idmap: u 1000 101000 4000 
lxc.idmap: g 1000 101000 4000 
lxc.idmap: u 5000 5000 1 
lxc.idmap: g 5000 5000 1 
lxc.idmap: u 5001 105001 60536 
lxc.idmap: g 5001 105001 60536


Und alternativ dies, wie in vielen Wikis gesehen

Code:
lxc.idmap = u 0 100000 999 
lxc.idmap = g 0 100000 999 
lxc.idmap = u 999 5000 1 
lxc.idmap = g 999 5000 1 
lxc.idmap = u 5000 101000 64536 
lxc.idmap = g 5000 101000 64536

Beide mit dem gleichen Effekt.

Im host /etc/sub{u,g}id:

Code:
root:100000:65536 
root:999:1 root:5000:1


Wäre es alternativ machbar/empfehlenswert, eine ACL für die freigegebenen Ordner innerhalb jedes Containers zu setzen und die Masken auf rw-rw-rw zu setzen? Auf diese Weise wären die unterschiedlichen Owner-IDs irrelevant.
 

Dunuin

Active Member
Jun 30, 2020
986
179
43
Wenn du das mit dem Mapping richtig machst, dann hast du eigentlich kein "nobody" mehr. Guck mal hier im Wiki.
Da wird der User 1005 auf dem Host zum User 1005 im Gast gemappt. Egal ob du im Gast oder auf dem Host guckst, der Ordner gehört immer dem User mit UID 1005. Sollte natürlich sowohl auf dem Gast als auch auf dem Host ein User mit der UID 1005 vorher existieren, dann wird da auch der entsprechende Name vom User angezeigt.
 

poisonborz

New Member
May 8, 2020
15
1
3
51
Aber.... wut... Kann man nicht zb user 999 (Gast) zu user 5000 (Host) mappen? Muss das immer gespiegelt sein? Wie ist das nutzbar wenn ich verschieden Gäste habe mit verschiedene users, die auf selber Mount points zugreifen?
 

Dunuin

Active Member
Jun 30, 2020
986
179
43
Aber.... wut... Kann man nicht zb user 999 (Gast) zu user 5000 (Host) mappen?
Kann man. Musst du aber die Konfigs entsprechend anpassen.
Muss das immer gespiegelt sein?
Nein.
Wie ist das nutzbar wenn ich verschieden Gäste habe mit verschiedene users, die auf selber Mount points zugreifen?
Dann wird es eher schwierig. Willst du mehreren Usern Rechte zu einem Ordner gewähren, dann musst du das ja über Gruppen machen. Gruppen lassen sich genau wie User mappen. Kompliziert wird es eher, weil deine Gruppen auf Host und Gast ja unterschiedlich sind. Nur weil ein User im Gast Mitglied einer Gruppe ist, heißt das ja nicht, dass er auf der Gruppe auf dem Host noch ist.

Am einfachsten fährst du wohl noch, wenn du in allen Gästen immer die gleiche UID für den User nutzt, der da Zugriff auf den bind-mount braucht.

Was mir bei deinen Beispielen auffällt ist, dass du da nichts zwischen 1000 und 5000 mappst. Du sagst 0-998 soll zu 100000-100998 gemappt werden. Dann 999 zu 5000. Und dann 5001-65565 zu 105001-165565. Alles von 1000 bis 4999 lässt du einfach weg. Eigentlich müsstest du dann ja noch 1000-4999 zu 101000-104999 und 5000 zu 999 mappen.
Außerdem versuchst du im Beispiel User 999 vom Host zu User 5000 im Gast zu mappen und nicht "999 (Gast) zu user 5000 (Host)" wie du oben schreibst.
 
Last edited:

poisonborz

New Member
May 8, 2020
15
1
3
51
Ich wollte gerade diese Gruppenidee schreiben.
Problem ist, ich verwende mehrere Services (Syncthing, Nextcloud usw.), die alle verschiedene Benutzer verwenden.
Die bessere Idee ist also, dass ich jede solche benutzer (eins pro container) auf uid/gid 5000 ändere.
Ich habe diese id-s nun auf einem Container geändert - der Container funktioniert gut. Auch auf dem Host gibt es aich einen Benutzer #5000.

Nun habe ich dies in der container conf hinzugefügt:

Code:
lxc.idmap: u 0 100000 5000
lxc.idmap: g 0 100000 5000
lxc.idmap: u 5000 5000 1
lxc.idmap: g 5000 5000 1
lxc.idmap: u 5001 105001 60535
lxc.idmap: g 5001 105001 60535

Und nach dem Neustart gehört der /home-Container des Benutzers zur uid 65534... was ist da falsch?
 
Last edited:

Dunuin

Active Member
Jun 30, 2020
986
179
43
Hast du auch die "/etc/sub{u,g}id" entsprechend für User 5000 angepasst?

Verschiedene Nutzer für alle Dienste ist ja prinzipiell eine gute Idee. Aber dann musst du halt mit Gruppenrechten arbeiten und das geht nur, wenn du da auch auf allen Gästen und dem Host überall die selben Nutzer und Gruppen anlegst und manuell synchron hältst. Sind entsprechende Gruppen mit allen Usern überall gleich, dann sollten Gruppen ja auch nach dem Remapping auch kein Problem mehr sein.

Oder man nutzt gleich VMs mit SMB Shares und spart sich das ganze unnötig umplizierte Rumgewurstel ;)
 
Last edited:

poisonborz

New Member
May 8, 2020
15
1
3
51
Das ist mein sub{u,g}id config - share ist die Host #5000 user:

Code:
root:100000:65536
share:165536:65536
root:5000:1

Ich hätte kein großes Problem damit, dies individuell für Containers zu tun - da ich es nur einmal tun müsste - solange es funktioniert...

Ja, der schlimmste Fall ist SMB, aber dann müsste ich es auf allen Gästen installieren, und Bind-Mounts wären so viel bequemer und schnell in der UI sichtbar (und ist auch der empfohlene Weg)
 

Dunuin

Active Member
Jun 30, 2020
986
179
43
Ja, der schlimmste Fall ist SMB, aber dann müsste ich es auf allen Gästen installieren, und Bind-Mounts wären so viel bequemer und schnell in der UI sichtbar (und ist auch der empfohlene Weg)
Gerade Dinge wie Nextcloud die offen im Internet hängen würde ich persönlich aber z.B. nicht in einem LXC laufenlassen wollen, da mir die Sicherheit wichtiger wäre als der RAM-Verbrauch oder die Performance der Laufwerke.

Das ist mein sub{u,g}id config - share ist die Host #5000 user:

Code:
root:100000:65536
share:165536:65536
root:5000:1
Dann weiß ich gerade auch nicht weiter. Sieht für mich soweit ok aus.
 

poisonborz

New Member
May 8, 2020
15
1
3
51
Nur eine Nebenbemerkung, ich habe dieses Problem umgangen, ohne UID-mapping.

Wie im OP angegeben, wollte ich nur Bind-Mounts zwischen Containern teilen, ohne dass die Möglichkeit besteht, dass Dateien für einige Container nicht verfügbar oder nur lesbar sind. Dazu sind keine bestimmten Benutzer erforderlich, nur voreingestellte Rechte. So ich habe 777 ACL-s zu den Root-Ordnern auf dem Host hinzugefügt - sicherheitstechnisch ist das kein Problem, da die Container nur die Bind-Mounts bekommen, auf die sie vollen Zugriff haben sollten.

Jeder, der das gleiche Problem hat, sollte sich überlegen, ob er wirklich einen bestimmten Benutzer als Eigentümer der Dateien benötigt - wenn nicht, ist eine ACL eine gute und viel einfachere Lösung. Ich wünschte immer noch, ich wüsste, was das Problem mit der UID-Zuordnung war, aber im Moment war es nicht erforderlich.
 
  • Like
Reactions: Dunuin

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!