Untergeordnete GIDs / UIDs mit LXC und Benutzern für nicht privilegierte Benutzer?


7

Wenn Sie Benutzer verwenden (in meinem Fall über LXC), weisen Sie einem nicht privilegierten Benutzer eine Reihe von untergeordneten GIDs und UIDs zu. Siehe für mehr Informationen: subuid(5), subgid(5), newuidmap(1), newgidmap(1), user_namespaces(7).

Dieser Bereich kann dann verwendet werden und wird über dem Systemkonto zugeordnet werden.

Nehmen wir an, wir haben ein (Host-) Systemkonto johnmit einer UID (und GID) von 1000. Der zugewiesene Bereich von GIDs und UIDs ist 100000..165536.

So ein Eintrag existiert in /etc/subgidund /etc/subuidjeweils:

john:100000:65536

Dateien, die sich innerhalb des nicht privilegierten Containers im Besitz des "Inside" befinden john, gehören jetzt 101000 auf dem Host, und Dateien, die dem "Inside" gehören root, gehören 100000.

Normalerweise werden diese Bereiche keinem Namen auf dem Host zugewiesen.

Fragen:

  1. Ist es in Ordnung, einen Benutzer für die jeweiligen UIDs / GIDs auf dem Host zu erstellen, um eine aussagekräftigere Ausgabe für lsund Freunde zu erhalten?
  2. Gibt es eine Möglichkeit, diese Dateien / Ordner dem Hostbenutzer zugänglich zu machen, dem die Benutzer "gehören", dh johnin unserem Fall? Und wenn ja, ist die einzig sinnvolle Methode, eine Gruppe zu erstellen, die von diesen gültigen Benutzern innerhalb des untergeordneten Bereichs und dem "Eigentümer" des Benutzers gemeinsam genutzt wird, und die Berechtigungen entsprechend festzulegen? Na ja, oder ACLs natürlich.

Antworten:


2
  1. Ist es in Ordnung, einen Benutzer für die jeweiligen UIDs / GIDs auf dem Host zu erstellen, um eine aussagekräftigere Ausgabe für ls und Freunde zu erhalten?

Ja, es ist in Ordnung. Sie müssen jedoch sicherstellen, dass dieser Benutzer kein Recht auf irgendetwas im Hostsystem hat:

  • Deaktivierter Zugriff oder Passwort,
  • Keine verwendbare Login-Shell,
  • Kein beschreibbares Home-Verzeichnis.

Stellen Sie außerdem sicher, dass Sie keine Duplikate in Ihren Benutzernamen erstellen.

Hier ist ein Beispielskript, das die Gäste /etc/passwdund /etc/groupDateien verwendet, um die entsprechenden Benutzer im Hostsystem zu erstellen. Allen Namen wird der Containername vorangestellt, und alle IDs werden unter Verwendung des angegebenen Werts erhöht, um den UIDs des Containers zu entsprechen:

#! /bin/sh

# Path to guest's `/etc' directory.
guest_etc=/var/lib/lxc/mycontainer/rootfs/etc
# Guest's name, used as login prefix and inside GECOS field.
guest_name=mycontainer
# Increment to be applied to UIDs and GIDs (= range start).
uid_incr=100000
gid_incr=$uid_incr

guest_passwd=${guest_etc}/passwd
guest_group=${guest_etc}/group

exec <$guest_group
while IFS=":" read name pass gid null; do
    gid_new=$( expr $gid + $gid_incr )
    if ! getent group $gid_new >/dev/null; then
        addgroup --system --gid $gid_new "${guest_name}_${name}"
    fi  
done

exec <$guest_passwd
while IFS=":" read login pass uid gid gecos null; do
    uid_new=$( expr $uid + $uid_incr )
    gid_new=$( expr $gid + $gid_incr )
    if ! getent passwd $uid_new >/dev/null; then
        adduser --system --home /nonexistent --no-create-home \
            --shell /bin/nologin --uid $uid_new --gid $gid_new \
            --gecos "\"$guest_name container user (${gecos})\"" \
            "${guest_name}_${login}"
    fi  
done

Die Warnungen bezüglich des unzugänglichen Home-Verzeichnisses sind normal und werden erwartet: Dies ist der eigentliche Zweck /nonexistent, nicht zu existieren.

  1. Gibt es eine Möglichkeit, diese Dateien / Ordner dem Host-Benutzer zugänglich zu machen, dem die Benutzer "gehören", in unserem Fall John? Und wenn ja, ist dies die einzig sinnvolle Methode, um eine Gruppe zu erstellen, die von diesen gültigen Benutzern innerhalb des untergeordneten Bereichs und dem "Eigentümer" des Benutzers gemeinsam genutzt wird, und die Berechtigungen entsprechend festzulegen? Na ja, oder ACLs natürlich.

Dies sollte wirklich eine separate Frage wert sein, IMO.

Da der Inhalt des Containers anderen UIDs gehört als die UID des Containereigentümers, ist er für ihn nicht zugänglich. Ich kann mir eine Ausnahme von dieser Regel für Unterbenutzer vorstellen, aber es gibt derzeit keine, die mir bekannt sind (ich habe vor einiger Zeit eine verwandte Frage erstellt, aber noch keine Antwort).

Die Dateien /etc/subuidund /etc/subgidwerden derzeit nur von newuidmap(1) verwendet, um den Wechsel von einer UID / GID zu einer anderen eines bestimmten Prozesses zuzulassen oder zu verweigern. Es gibt dem Bereichsinhaber kein anderes Recht.

Daher sollte die Lösung für ein solches Problem von Fall zu Fall festgelegt werden. Beachten Sie jedoch Ihre ACL-Idee: Nehmen wir an, Sie fügen einige ACLs in die Dateien des Containers ein, damit die UID 1000 Ihres Hosts sie lesen kann. Dies bedeutet, dass der Benutzer des Containers mit der UID 1000 des Containers auch die gleichen Berechtigungen hat ...

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.