• [^] # Re: corrige les fichiers /etc/subuid et /etc/subgid

    Posté par . En réponse au message Utilisation de LXC en mode non privilégié. Évalué à 3.

    Hello,

    oui, le wiki de Arch est pas mal ! Mais, globalement, c'est vrai qu'on trouve très peu d'infos sur LXC (encore pire depuis que LXD existe), et c'est bien dommage.

    La syntaxe de /etc/subuid est la suivante:
    <login>:<start_of_subuid_range>:<number_of_subuids_in_the_range>
    Ce fichier permet de réserver des plages d'UIDs pour chaque user du système.
    Source: man subuid et man subgid

    Sur une Debian/Ubuntu, il semblerait que 65536 UIDs soient nécessaires pour les besoin du système: de 0 à 65535 inclus
    Je n'ai pas trouvé de source propre, mais voici quelques indices :
    - http://www.debianhelp.co.uk/usersid.htm
    - /etc/passwd : le user nobody a l'UID 65534 (et on a envie d'arrondir à 65535 qui est 216 - 1)

    Donc, au minimum, on peut faire ça /etc/subuid :
    ache:65536:65536

    Le plus souvent, dans les tutos, on trouve ça :
    ache:100000:65536
    i.e. Les UIDs de 100000 (colonne 2) à 131071 inclus (65536 à 131071 nous font 65536 UIDs (colonne 3)) sont réservés pour le user "ache" (colonne 1).

    Explications :
    Le 1er UID réservable (colonne 2) doit être >= 65536 car on a vu que le 65535 est le dernier UIDs réservé et utilisé par le système. Souvent, ce 1er UID est arrondi à 100000 pour simplifier la lecture et la manipulation des UIDs. Dans cet exemple, on a donc une plage non utilisée de 65536 et 99999 inclus).
    En colonne 3, il est conseillé de réservé au moins 65536 UIDs si on veut pouvoir "booter" un système complet Debian/Ubuntu dans un container.

    Ensuite, avec ce /etc/subuid, le user "ache" peut créer un container en mappant le range d'UID "classique" qui va de 0 à 65535 (vu dans le container) sur 100000 à 131071 avec cette conf. LXC:
    lxc.idmap = u 0 100000 65536

    Ce qui signifie pour LXC: les UIDs qui commencent à 0 dans le container commencent à 100000 en dehors du container, et la taille de ce range est 65536 UIDs (0->65535 dans le container est 100000->131071 en dehors du container).
    Source: man lxc.container.conf ou https://linuxcontainers.org/lxc/manpages/man5/lxc.container.conf.5.html

    Et c'est tout pareil avec les GIDs.

    Perso, j'ai laissé tomber la création de containers non privilégiés depuis des users non-root :
    - les containers démarrés depuis un user non-root ne peuvent pas utiliser "lxc.start.auto" pour se faire démarrer au boot du serveur. Enfin, c'est possible, mais il faut se faire des units systemd à la main.
    - comme pour les UIDs/GIDs, il faut réserver des interfaces réseau dans /etc/lxc/lxc-usernet pour que les users non-privilégiés pour lancer un container qui a accès au réseau
    - d'après la doc. LXC, root peut aussi lancer des containers non privilégiés, qui, une fois lancés, n'ont pas plus de droits que ceux lancés par des users non-root.

    Donc je lance mes containers LXC non-privilégies depuis root pour avoir les avantages des containers non privilégiés, sans les inconvénients des containers lancés depuis des users non-root :)
    Mon /etc/subuid ressemble à ça:
    root:100000:10000000

    Ca me permet d'exécuter jusqu'à 100 containers isolés (oui, j'ai aussi arrondi la quantité d'UIDs à 100000 au lieu de 65536 par facilité) avec des confs. LXC qui suivent ce pattern:
    container1:
    lxc.idmap = u 0 100000 100000

    container2:
    lxc.idmap = u 0 200000 100000

    etc...