Forum Linux.général Utilisation de LXC en mode non privilégié

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
1
13
déc.
2021

Bonjour,

Je souhaite utiliser des conteneurs lxc en tant que simple utilisateur (utilisateur non privilégié).

Je n'ai aucun problème étant root, mais je n'arrive pas du tout à configurer la translation d'uid et d'id de groupe.

Lorsque j'essaye de créer un conteneur lxc j'ai ce message :

    $ lxc-create -n ml -t download -- --dist ubuntu
    lxc-create: ml: conf.c: lxc_map_ids: 3654 newuidmap failed to write mapping "newuidmap: uid range [0-1) -> [100000-100001) not allowed": newuidmap 27943 0 100000 1 1000 1000 1
    lxc-create: ml: conf.c: userns_exec_mapped_root: 5529 Error setting up {g,u}id mappings for child process "27943"
    lxc-create: ml: lxccontainer.c: do_lxcapi_create: 1805 Invalid argument - Failed to create container ml

J'essaye tant bien que mal de comprendre comment fonctionne le fichier /etc/subuid mais rien n'est claire pour moi.

    $ man subuid
    Each line in /etc/subuid contains a user name and a range of subordinate user ids that user is allowed to use. This is
    specified with three fields delimited by colons (« : »). These fields are:
    [...]

Ok donc mon utilisateur ache doit pouvoir utiliser l'ensemble des utilisateurs du conteneur, l'uid 0 inclut. Donc en lisant la documentation, ce fichier ne me semble pas déconnant, je n'aurais pas 1000 utilisateur sur mon conteneur :

ache:0:2000
Manifestement, je n'ai pas compris quelque chose, ou je n'ai rien compris du tout. Mon uid est 1000, tout comme l'id de mon groupe principal.

Quelqu’un pourrait m'expliquer ?
Merci.


PS: Après quelques tentatives, sans vraiment bien comprendre. En utilisant :

ache:0:100001
Dans subuid et subgid, j'ai cette erreur :

    lxc-create -n ml -t download -- --dist ubuntu
    lxc 20211213163145.370 ERROR    conf - conf.c:lxc_map_ids:3654 - newuidmap failed to write mapping "newuidmap: uid range [1001-66537) -> [101001-166537) not allowed": newuidmap 83559 0 100000 1000 1000 1000 1 1001 101001 65536
    Failed to write id mapping for child process
    lxc 20211213163145.371 ERROR    utils - utils.c:lxc_drop_groups:1345 - Operation not permitted - Failed to drop supplimentary groups
    lxc 20211213163145.371 ERROR    utils - utils.c:lxc_switch_uid_gid:1320 - Invalid argument - Failed to switch to gid 0
    lxc-create: ml: lxccontainer.c: create_run_template: 1618 Failed to create container from template
    lxc-create: ml: conf.c: lxc_map_ids: 3654 newuidmap failed to write mapping "newuidmap: uid range [1001-66537) -> [101001-166537) not allowed": newuidmap 83561 0 100000 1000 1000 1000 1 1001 101001 65536
    lxc-create: ml: conf.c: userns_exec_full: 5315 error setting up {g,u}id mappings for child process "83561"
    lxc-create: ml: lxccontainer.c: container_destroy: 2989 Error destroying rootfs for ml
    lxc-create: ml: tools/lxc_create.c: main: 317 Failed to create container ml

Il réussit quand même à créer le container ml mais il ne se lance pas :

    lxc-start -n ml
    lxc-start: ml: lxccontainer.c: wait_on_daemonized_start: 867 Received container state "ABORTING" instead of "RUNNING"

