GIDs / UID subordonnés avec LXC et userns pour user non privilégié?

Lorsque vous utilisez des users (via LXC dans mon cas), vous affectez une gamme de GID et d'UID subordonnés à un user non privilégié. Voir pour les ressources: subuid(5) , subgid(5) , newuidmap(1) , newgidmap(1) , user_namespaces(7) .

Cette plage peut ensuite être utilisée et via les users être mappée sur le count système.

Supposons que nous ayons un count système (hôte) john avec un UID (et un GID) de 1000. La plage assignée de GID et d'UID est 100000..165536.

Une input existe donc dans /etc/subgid et /etc/subuid respectivement:

 john:100000:65536 

Les files à l'intérieur du conteneur non privilégié sont la propriété de john "inside" qui appartiendra désormais à 101000 sur l'hôte et ceux appartenant à la root "inside" seront la propriété de 100000.

Normalement, ces plages ne sont affectées à aucun nom sur l'hôte.

Des questions:

  1. est-ce bien de créer un user pour ces UID / GID respectifs sur l'hôte afin d'avoir une sortie plus significative pour ls et amis?
  2. existe-t-il un moyen de rendre ces files / dossiers accessibles à l'user hôte qui "possède" les users, c'est-à-dire john dans notre cas? Et si c'est le cas, est la seule méthode sensée pour créer un groupe partagé entre ces users valides à l'intérieur de la gamme subordonnée et les userns "propriétaire" et définir les permissions en conséquence? Eh bien, ou ACL, évidemment.

  1. Est-ce bien de créer un user pour ces UID / GID respectifs sur l'hôte afin d'avoir une sortie plus significative pour ls et amis?

Oui c'est bon. Cependant, vous devez vous assurer que cet user n'a aucun droit sur le système hôte:

  • Accès ou mot de passe désactivé
  • Aucun shell de connection utilisable,
  • Aucun directory personnel inscriptible.

Assurez-vous également de ne pas créer de duplicates dans vos noms d'user.

Voici un exemple de script, en prenant les files /etc/passwd et /etc/group l'invité pour créer les users correspondants dans le système hôte. Tous les noms sont préfixés avec le nom du conteneur et tous les ID sont augmentés en utilisant la valeur donnée pour correspondre aux UID du conteneur:

 #! /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 

Les avertissements concernant le directory de base inaccessible sont normaux et attendus: c'est le but réel de /nonexistent de ne pas exister.

  1. existe-t-il un moyen de rendre ces files / dossiers accessibles à l'user hôte qui "possède" les users, c'est-à-dire john dans notre cas? Et si c'est le cas, est la seule méthode sensée pour créer un groupe partagé entre ces users valides à l'intérieur de la gamme subordonnée et les userns "propriétaire" et définir les permissions en conséquence? Eh bien, ou ACL, évidemment.

Cela devrait vraiment valoir la peine d'une question distincte IMO.

Puisque le contenu du conteneur est détenu par des UID différents de ceux du propriétaire du conteneur, il n'est pas accessible. Je peux imaginer une exception à cette règle pour les sous-users, mais il n'y en a actuellement aucun dont je sois conscient (j'ai créé une question connexe il y a quelques time, mais pas encore de réponse).

Les files /etc/subuid et /etc/subgid sont actuellement utilisés que par newuidmap (1) pour autoriser ou refuser le passage d'un UID / GID à un autre d'un process donné. Il ne donne pas d'autre droit au propriétaire de la gamme.

Par conséquent, la solution à ce problème devrait être conçue au cas par cas. Méfiez-vous toutefois de votre idée ACL: supposons que vous placiez des ACL sur les files du conteneur pour permettre à l'hôte UID 1000 de les lire, ce qui signifie que l'user du conteneur avec le conteneur UID 1000 aura le même niveau de privilège …