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 :
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.
ache:0:2000
Quelqu’un pourrait m'expliquer ?
Merci.
PS: Après quelques tentatives, sans vraiment bien comprendre. En utilisant :
Dans subuid et subgid, j'ai cette erreur :
ache:0:100001
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 . É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 . É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):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
: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 . É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
etman 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 ache (site web personnel) . É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
etgroup
. "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) . É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 :
Mon
/etc/subuid
et/etc/subgid
ressemble à ça :Et là, ça ”marche”. Disons que le conteneur se crée. Mais avec des messages d'erreurs :
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) . É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.