logfile :

    lxc-start ml 20211213163234.942 ERROR    conf - conf.c:lxc_map_ids:3654 - newuidmap failed to write mapping "newuidmap: uid range [1001-66537) -> [101001-166537) not allowed": newuidmap 83960 0 100000 1000 1000 1000 1 1001 101001 65536
    lxc-start ml 20211213163234.943 ERROR    start - start.c:lxc_spawn:1790 - Failed to set up id mapping.
    lxc-start ml 20211213163234.943 ERROR    lxccontainer - lxccontainer.c:wait_on_daemonized_start:867 - Received container state "ABORTING" instead of "RUNNING"
    lxc-start ml 20211213163234.943 ERROR    lxc_start - tools/lxc_start.c:main:306 - The container failed to start
    lxc-start ml 20211213163234.943 ERROR    lxc_start - tools/lxc_start.c:main:309 - To get more details, run the container in foreground mode
    lxc-start ml 20211213163234.943 ERROR    lxc_start - tools/lxc_start.c:main:311 - Additional information can be obtained by setting the --logfile and --logpriority options
    lxc-start ml 20211213163234.943 ERROR    start - start.c:__lxc_start:2073 - Failed to spawn container "ml"

  • # corrige les fichiers /etc/subuid et /etc/subgid

    Posté par  . Évalué à 3.

    salut

    ca fait un moment que je n'ai pas touché à lxc , mais pour moi ton fichier /etc/subuid n'est pas bon

    le premier chiffre doit être supérieur aux id déjà utilisé sur ta machine
    donc plutôt un truc du genre

    ache:2000:200 qui fera que tu auras les id de 2000 à 2200.

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

      Posté par  . Évalué à 3.

      Bonsoir,

      Je n'ai pas l'habitude d'utiliser des conteneurs non-privilégiés. Ce qui suit est à faire avec précaution et en connaissance des risques.

      Pour compléter la réponse ci-dessus, je pense qu'il faudrait ajouter le fichier /etc/lxc/default.conf de cette façon (exemple directement tiré du wiki de Archlinux):

      lxc.idmap = u 0 2000 200
      lxc.idmap = g 0 2000 200
      

      Et ensuite, oui, il faut remporter ces valeurs. Et c'est où je ne suis pas d'accord avec l'exemple de sagoum car il s'agit de remporter ces valeur pour l'utilisateur root du conteneur et non pas l'utilisateur qui va réellement lancer le conteneur.
      Ça donne donc le même contenu pour /etc/subuid et /etc/subgid:

      root:2000:200
      

      Pour ce qui est de lancer le conteneur par l'utilisateur ache, il faudrait regarder en détail l'exemple fourni par le wiki.

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

        Posté par  . É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…

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

        Posté par  (site web personnel) . Évalué à 2. Dernière modification le 15 décembre 2021 à 10:05.

        Merci à vous !

        Donc j'ai modifié le fichier /etc/lxc/default.conf et également le mien dans ~ache/.config/lxc/default.conf.

        En ajoutant ceci :

             lxc.idmap = u 1000 1000 1
             lxc.idmap = g 1000 1000 1
        
             lxc.idmap = u 0 2000 200
             lxc.idmap = g 0 2000 200

        Mon /etc/subuid et /etc/subgid ressemble à ça :

              ache:1000:1
              ache:2000:200

        Et là, ça ”marche”. Disons que le conteneur se crée. Mais avec des messages d'erreurs :

             tar: ./var/log/lastlog : le propriétaire ne peut pas être changé en uid 0, gid 997: Argument invalide
             tar: ./var/log/btmp : le propriétaire ne peut pas être changé en uid 0, gid 997: Argument invalide
             tar: ./var/log/wtmp : le propriétaire ne peut pas être changé en uid 0, gid 997: Argument invalide
             tar: ./var/log/journal/remote : le propriétaire ne peut pas être changé en uid 0, gid 981: Argument invalide
             tar: ./var/log/journal : le propriétaire ne peut pas être changé en uid 0, gid 983: Argument invalide
             tar: Arrêt avec code d'échec à cause des erreurs précédentes
             lxc-create: ache: lxccontainer.c: create_run_template: 1618 Failed to create container from template
             lxc-create: ache: tools/lxc_create.c: main: 317 Failed to create container ache

        Bref, j'investiguerais ça. Mais pour l'instant le mapping à pas l'air mauvais. Je crois que j'ai compris comment il fonctionne ! Merci à vous ! :)

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

          Posté par  (site web personnel) . Évalué à 1.

          Oh ! Apparemment, c'est le conteneur archlinux qui a ce problème, le conteneur ubuntu fonctionne. 👌

          Je dois configurer /etc/lxc/lxc-usernet

          ache veth lxcbr0 11

          Et lancer le conteneur avec :

          $ systemd-run --user --scope lxc-start -n sandbox
          $ systemd-run --user --scope lxc-attach -n sandbox

          Ça marche nickel. 👌

          PS: J'ai également fait systemctl edit user@1000.service pour ajouter

          [Service]
          Delegate=cpu cpuset io memory pids

          Mais je ne comprends pas bien si ça a eu un effet. J'ai l'impression passer à côté de quelque chose dans le nom de ce service. user@1000 pour moi c'est un service comme un autre, je comprends pas bien pourquoi il existait déjà et pourquoi il fait ce qu'il doit faire. En utilisant l'option --full j'ai l'impression que c'est un service générique. On peut utiliser des paramètres dans les units systemd ? Ici le paramètre est 1000 ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.