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

Posté par ache (site web personnel) le 13 décembre 2021 à 15:44. Licence CC By‑SA.

Étiquettes :

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:2000Manifestement, 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:100001Dans 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 sagoum le 13 décembre 2021 à 21:53. É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 volts le 13 décembre 2021 à 23:14. É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 BiBite le 14 décembre 2021 à 22:48. É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 2¹⁶ - 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 ache (site web personnel) le 15 décembre 2021 à 02:34. Évalué à 1. Dernière modification le 15 décembre 2021 à 02:37.
      
      Pour l'utilisateur nobody, j'avais bien compris qu'il posait problème. Du coup, je m'en suis débarrassé directement dans /etc/passwd et group. ^{^"}
      
      Il semble quand même un peu utile : https://unix.stackexchange.com/questions/186568/what-is-nobody-user-and-group. Si jamais j'ai un problème, je le recréerai avec l'uid 1999.
      
      Merci beaucoup en tout cas, c'est bien plus clair maintenant ! Je risque également de passer au conteneur non-privilégié de root. Ça a l'air plus simple.
  - [^] # Re: corrige les fichiers /etc/subuid et /etc/subgid
    
    Posté par ache (site web personnel) le 15 décembre 2021 à 02:01. É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 ache (site web personnel) le 15 décembre 2021 à 02:28. É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.