Si on y va, je suis plus favorable à l'option RUNP, au lieu d'avoir
tous les conteneurs s'exécutant en mode privilégié.

Le mer. 18 sept. 2013 à 13:07, Benjamin Podszun
[email protected] a écrit :

Actuellement, il semble n'y avoir aucun moyen d'exécuter des opérations privilégiées en dehors de
docker run -privilégié.

Cela signifie que je ne peux pas faire les mêmes choses dans un Dockerfile. mon récent
problème : j'aimerais exécuter fuse (pour encfs) à l'intérieur d'un conteneur. Installation
fuse est déjà un gâchis avec des hacks et des solutions de contournement laides (voir [1] et [2]),
car mknod échoue/n'est pas pris en charge sans une étape de construction privilégiée.

La seule solution de contournement pour le moment est de faire l'installation manuellement, en utilisant
run -privileged et en créant une nouvelle "image de base de fusible". Ce qui veut dire que je
ne peut pas décrire l'ensemble du conteneur, d'une image de base officielle à la finition,
dans un seul Dockerfile.

Je suggère donc d'ajouter soit

• une build docker -privilégié
  cela devrait faire la même chose que run -privileged, c'est-à-dire supprimer tout
  limitations des majuscules

ou

• une commande RUNP dans le Dockerfile
  cela devrait .. bien .. RUN, mais avec _P_rivileges

J'ai essayé de regarder la source, mais je suis inutile avec go et je n'ai pas trouvé de
point d'entrée décent pour joindre une preuve de concept, malheureusement. :(

1 : https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: #514 (commentaire) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/dotcloud/docker/issues/1916
.

Victor VIEUX
http://vvieux.com

En fait, nous devrons peut-être faire les deux - c'est-à-dire que RUNP + nécessite un "-privileged"
drapeau.

Si nous comptons uniquement sur RUNP (sans exiger "-privileged"), alors nous
devons nous demander quand nous faisons une construction "est-ce que cette construction est sûre ?".
Si on se fie uniquement à "-privileged", on passe à côté de l'information (dans le
Dockerfile) que "cette action nécessite des privilèges étendus".

Je pense qu'une combinaison des deux est le moyen le plus sûr.

Le mer. 18 sept. 2013 à 04:07, Benjamin Podszun
[email protected] a écrit :

Actuellement, il semble n'y avoir aucun moyen d'exécuter des opérations privilégiées en dehors de
docker run -privilégié.

Cela signifie que je ne peux pas faire les mêmes choses dans un Dockerfile. mon récent
problème : j'aimerais exécuter fuse (pour encfs) à l'intérieur d'un conteneur. Installation
fuse est déjà un gâchis avec des hacks et des solutions de contournement laides (voir [1] et [2]),
car mknod échoue/n'est pas pris en charge sans une étape de construction privilégiée.

La seule solution de contournement pour le moment est de faire l'installation manuellement, en utilisant
run -privileged et en créant une nouvelle "image de base de fusible". Ce qui veut dire que je
ne peut pas décrire l'ensemble du conteneur, d'une image de base officielle à la finition,
dans un seul Dockerfile.

Je suggère donc d'ajouter soit

• une build docker -privilégié
  cela devrait faire la même chose que run -privileged, c'est-à-dire supprimer tout
  limitations des majuscules

ou

• une commande RUNP dans le Dockerfile
  cela devrait .. bien .. RUN, mais avec _P_rivileges

J'ai essayé de regarder la source, mais je suis inutile avec go et je n'ai pas trouvé de
point d'entrée décent pour joindre une preuve de concept, malheureusement. :(

1 : https://github.com/rogaha/docker-desktop/blob/master/Dockerfile#L40
2: #514 (commentaire) https://github.com/dotcloud/docker/issues/514#issuecomment -22101217

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/dotcloud/docker/issues/1916
.

@jpetazzo https://twitter.com/jpetazzo
Dernier article de blog : http://blog.docker.io/2013/09/docker-joyent-openvpn-bliss/

Semble raisonnable. Pour moi, cette fonctionnalité (pouvoir créer des nœuds de périphérique) rend ou interrompt la possibilité de créer le déploiement dans Docker. Si je peux aider (en testant principalement, j'ai essayé de regarder la source mais j'ai échoué jusqu'à présent. Il semble que les commandes disponibles dans un fichier de construction soient trouvées via la réflexion, j'ai ajouté une commande runp qui définissait config.privileged sur true, mais jusqu'à présent, je suis incapable de construire et de tester -> bloqué) J'investirais volontiers un peu de temps.

Je suggérerais RUNP + build -privileged .

_allume des signaux de fumée pour attirer l'attention de @shykes , @crosbymichael_

... Et puis il faudra trouver quelqu'un pour le mettre en œuvre, bien sûr ☺
Serait-ce quelque chose que vous voudriez essayer (avec les conseils appropriés et les commentaires de l'équipe principale, bien sûr) ?

Si la dernière partie me visait : Bien sûr, pourquoi pas. Je suis déjà en train de jouer avec le code go (ce n'est pas un langage que je connais bien, mais voyez ci-dessus : j'essaie de comprendre ce qui se passe de toute façon).

Avec quelques pointeurs / quelqu'un à qui répondre pour certaines questions, je ferais certainement un essai.

Je ne suis pas vendu sur RUNP ou build -privileged.

​

En général, je n'aime rien qui présente différentes versions possibles de la même entrée. C'est pourquoi vous ne pouvez pas passer d'arguments ou de variables d'environnement à un build.

Plus précisément, je n'aime pas introduire des dépendances sur "privilégié" partout, car cela désigne un ensemble de capacités qui est a) très grand et b) pas clairement spécifié ou défini. C'est ok comme mécanisme grossier pour que les administrateurs système contournent la sécurité d'une manière tout ou rien - une " trappe de sortie " lorsque l'environnement d'exécution standard de docker ne suffit pas. C'est similaire de cette manière aux montages de liaison et à la configuration de lxc-conf personnalisée.

-
@solomonstre
@getdocker

Le ven. 20 sept. 2013 à 15:18, Benjamin Podszun
[email protected] a écrit :

Si la dernière partie me visait : Bien sûr, pourquoi pas. Je suis déjà en train de jouer avec le code go (ce n'est pas un langage que je connais bien, mais voyez ci-dessus : j'essaie de comprendre ce qui se passe de toute façon).

Avec quelques pointeurs / quelqu'un à qui répondre pour certaines questions, je ferais certainement un essai.

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/dotcloud/docker/issues/1916#issuecomment-24844868

Eh bien, êtes-vous d'accord pour dire qu'il devrait être possible de créer une image docker qui - par exemple - exécute un fusible ?
Pour cela, nous aurions besoin de mknod.

La façon dont je le vois, il n'y a aucun moyen que ces builds puissent être différents en fonction des paramètres : Il y a peu ou pas de risque de "versions" différentes du même fichier de construction, n'est-ce pas ?

Je rencontre ce problème maintenant. Pour construire l'image dont j'ai besoin, je dois effectuer une série d'étapes run -privileged + une étape commit , plutôt que build un Dockerfile. Idéalement, ce serait bien d'exprimer les étapes de construction de l'image dans un Dockerfile.

Est-ce également lié aux opérations mknod ?
Si vous pouviez décrire exactement les actions qui nécessitent le mode privilégié dans
votre cas, ce serait très utile!
Merci,

Salut @jpetazzo , dans la liste de diffusion, voici le problème auquel je suis confronté : https://groups.google.com/forum/#!topic/docker -user/1pFhqlfbqQI

J'essaie de mount un fs que j'ai créé (créé pour contourner aufs et quelque chose à propos de la journalisation ) à l'intérieur du conteneur. La commande spécifique que j'exécute est mount -o loop=/dev/loop0 /db/disk-image /home/db2inst1 , où /db/disk-image été créé avec dd if=/dev/zero of=disk-image count=409600 et home/db2inst1 est l'endroit où j'essaie de démarrer db2.

Si je comprends bien, pendant le processus d'installation, vous avez besoin d'un répertoire non AUFS - ou plutôt, quelque chose qui prend en charge O_DIRECT . Si tel est le cas, Docker 0.7 devrait résoudre le problème, car il utilisera ext4 (et des instantanés au niveau du bloc) au lieu d'AUFS.

+1 pour cela aussi.

L'installation de packages nécessitant une modification des paramètres de mémoire et de la configuration du noyau (par exemple, Vertica DB, WebSphere MQ) ne peut être effectuée qu'en mode privilégié.

Essayons de séparer les préoccupations en ce qui concerne l'exécution / la construction avec "privileged": cela peut être requis uniquement pendant la construction, uniquement pendant l'exécution via docker run ou les deux.

Il devrait être possible d'autoriser un build à faire quelque chose nécessitant un peu plus d'autorisations pour une étape (ou plus) si cela est nécessaire. J'en avais besoin pour un projet et devais convertir la moitié d'un Dockerfile en un script shell qui invoquait la construction et continuait à construire des choses en mode privilégié, donc avoir une construction "privilégiée" serait utile.

Cependant, nous ne devrions pas aller jusqu'au mode privilégié par défaut juste pour pouvoir utiliser sysctl pour modifier certains paramètres. Cela doit être fait via la configuration de l'image ou via les arguments de ligne de commande à transmettre à docker run .

Droit. @orikremer , avez-vous des détails sur les paramètres que Vertica DB et WebSphere MQ tentaient de modifier ?

S'il s'agit de choses dans /sys ou /proc, la meilleure solution pourrait être d'y mettre une maquette à la place, plutôt que de passer en mode privilégié (puisque les modifications ne seront pas persistantes de toute façon).

À long terme, un système de fichiers fictif peut capturer les modifications et les convertir en directives Dockerfile, indiquant au runtime que « hé, ce conteneur a besoin de tel ou tel ajustement ».

@jpetazzo Cela fait quelques jours que j'ai créé l'image. AFAIR Vertica se plaignait de ne pas avoir assez de mémoire et les deux essayaient de modifier le nombre maximal de fichiers ouverts.
Je vais essayer de recréer l'image à l'aide d'un Dockerfile et de faire rapport.

Notant le problème #2080 car il est lié.

@jpetazzo a commencé à recréer l'image sans -privileged. Deux problèmes à ce jour :

• nice dans limites.conf : Vertica ajoute "dbadmin - nice 0" à /etc/security/limits.conf. Lorsque j'essaie de passer à cet utilisateur lors de l'exécution dans un conteneur non privilégié, une erreur "Impossible d'ouvrir la session" s'affiche. Dans un conteneur privilégié, l'utilisateur travaille sans erreur.
• max open files: puisque le max nécessaire dans le conteneur était supérieur à celui défini dans l'hôte, j'ai dû modifier /etc/init/docker.conf sur l'hôte et définir "limit nofile" puis ulimit -n dans le conteneur. Est-ce la bonne approche ?

Lorsque vous essayez de passer à cet utilisateur,

Comment se passe le basculement ? Je ne comprends pas comment -privileged aiderait à changer d'utilisateur ; Il me manque probablement quelque chose ici :-)

max de fichiers ouverts

Si je comprends bien, le programme d'installation de Vertical essaie de définir le nombre maximal de fichiers ouverts sur un nombre très élevé, et cela ne fonctionne que si Docker a été démarré avec un nombre aussi élevé _ou_ avec le drapeau -privileged ; droit?

changement d'utilisateur - su dbadmin échoue avec cette erreur.
J'ai pu reproduire par :

• extraire une nouvelle image (centos-6.4-x86_64) et exécuter sans privilège
• useradd testuser
• éditez /etc/security/limits.conf, ajoutez "testuser - nice 0"
• essayez su testuser --> devrait échouer avec "impossible d'ouvrir la session"
  Dans un conteneur privilégié, su testuser fonctionne bien.

max fichiers ouverts - correct. le programme d'installation essaie de définir un nombre supérieur à celui de l'hôte. Ce n'est qu'en augmentant le paramètre hosts ou en démarrant -privileged que cela fonctionne.

Je viens d'essayer avec le Dockerfile suivant :

FROM ubuntu
RUN useradd testuser
RUN echo testuser - nice 0 > /etc/security/limits.conf
CMD su testuser

Et ça marche bien. Quel est le nom exact de l'image que vous utilisez ?
(J'ai essayé centos-6.4-x86_64 mais on dirait que je ne peux pas le tirer !)

@lukewpatterson Pouvez-vous expliquer comment vous avez fait fonctionner le système de fichiers en boucle dans votre conteneur ?

@jpetazzo Exécuter ce fichier docker

FROM backjlack/centos-6.4-x86_64
RUN useradd testuser
RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
RUN su testuser
RUN echo 'test' > ~/test.txt

a échoué avec :

ori<strong i="10">@ubuntu</strong>:~/su_test$ sudo docker build .
Uploading context 10240 bytes
Step 1 : FROM backjlack/centos-6.4-x86_64
 ---> b1343935b9e5
Step 2 : RUN useradd testuser
 ---> Running in b41d9aa2be1b
 ---> 2ff05b54e806
Step 3 : RUN echo 'testuser - nice 0' >> /etc/security/limits.conf
 ---> Running in e83291fafc66
 ---> 03b85baf140a
Step 4 : RUN su testuser
 ---> Running in c289f6e5f3f4
could not open session
Error build: The command [/bin/sh -c su testuser] returned a non-zero code: 1
The command [/bin/sh -c su testuser] returned a non-zero code: 1
ori<strong i="11">@ubuntu</strong>:~/su_test$

J'ai activé le débogage pour le module PAM (en ajoutant debug à la ligne pam_limits.so dans /etc/pam.d/system-auth ), installé syslog , essayé de su encore, et voici ce que j'ai trouvé dans /var/log/secure :

7 octobre 14:12:23 8be1e7bc5590 su: pam_limits(su:session): lecture des paramètres de '/etc/security/limits.conf'
7 octobre 14:12:23 8be1e7bc5590 su: pam_limits(su:session): process_limit: processing - nice 0 pour USER
7 octobre 14:12:23 8be1e7bc5590 su: pam_limits(su:session): lecture des paramètres de '/etc/security/limits.d/90-nproc.conf'
7 octobre 14:12:23 8be1e7bc5590 su: pam_limits(su:session): process_limit: traitement soft nproc 1024 pour DEFAULT
7 octobre 14:12:23 8be1e7bc5590 su : pam_limits(su:session) : impossible de définir la limite pour « nice » : opération non autorisée

Ensuite, j'ai strace d le processus su et j'ai découvert que l'appel système suivant échouait :

setrlimit(RLIMIT_NICE, {rlim_cur=20, rlim_max=20}) = -1 EPERM (Operation not permitted)

Ceci, à son tour, amène le module pam_limits à signaler un échec ; et cela empêche su de continuer.
Fait intéressant, sur Ubuntu, pam_limits n'est pas activé pour su par défaut ; et même si vous l'activez, l'appel setrlimit échoue, mais su continue et fonctionne quand même.
Cela pourrait être lié au code d'audit, je ne suis pas sûr.

Maintenant, pourquoi setrlimit échoue-t-il ? Parce que le conteneur n'a pas la capacité sys_resource , qui est nécessaire pour augmenter tout type de limite.

Je pense que je voudrais juste commenter cette directive limits.conf .
(Au fait, c'est une mauvaise pratique d'ajouter des éléments directement à limits.conf ; je pense que cela devrait aller dans un fichier séparé dans limits.d .)

Remarque : puisque vous avez déjà augmenté la limite du nombre de fichiers ouverts pour Docker, vous pouvez également augmenter la limite de la priorité maximale ; ça devrait marcher aussi !

J'espère que ça aide.

Dans ce Dockerfile, vous avez la ligne suivante :

RUN su testuser

Il n'y a pas de commande pour aller avec cela (et il n'appliquera aucun shell résultant aux commandes RUN suivantes), donc je ne serais pas surpris si cela échoue vraiment à essayer d'ouvrir un shell et à ne pas être dans un endroit interactif qui a du sens (puisque docker build n'est pas un processus interactif). Je n'ai pas le temps pour le moment de confirmer, mais cela vaut probablement la peine d'essayer avec une commande réelle passée à su .

@jpetazzo Merci pour la description détaillée. Je vais essayer d'augmenter la priorité maximale pour Docker et voir si cela aide.

(Soit dit en passant, c'est une mauvaise pratique d'ajouter des éléments directement à bounds.conf ; je pense que cela devrait aller dans un fichier séparé dans bounds.d.)

D'accord, mais comme il s'agit du code d'installation de Vertica qui le met là, j'essaie de contourner cela.

@tianon La même chose se produit si je l'exécute dans un shell interactif (/bin/bash).

Mes excuses, je pense que ça valait quand même la peine d'essayer.

Le point sur cette ligne qui n'a pas beaucoup de sens dans le Dockerfile s'applique toujours cependant. Vous vouliez probablement quelque chose de plus comme ça (après avoir compris les problèmes de limites) :

RUN su testuser -c 'echo test > ~/test.txt'

@tianon tu as raison, ça n'a pas beaucoup de sens. C'était simplement pour démontrer que le su lui-même échoue.

Pour revenir à la discussion d'origine : je pense qu'il est bien du point de vue de la sécurité (et utile !) d'autoriser les capacités setfcap et mknod dans le processus de construction (et probablement dans bien). Quelqu'un voit-il un problème qui pourrait en découler ?

@jpetazzo Bien au contraire ! Cela résoudrait de nombreux problèmes que je rencontre. Je pense que cela est nécessaire pour les personnes qui souhaitent exécuter des conteneurs Docker qui ressemblent davantage à une vraie machine.

D'ACCORD! Si cela vous convient, je ferme ce problème en faveur de #2191, "Activer les capacités mknod et setfcap dans tous les conteneurs" alors :-)

Connaît-on de tels scénarios ?

Le dimanche 13 octobre 2013 à 12h22, unclejack [email protected] a écrit :

2191 https://github.com/dotcloud/docker/issues/2191 ne résout pas ce problème

problème pour tous les scénarios qui nécessiteraient la construction de docker -privileged.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -26224788
.

@jpetazzo https://twitter.com/jpetazzo
Dernier article de blog :
http://jpetazzo.github.io/2013/10/06/policy-rc-d-do-not-start-services-automatically/

@jpetazzo Ceci est nécessaire lorsque vous souhaitez utiliser un Dockerfile pour créer une image du système d'exploitation.

J'ai supprimé mon commentaire par erreur en l'éditant.

Veuillez regarder à quoi cela ressemblerait sans tout faire dans un Dockerfile :

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh

build.sh

docker build -t mybuild .
docker run -i -t -privileged -cidfile mybuild.cid mybuild /root/build.sh
buildcid=`cat mybuild.cid`
rm mybuild.cid
docker commit $buildcid mybuild-final

Cela m'oblige simplement à contourner le manque de runp dans le Dockerfile ou docker build -privileged , rendant ainsi Dockerfiles inutile et m'obligeant à écrire un outil pour dupliquer les fonctionnalités de type Dockerfile.

Evidemment, le Dockerfile serait bien plus utile avec runp ou docker build -privileged :
exemple runp :

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
runp /root/build.sh

Exemple de docker build -privileged :

from ubuntu:12.04
run apt-get update
[... a few more run commands]
add build.sh /root/build.sh
run /root/build.sh

@unclejack : désolé, ma question n'était pas assez précise !
Ce que je voulais dire, c'est "de quelle autorisation avez-vous besoin exactement (en plus de mknod et setfcap) ?"

@jpetazzo C'est difficile à dire, je devrais vérifier cela d'une manière ou d'une autre pour déterminer ce qui est nécessaire. Monter des systèmes de fichiers, utiliser des périphériques de bloc montés en boucle et quelques autres choses.

Il existe au moins trois besoins distincts lorsqu'il s'agit de créer des images : les autorisations requises lors d'un docker build , les autorisations requises lors de l'exécution d'un conteneur avec docker et les besoins d'exécution des processus lors de la construction, de l'exécution ou des deux (comme sysctls et autres) .

Je pense qu'avoir docker build -privileged (ou runp pour utiliser le mode -privileged uniquement pour les commandes qui en ont vraiment besoin) serait utile.

Ah, les montures sont définitivement un gros problème. C'est un cas d'utilisation très valable, et nous ne voulons probablement pas les autoriser dans le cas général. Je rouvre le sujet.

@jpetazzo RE: module PAM (

Peut-être que certaines de ces limites peuvent être définies via le fichier docker.conf ?

Il convient de considérer que Docker lui-même peut s'exécuter dans un ensemble limité de capacités, ces privilèges pouvant ne pas être disponibles pour que Docker délègue à ses conteneurs. Cela serait particulièrement vrai dans un scénario Docker imbriqué qui devrait émettre un terrain # 2080 - cela pourrait autoriser Docker imbriqué non privilégié.

Cela ne change rien, sauf que des solutions telles que "runp" ou "-priviledged" peuvent ne pas garantir le succès dans tous les environnements Docker. Cela doit être pris en compte lors de l'ajout de telles commandes et lors de leur documentation.

@ramarnat @jpetazzo juste pour boucler la boucle sur l'installation de Vertica et le problème de niveau sympa,
J'ai essayé de définir la limite nice dans docker.conf mais cela n'a pas fonctionné pour moi et j'ai été obligé d'exécuter bash privilégié et de l'installer manuellement.

@orikremer @jpetazzo J'ai pu exécuter l'installation en supprimant sys_resource de lxc_template.go et en recompilant docker. Je peux envoyer une pull request, mais j'attendrai que d'autres se prononcent sur les implications de sécurité de la suppression de cela de la configuration lxc.

@ramarnat : selon le scénario, certaines personnes penseront que supprimer sys_resource est bien ; pour d'autres, ce sera un problème.

Une possibilité pourrait être d'augmenter les limites de base à quelque chose de plus élevé (les descripteurs de fichiers sont également un problème pour Elastic Search). Cela reviendrait à affirmer "un environnement d'exécution Docker minimal devrait être capable de gérer 1 000 000 de descripteurs de fichiers". Si Docker ne peut pas augmenter la limite au démarrage, il émet un avertissement et continue (comme il le fait pour le groupe de contrôleurs de mémoire/échange).

Cependant, cela ne résout pas le scénario de montage/boucle (je dors toujours sur celui-ci).

@jpetazzo peut fournir un moyen de remplacer les valeurs codées en dur dans lxc_template.go. Il y a déjà quelque chose pour le scénario avec la ligne de commande -lxc_conf, mais cela ne fonctionne pas pour la nature .drop de ces directives de configuration lxc - j'ai essayé !

Eh bien, c'est une possibilité, mais c'est aussi un bon moyen de briser la compatibilité future entre différents systèmes de conteneurisation :-) Nous verrons si nous ne pouvons pas trouver mieux.

Pourrions-nous ajouter /dev/loop* à la liste blanche en mode non privilégié ? Je suppose que le problème est que cela pourrait me donner accès aux fichiers montés en boucle d'autres conteneurs, ou même à ceux de l'hôte ...

@solomonstre
@docker

Le jeu. 17 oct. 2013 à 18:09, Jérôme Petazzoni
[email protected] a écrit :

Eh bien, c'est une possibilité, mais c'est aussi un bon moyen de briser la compatibilité future entre différents systèmes de conteneurisation :-) Nous verrons si nous ne pouvons pas trouver mieux.

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/dotcloud/docker/issues/1916#issuecomment -26565782

@jpetazzo C'est vrai, mais je pense que docker aura besoin d'un moyen standard de remplacer la configuration des systèmes de conteneurisation sous-jacents si cela est autorisé - retour à la considération privilégiée de construction, je suppose!

@solomonstre Le fait est qu'il doit y avoir un moyen de permettre à docker build de construire en mode privilégié. Autoriser l'accès à /dev/loop* ne m'aidera pas dans mon cas d'utilisation particulier.

@solomonstre : la liste blanche /dev/loop est, à

Je comprends que certaines versions nécessiteront des périphériques de boucle, des montages et d'autres choses. Passons en revue nos options :

1. docker build -privileged
   Pratique, mais trace la ligne entre les « versions normales » et les « versions privilégiées ». S'il vous arrive d'avoir une image très utile qui nécessite un constructeur privilégié, il sera difficile de la construire sur des constructeurs publics. Par exemple, si quelqu'un démarre un service pour automatiser les builds, il n'offrira probablement pas de builds privilégiés (ou il devra utiliser des protections supplémentaires).
2. Détendez un peu les autorisations dans le constructeur
   Cela signifie (au moins) activer cap_sysadmin (cela me fait frissonner un peu paranoïaque), et peut-être donner un ou deux périphériques de boucle à chaque constructeur. Cela limiterait le nombre total de constructeurs fonctionnant en parallèle ; mais ce n'est pas grave puisque les builds sont censés être des processus rapides et, plus important encore, actifs. IE si vous avez 50 builds exécutés en parallèle, à moins que vous n'ayez une machine avec un sous-système d'E/S kickass, ces builds ne progresseront pas beaucoup.
3. Enveloppez le build dans une autre couche de virtualisation/isolation.
   Au lieu d'exécuter la construction directement dans Docker, exécutez quelque chose comme QEMU-in -Docker ou UML-in-Docker. C'est une solution intéressante du point de vue d'un développeur Docker, car cela ne signifie aucun travail supplémentaire ; c'est une mauvaise solution du point de vue de l'utilisateur de DOcker, car cela signifie faire face à une autre couche de complexité.

Je me demande si la bonne solution serait d'autoriser docker build -privileged`, et en même temps, de penser à des hooks qui permettraient une implémentation transparente de l'option 3. Supposons que je sois un "docker build provider": si quelqu'un demande une construction privilégiée, tout ce que j'ai à faire est d'insérer quelque chose quelque part pour exécuter leur processus de construction dans un environnement en bac à sable (QEMU et UML sont des candidats évidents, mais d'autres peuvent aussi fonctionner ; ce ne sont que des exemples pratiques).

Qu'en pensez-vous?

@backjlack , puis-je vous demander comment utilisez-vous ce conteneur une fois qu'il est construit ? Quoi
se produit lorsque vous "docker exécutez" exactement, quelle est l'application ? Seulement
essayer d'avoir une idée des cas d'utilisation pour cela.

Le ven. 18 oct. 2013 à 09:59, Jérôme Petazzoni
[email protected] a écrit :

@solomonstre https://github.com/solomonstre : liste blanche /dev/loop est,
À mon humble avis, un grand non-non, car avec la branche DM, cela donnerait lecture/écriture
accès à tout (puisque le comportement par défaut de la branche DM est d'utiliser
périphériques de boucle pour stocker les pools).

Je comprends que certaines versions nécessiteront des périphériques de boucle, des montages et d'autres
des choses. Passons en revue nos options :

1. docker build -privileged Pratique, mais trace la ligne entre
   « versions normales » et « versions privilégiées ». S'il vous arrive d'avoir un très
   image utile qui nécessite un constructeur privilégié, il sera difficile de
   construisez-le sur des constructeurs publics. Par exemple, si quelqu'un démarre un service pour automatiser
   builds, ils n'offriront probablement pas de builds privilégiés (ou ils auront
   d'utiliser des garanties supplémentaires).
2. Détendez un peu les autorisations dans le constructeur Cela signifie (au moins)
   activer cap_sysadmin (cela me fait frissonner un peu paranoïaque), et peut-être
   donner un ou deux dispositifs de boucle à chaque constructeur. Cela limiterait le total
   nombre de constructeurs fonctionnant en parallèle ; mais ce n'est pas grave puisque
   les builds sont censés être des processus rapides et, plus important encore, actifs.
   IE si vous avez 50 builds en parallèle, sauf si vous avez une machine
   avec un sous-système d'E/S kickass, ces builds ne progresseront pas beaucoup.
3. Enveloppez le build dans une autre couche de virtualisation/isolation.
   Au lieu d'exécuter la construction directement dans Docker, exécutez quelque chose comme
   QEMU-in-Docker, ou UML-in-Docker. Ceci est une solution intéressante d'un Docker
   du point de vue du développeur, car cela ne signifie aucun travail supplémentaire ; c'est un pauvre
   solution du point de vue de l'utilisateur de DOcker, puisqu'il s'agit de traiter
   une autre couche de complexité.

Je me demande si la bonne solution serait d'autoriser docker build-privileged`,
et en même temps, pensez à des crochets qui permettraient une transparence
implémentation de l'option 3. Supposons que je sois un "fournisseur de build docker": si
quelqu'un demande une version privilégiée, tout ce que j'ai à faire est d'insérer
quelque chose quelque part pour exécuter leur processus de construction dans un bac à sable
environnement (QEMU et UML sont des candidats évidents, mais d'autres pourraient fonctionner
trop; ce ne sont que des exemples pratiques).

Qu'en pensez-vous?

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -26612009
.

+1 - J'aimerais voir les capacités de mknode à installer des fusibles (pour monter des compartiments S3) ou la possibilité d'exécuter des exécutions privilégiées dans Dockerfiles. Vous ne savez pas encore quelle est la meilleure solution.

+1. des mises à jour sur ce problème?

+1
Le 17 novembre 2013 à 23h31, "yukw777" [email protected] a écrit :

+1. des mises à jour sur ce problème?

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -28676216
.

J'ai également rencontré le problème Fuse en essayant d'installer Java et je suis intéressé par une solution. J'ai essayé la solution de contournement suggérée ici https://gist.github.com/henrik-muehe/6155333 mais cela ne fonctionne pas pour moi sur docker sur le Raspberry Pi.

@jpetazzo : J'aime la stratégie globale de mise en œuvre de l'indicateur -privileged tout en explorant simultanément une solution à plus long terme. À cette fin, j'ai soumis une pull request pour implémenter cette fonctionnalité. Notez qu'à l'heure actuelle, il n'implémente pas la commande "RUNP" comme indiqué précédemment dans ce fil.

(Permettez-moi de "cross post" ceci, car les gens pourraient se retrouver ici à la recherche d'une solution de contournement)

Si vous n'utilisez pas réellement le fichier de périphérique (mais cela fait simplement partie d'un script post-installation comme dans le cas du package fuse), vous pouvez faire :

fakeroot apt-get ...

ou:

dpkg-divert --local --rename --add /sbin/mknod && ln -s /bin/true /sbin/mknod`

Je suis sûr que c'est bien intentionné, mais le tout premier commentaire/mon rapport incluait déjà deux solutions de contournement.
Pour être juste, vous en avez ajouté de nouveaux à la liste, mais le problème n'est pas "Impossible d'installer le fusible" et la lecture du premier message devrait aider les personnes qui ont juste besoin du package à installer quoi qu'il arrive.

Le vrai problème est « je dois appeler mknod » (ou plus générique : j'ai besoin d'opérations privilégiées qui échouent jusqu'à présent).

@jpetazzo Cela pourrait résoudre ce problème, non? https://lwn.net/Articles/564977/ - Jusque-là, j'opterais pour 3) car isoler l'accès aux périphériques _est_ une autre couche de complexité et il doit être géré quelque part.

Je ne suis pas non plus convaincu que le montage en boucle ou le fusible soit une caractéristique nécessaire. C'est fou de donner à un conteneur en cours d'utilisation des autorisations root pour monter un système de fichiers qui se trouve (fuse : implémentation en cours, boucle : fichier image) dans l'espace utilisateur.

Si vous avez besoin de monter une image de système de fichiers ou de fuse fs, vous pouvez la monter en dehors du conteneur et l'utiliser comme montage de volume/liaison. Bien que cela puisse être une fonctionnalité intéressante pour prendre en charge et gérer les systèmes de fichiers distants dans docker lui-même. Peut-être un dockerfile MOUNT/point-de-montage.

@discordianfish 3) est à peu près une non-solution.

#2979 aiderait-il à résoudre ce problème ?

J'attends une résolution pour cela aussi, mais pas à cause de mknod. Nous utilisons des conteneurs centos avec des rpms qui définissent des limites pour les utilisateurs utilisant /etc/security/limits.d/ et j'utilise actuellement une solution de contournement consistant en :

RUN /bin/sed --in-place -e "s/^\s\?session.*pam_limits.so.*/\#\0/g" /etc/pam.d/*

en haut de mon Dockerfile. (Nous ne faisons que du prototypage, ne vous inquiétez pas :) )

Salut @jpetazzo, j'ai essayé les deux options que vous avez suggérées. J'essaie de créer une image "oracle_xe" en utilisant

sudo docker build - privilégié -t oracle_xe parce que dans mon Dockerfile je veux exécuter ces 2 commandes

RUN mount -o remount, size=3G /dev/shm
RUN monter -a

Mais cela ne fonctionne pas, je ne sais pas si la syntaxe que j'ai utilisée est incorrecte, l'erreur que j'obtiens est
indicateur fourni mais non défini : -privileged

J'ai également essayé le deuxième choix d'utiliser RUNP mais cela n'a pas non plus fonctionné, lorsque je construis l'image, il saute cette étape en disant

Ignorer l'instruction inconnue RUNP. Je peux vous envoyer le Dockerfile que j'essaye de construire. Merci de m'aider à résoudre ce problème.

Merci.

Je pense que ni RUNP ni "build --privileged" n'ont été implémentés.
Si possible, n'hésitez pas à partager le Dockerfile ; ça peut être utile alors
nous pouvons vous donner la solution de contournement "la moins pire" :-)

Le mercredi 9 avril 2014 à 7h44, Manoj7 [email protected] a écrit :

Salut jpetazzo, j'ai essayé les deux options que vous avez suggérées. j'essaye de construire
une image "oracle_xe" utilisant

sudo docker build - privilégié -t oracle_xe parce que dans mon Dockerfile i
voulez exécuter ces 2 commandes

RUN mount -o remount, size=3G /dev/shm
RUN monter -a

Mais ça ne marche pas, je ne sais pas si la syntaxe que j'ai utilisée est
Incorrect. J'ai aussi essayé le deuxième choix pour utiliser RUNP mais cela n'a pas non plus
travail, quand je construis l'image, il saute cette étape en disant
Ignorer l'instruction inconnue RUNP. Je peux vous envoyer le Dockerfile que je suis
essayer de construire. Merci de m'aider à résoudre ce problème.

Merci.

Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/dotcloud/docker/issues/1916#issuecomment -39972199
.

@jpetazzo https://twitter.com/jpetazzo
Dernier article de blog :
http://jpetazzo.github.io/2014/03/23/lxc-attach-nsinit-nsenter-docker-0-9/

Salut @jpetazzo , j'aimerais faire un "RUN sudo umount /etc/hosts" dans mon Dockerfile - existe-t-il une solution de contournement "la moins pire" pour cela ? ;)

@jpetazzo

Le Dockerfile que j'ai utilisé pour créer l'image oracle_xe

À partir de *

MAINTIEN * * * * * * *

AJOUTER oracle-xe-11.2.0-1.0.x86_64.rpm.zip /appl/oracle/xe/oracle-xe-11.2.0-1.0.x86_64.rpm.zip
RUN mount -o remount, size=3G /dev/shm
RUN monter -a
Exécutez le cd /appl/oracle/xe && décompressez oracle-xe-11.2.0-1.0.x86_64.rpm.zip
Exécutez le cd /appl/oracle/xe/Disk1 && rpm -Uvh oracle-xe-11.2.0-1.0.x86_64.rpm
Exécutez le cd /appl/oracle/xe && rm oracle-xe-11.2.0-1.0.x86_64.rpm.zip
ENV ORACLE_HOME /u01/app/oracle/product/11.2.0/xe
ENV ORACLE_SID XE

La première chose que j'ai essayé était

sudo docker build -privileged -t oracle_xe .

Cela n'a pas fonctionné et j'ai ensuite essayé d'utiliser RUNP
RUNP mount -o remount, size=3G /dev/shm
Monture RUNP -a
cela n'a pas non plus fonctionné, ces deux étapes ont été ignorées.

@gatoravi : malheureusement, le démontage de /etc/hosts ne fonctionnera pas facilement. Pourquoi as-tu besoin de faire ça ? (Je comprends que vous puissiez avoir des raisons très valables, mais j'aimerais les entendre pour vous donner la meilleure solution de contournement...)

@Bhagat7 : d'accord ! Question : avez-vous besoin du plus gros /dev/shm au moment de l'exécution _et_ au moment de l'installation, ou uniquement au moment de l'exécution ? Si c'est au moment de la construction, quelle étape échoue et comment ?

@jpetazzo J'aimerais ajouter une nouvelle adresse IP à /etc/hosts dans le cadre du processus de construction de mon outil.
Quelque chose comme echo $IP $HOST >> /etc/hosts.

Je peux le faire très bien si j'utilise docker run --privileged puis fais un sudo umount \etc\hosts mais il semble que je ne puisse pas le commettre en utilisant docker commit donc je dois répéter le umount étape à chaque fois manuellement lorsque j'exécute un conteneur.

J'aimerais d'une manière ou d'une autre rendre \etc\hosts inscriptible et le rendre persistant, je n'arrive pas à trouver un moyen de le faire avec docker commit ou avec un Dockerfile.

@jpetazzo

j'ai eu ce problème

bash-4.1#/etc/init.d/oracle-xe configurer
Spécifiez le port HTTP qui sera utilisé pour Oracle Application Express [8080] :

Spécifiez un port qui sera utilisé pour l'écouteur de base de données [1521] : 1521

Spécifiez un mot de passe à utiliser pour les comptes de base de données. Notez que le même
le mot de passe sera utilisé pour SYS et SYSTEM. Oracle recommande l'utilisation de
des mots de passe différents pour chaque compte de base de données. Cela peut être fait après
configuration initiale :
Confirmez le mot de passe :

Voulez-vous qu'Oracle Database 11g Express Edition soit démarré au démarrage (y/n) [y]:y

Démarrage d'Oracle Net Listener... Terminé
Configuration de la base de données...Terminé
Démarrage de l'instance Oracle Database 11g Express Edition...Terminé
L'installation s'est terminée avec succès.
bash-4.1#cd /u01/app/oracle/product/11.2.0/xe/bin
base-4.1#sqlplus
Entrez le nom d'utilisateur : système
Entrez le mot de passe : * **
Mais j'obtiens cette erreur
ORA-01034 : ORACLE non disponible
ORA-27101 : le domaine de la mémoire partagée n'existe pas
Erreur Linux-x86_64 : 2 : aucun fichier ou répertoire de ce type
ID de processus : 0
ID de session : 0 Numéro de série : 0
df -h à l'intérieur du conteneur renvoyé
Taille du système de fichiers utilisée % d'utilisation disponible Monté sur
tmpfs 64M 0 64M 0% /dev/shm

Ainsi, lorsque j'ai augmenté la taille de tmpfs en 3G, je n'ai pas eu cette erreur. Je l'ai résolu en exécutant le conteneur en tant que
sudo docker run -privileged -i -t oracle_xe /bin/bash. J'ai exécuté les 2 commandes de montage à l'intérieur du conteneur. Mais je ne veux pas le faire de cette façon, je veux plutôt les mettre dans mon Dockerfile et le construire.

@gatoravi : OK, compris. Encore deux questions : avez-vous besoin de ces hôtes supplémentaires dans /etc/hosts pendant la construction, ou seulement pendant l'exécution ? Et pourquoi en avez-vous besoin ?

@ Bhagat7 : Désolé, je n'ai pas encore de solution élégante pour cela :-( Je suggérerais d'avoir deux Dockerfiles :

• un premier qui fait toutes les étapes (sauf celle qui nécessite le plus gros /dev/shm), et définit un CMD qui vérifiera si le conteneur s'exécute en mode privilégié, montera le plus gros /dev/shm et exécutera le spécial commander;
• un deuxième Dockerfile pour effectuer d'autres étapes (à moins que vous n'ayez également besoin de /dev/shm lors de l'exécution, vous avez besoin pour l'instant d'un élément privilégié).

@jpetazzo Nous aimerions fournir à nos utilisateurs une image (/container) avec un /etc/hosts/ modifiable afin qu'ils puissent créer notre code qui modifie ce fichier :) Quant à savoir pourquoi nous devons ajouter l'hôte, je ' Je ne suis pas vraiment sûr d'être honnête, nous le faisons dans le cadre de notre installation pour aider à pointer certains noms d'hôtes vers des adresses IP.

@ Bhagat7 J'ai pu faire fonctionner oracle XE dans un conteneur docker 0.9 en utilisant une combinaison de:

1. https://github.com/wnameless/docker-oracle-xe-11g
   et
2. sur l'hôte...

sysctl -w kernel.msgmni=4096
sysctl -w kernel.msgmax=65536
sysctl -w kernel.msgmnb=65536
sysctl -w fs.file-max=6815744
echo "fs.file-max = 7000000" > /etc/sysctl.d/30-docker.conf
service procps start

@mikewaters Merci beaucoup d'avoir répondu. Je pense que vous avez construit Oracle XE sur Ubuntu. Mais j'essaie de le construire sur Centos.

@jpetazzo Merci beaucoup pour votre suggestion

Salut les gars,

J'utilise google-chrome qui doit écrire sur /dev/shm qui semble être généralement 777 et est 755 ici. J'ai essayé d'ajouter une configuration spécifique à mon /etc/fstab mais je ne peux pas exécuter mout -a pour appliquer les modifications sur une version. Bien sûr, j'ai essayé le chmod ou le chown mais je ne peux pas le faire non plus.

Si j'utilise mes commandes lorsque je suis connecté en mode --privileged , tout va bien. Mais j'ai besoin, comme d'autres l'ont expliqué, de le faire sur build.

Toute suggestion?

Merci.

@tomav le problème d'autorisations "/dev/shm" est en fait #5126, qui a été corrigé dans #5131 et est déjà fusionné dans master (et le sera dans la prochaine version)

Merci @tianon.

aujourd'hui j'ai eu cette idée : je veux un conteneur gérant mes volumes de données. facile, mais comme je suis sur un vps, je veux que ces volumes soient chiffrés, mais fournis aux autres conteneurs comme d'habitude en clair. le fait est de n'avoir aucune donnée claire sur le disque virtuel et un moyen rapide de détruire en supprimant la clé.

J'ai suivi certaines des étapes magnifiquement documentées dans cet article sur la création d'un cryptfs pour y placer des conteneurs : https://launchbylunch.com/posts/2014/Jan/13/encrypting-docker-on-digitalocean/

notez que je n'essaye _pas_ de le faire, mais que j'ai en fait un conteneur avec un cryptfs monté :
donc un système de fichiers crypté doit être créé, monté, formaté lors de la construction via docker.

qui échoue :

• quand j'essaye de trouver un périphérique de boucle :

+ losetup -f
losetup: Could not find any loop device. Maybe this kernel does not know
       about the loop device? (If so, recompile or `modprobe loop'.)

• bizarrement, exactement le même dockerfile réussit _parfois_ à trouver un périphérique de boucle, puis :

+ losetup -f
+ LOOP_DEVICE=/dev/loop1
+ losetup /dev/loop1 /cryptfs/disk
+ cryptsetup luksFormat --batch-mode --key-file=/etc/cryptfs/random /dev/loop1
setpriority -18 failed: Permission denied
/dev/mapper/control: mknod failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

y a-t-il encore un moyen de contourner cela? (à part déplacer les étapes de montage/formatage du disque dans run )

+1 Ce serait particulièrement utile pour les environnements "docker in docker"

+1 à ce sujet, iptables ne fonctionne pas en mode non privilégié, ce qui fait échouer tout essai de configuration de règles de pare-feu.

@PerilousApricot : notez cependant que même si vous pouviez définir une règle iptables dans RUN , elle serait immédiatement perdue, car une image ne contient que l'état du système de fichiers. Il ne connaît pas les processus en cours, les routes réseau, les règles iptables, etc.

Cela me convient, car le conteneur n'aurait que des ports spécifiques
transmis, je ne suis pas concerné par le pare-feu, je veux surtout juste le
installateur pour pouvoir réussir à tous

André Melo

@PerilousApricot je vois ! Dans ce cas, qu'en est-il du lien symbolique entre iptables et /bin/true ? Cela devrait également faire plaisir à l'installateur. (Ou une astuce similaire pour tromper l'installateur ?)

J'ai essayé, mais le programme d'installation doit également analyser la sortie de
iptables, donc ce n'est pas si simple :)

OK, je sais que ça devient bidon, mais -- qu'en est-il de mettre un faux iptables place ? Lequel générerait une sortie fictive ?

Je comprends tout à fait que ce n'est pas génial; mais sérieusement, ce genre d'installateur devrait être corrigé en premier lieu :)

Le docker dans le cas d'utilisation de docker est ce qui m'a amené ici. Eh bien, docker dans lxc, pour être précis, car notre environnement de développement utilise lxc, et j'aimerais que les développeurs puissent construire les images dans le lxc.

J'aimerais aussi cela pour docker dans docker. Il y a une image qui doit être extraite avant que l'application puisse être exécutée, ce qui est plutôt volumineux, et je préférerais qu'elle soit extraite et mise en cache dans le cadre de docker build au lieu d'avoir besoin d'extraire et/ou de valider fréquemment conteneurs qui l'ont tiré.

Cette fonctionnalité est indispensable à mon humble avis, une combinaison de RUNP avec build-privileged serait géniale.

Le scénario réel/de production auquel je suis confronté est constitué d'images Docker créées avec le provisionnement de Puppet dans un conteneur intermédiaire. Sur certains services qui nécessitent des capacités élevées, il y a des échecs lors de la construction nécessitant que le conteneur soit exécuté sous -privileged avec un ENTRYPOINT ou CMD qui réapplique le script de la marionnette.

Cela retarde le temps de démarrage du service réel dans le conteneur car la configuration de la marionnette doit être construite puis appliquée pour garantir un état correct (et cela prend du temps), ainsi que le conteneur en cours d'exécution _pourrait_ ne pas avoir besoin d'être exécuté en réel -privileged Mode

J'espère que ce qui précède a du sens.

@jpetazzo J'essaie de créer un serveur Web sur centos6. Je suis bloqué dans la configuration des règles iptable via le fichier docker. C'est similaire au problème de

btw: je ne suis PAS pour la mise en œuvre des hacks tels qu'un faux iptables.

@pmoust : avez-vous des détails sur les opérations de build nécessitant des privilèges élevés ? Je recommanderai probablement d'esquiver le problème, et je me rends parfaitement compte que cela pourrait ne pas être satisfaisant pour vous ; mais néanmoins, je serais heureux de comprendre quel type d'installateur/constructeur pourrait avoir besoin de ces privilèges...

@passion4aix : notez que si vous définissez des règles iptables dans le Dockerfile, elles ne seront PAS enregistrées. Docker enregistre uniquement l'état du système de fichiers, pas les processus de routage/filtrage/exécution... Il existe des moyens de configurer des règles iptables avec des conteneurs "sidekick". Est-ce quelque chose qui pourrait être intéressant pour vous ?

@jpetazzo Le programme d'installation de Bitrock en est un exemple. Il faut que /tmp soit monté en tant que tmpfs. Vous voudrez peut-être jeter un œil à http://answers.bitrock.com/questions/3092/running-installer-inside-docker

@jpetazzo ou pratiquement n'importe quel programme d'installation d'openstack

Je viens également de rencontrer un problème similaire en essayant d'exécuter TokuMX dans un conteneur Docker, car TokuMX nécessite la désactivation de l'option de noyau 'transparent_hugepage'.

Y a-t-il des progrès sur cette question? Il a déjà plus d'un an et en regardant les commentaires, la plupart des gens l'ont utilisé pour exécuter des actions privilégiées à partir d'un Dockerfile.

Personnellement, je n'opterais pas pour la construction avec la solution '--privileged'. La solution RUNP est meilleure car vous ne pouvez alors exécuter que certaines actions en tant qu'utilisateur privilégié au lieu d'exécuter l'ensemble de l'installation en tant qu'utilisateur privilégié. De cette façon, au moins, vous devez penser à quand utiliser RUNP et ne l'utiliser qu'en cas de besoin.

Il me semble que la question n'est plus SI cette option doit être ajoutée, mais seulement quand c'est fait. Alors, quand peut-on s'attendre à cette fonctionnalité ?

@diversit Ils devraient être couplés. Donc, --privileged sur la ligne de commande permettrait d'utiliser RUNP , sinon ce serait un cauchemar de sécurité pour les gens qui construisent du code non fiable (y compris DockerHub).

Mais gardez également à l'esprit que vous pouvez le faire manuellement en dehors de la syntaxe Dockerfile. Le processus de construction lit le Dockerfile, crée un conteneur à partir de celui-ci et le remet dans une image.

@deas : Je pense que cela peut être résolu en faisant VOLUME /tmp .

@PerilousApricot : pouvez-vous développer un peu ? Je ne comprends pas pourquoi tout type d'installateur nécessiterait des privilèges spéciaux. (Ouais, je suis un vieux type Unix têtu, c'est un de mes défauts :D)

@diversit : pour ce cas spécifique, je pense que l'administrateur de la machine devrait désactiver les énormes pages transparentes avant la construction. Parce que si le constructeur est autorisé à faire cela, il le fera globalement (n'est-ce pas ?) et cela pourrait casser d'autres conteneurs qui pourraient nécessiter la fonctionnalité. Est-ce que tu vois ce que je veux dire? Ce serait mauvais si la construction du conteneur X interrompait l'exécution du conteneur Y...

Tout le monde : Je comprends tout à fait que c'est super frustrant quand un Dockerfile ne fonctionne pas, et tout ce dont vous avez besoin est ce drapeau --privileged / RUNP . Mais si nous commençons à avoir des builds privilégiés, cela va casser une tonne de trucs (par exemple des builds automatisés sur le Docker Hub !), c'est pourquoi nous nous sentons très mal à ce sujet. Et pour ce que ça vaut, je suis prêt à enquêter sur tous les scénarios nécessitant des versions privilégiées et à aider à les corriger :-) (Puisque c'est ma conviction personnelle que ces installateurs sont cassés !)

@jpetazzo Beaucoup/la plupart des outils de déploiement d'openstack (ex https://openstack.redhat.com/Main_Page) définissent les règles iptables. J'aimerais pouvoir lancer/déployer des versions conteneurisées de l'application, donc pouvoir créer un fichier docker et le faire en une seule fois est important pour moi. Je sais que les règles iptables ne sont pas conservées nativement via le processus de conteneurisation, mais elles sont conservées via iptables-save, donc une simple restauration iptables dans le processus CMD entraînera le rechargement des règles. Il est beaucoup plus compliqué de simplement "stub out" iptables, car de nombreux outils de déploiement utilisent des outils CI comme Puppet ou Chef pour effectuer le déploiement réel, vous devrez donc créer un stub compatible qui finirait par émuler tout les entrées/sorties de la "vraie" commande iptables.

De plus, je pense que c'est un compromis équitable de dire : "Si vous avez un fichier Docker qui nécessite des versions privilégiées, vous perdez les fonctionnalités X, Y, Z"

Oracle xe ne fonctionnera pas sans un espace mémoire partagé suffisant. Tous les comptes sont que remountimg tmpfs avec enuf espace rendent Oracle xe heureux de démarrer et de terminer sa configuration .. (pour ceux qui ont un aperçu, c'est l'étape '/etc/init.d/oracle-xe configure' qui se plaint des limitations de la mémoire cible selon les rumeurs, il serait possible d'augmenter la taille de la monture)

Lors d'une construction
RUN démonter tmpfs
échoue avec
umount : /proc/kcore : doit être un superutilisateur pour effectuer le démontage

donnez-moi RUNP ou donnez-moi la mort .... ou .... montrez-moi ce qui pourrait faire différemment :)

Mon exemple n'est pas valide ; @jpefazzo est toujours debout :) Mes paramètres Oracle causaient des problèmes et il ne semble pas nécessaire d'ajuster la taille de tmpfs... au moins pour l'installation initiale.

Je rencontre un problème iptables dans CentOS 7.0 qui n'est résolu que lorsque run ning avec --privileged https://github.com/docker/docker/issues/3416

Sans prise en charge de la construction privilégiée, je ne sais pas comment contourner le problème

Step 24 : RUN iptables -I INPUT -p tcp --dport 80 -j ACCEPT
 ---> Running in 74ebc19b6935
iptables v1.4.21: can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.

@buley Je crois qu'avec le security-opts ajouté dans #8299, il sera possible de le faire sans --privileged

@jpetazzo Je ne vois pas comment l'utilisation de VOLUME /tmp résout le problème des installateurs Bitrock. Cela peut fonctionner pour la construction, mais cela permettra également à /tmp contourner la superposition AUFS pour tous les conteneurs basés sur cette image, n'est-ce pas ? En fin de compte, il semble que la cause première devrait être corrigée dans AUFS.

Voici mon cas d'utilisation : je souhaite créer un environnement chroot dans un conteneur docker. Le problème est que debootstrap ne peut pas s'exécuter, car il ne peut pas monter proc dans le chroot :
W: Failure trying to run: chroot /var/chroot mount -t proc proc /proc
mount: permission denied
Si je run --privileged le conteneur, ça marche (bien sûr)...
J'aimerais vraiment vraiment très bien debootstrap le chroot dans le Dockerfile (beaucoup beaucoup plus propre). Existe-t-il un moyen de le faire fonctionner sans attendre RUNP ou build --privileged ?

Merci beaucoup!

+1 pour --privileged ou de montage. Besoin d'automatiser la construction de glusterfs

Cela a un impact sur mes efforts pour créer une image à partir du programme d'installation de Bitnami Tomcat. 99 % du processus d'installation s'exécute sans problème, mais lorsqu'il tente de démarrer Tomcat pour la première fois, cela échoue avec la sortie suivante dans catalina-daemon.out :

set_caps : échec de la définition des capacités
vérifiez que votre noyau prend en charge les capacités
set_caps(CAPS) a échoué pour l'utilisateur 'tomcat'
Sortie de service avec une valeur de retour de 4

Je peux exécuter avec succès le programme d'installation de Tomcat manuellement dans un conteneur que je crée avec "--cap-add ALL". Il semble étrange que je ne puisse pas utiliser 'docker build' pour créer une image que je peux créer manuellement en utilisant 'docker run' puis 'docker commit'. Les conteneurs utilisés pendant le processus de génération doivent avoir toutes les fonctionnalités des conteneurs que vous pouvez créer à l'aide de "docker run".

@gilbertpilz Ils ne peuvent très explicitement pas le faire afin d'assurer la portabilité et la sécurité de la construction.

@ cpuguy83 - Cela n'a aucun sens. Je peux construire l'image que je veux, à la main, si je fais :

docker run --cap-add ALL .... /bin/bash
bitnami-tomcatstack-7.0.56-0-linux-x64-installer.run ...
sortir
docker commit ....

Tout ce que je demande, c'est la possibilité d'utiliser "docker build" pour faire la même chose que je fais manuellement ici. Je ne vois pas comment « la portabilité et la sécurité » sont « assurées » si je peux créer l'image dans un sens mais pas dans l'autre.

Ok, laissez-moi vous donner un Dockerfile qui monte le fichier /etc/passwd de l'hôte dans le constructeur et qui me l'envoie.

Ce truc peut être dangereux.
Notez également que --privileged (et --cap-add ALL) donne à l'utilisateur dans le conteneur le contrôle total de l'hôte.

Autoriser ces choses compromettrait l'intégralité de DockerHub

@ cpuguy83 - Vous n'avez pas besoin de mettre le contrôle dans le Dockerfile. Vous pouvez ajouter l'option "--cap-add" (ou quelque chose de similaire) à la commande "docker build". Si nous suivons votre logique, les scripts shell ne devraient pas autoriser l'utilisation de la commande "sudo" car quelqu'un pourrait écrire un script qui ferait de mauvaises choses.

Mais vous ne donneriez pas sudo à quelqu'un en qui vous n'avez pas confiance avec les clés du royaume.
Build doit être capable, de la manière la plus sûre possible, d'exécuter du code non fiable.

L'introduction d'indicateurs CLI pour activer des fonctionnalités supplémentaires lors de la construction interrompt la portabilité de la construction, et c'est pourquoi elle n'est pas encore ajoutée.

Cela dit, l'installateur a presque certainement tort de demander des choses auxquelles il ne devrait pas avoir accès.

Exactement. Vous ne devriez pas donner à des personnes en qui vous n'avez pas confiance la possibilité d'exécuter des builds de docker qui nécessitent des privilèges, mais docker ne devrait pas empêcher les personnes en qui vous avez confiance de le faire. Il s'agit d'une décision politique et je n'aime vraiment pas que les outils prétendent prendre des décisions politiques à ma place. Un bon outil me permet de mettre en œuvre les décisions politiques que j'ai prises de manière claire et non surprenante.

Vous ne voyez pas la situation dans son ensemble.

Il y a plus dans cet écosystème que votre serveur et mon serveur. DockerHub, par exemple, crée tout le temps des versions de code non fiable.

Ensuite, DockerHub devrait certainement _pas_ permettre l'ajout de fonctionnalités pour ses versions. Si cela signifie que je ne peux pas pousser ma construction de docker vers DockerHub, ça me va.

@cpuguy83 @tianon @jpetazzo -- Quand le FUD démarre, je suis obligé de parler :

Autoriser ces choses compromettrait l'intégralité de DockerHub

vraiment?
Implémentation de cette fonctionnalité == TEOTWAWKI ?

Bien sûr, DockerHub n'exécuterait jamais docker build avec le drapeau --privileged demandé.
Sans trop y réfléchir, il existe au moins deux manières évidentes de le mettre en œuvre :

• flag ne fonctionne que si vous lancez également docker -d avec un nouveau drapeau tel que : --i-want-a-broken-security-model
• Créez un indicateur de compilation qui active le chemin du code.

Dans l'ensemble, le rapport entre les grincements de dents et les raisons techniques contre la mise en œuvre semble vraiment élevé ici.

@tamsky Et puis nous avons une situation où les builds fonctionnent à un endroit mais pas à un autre.
J'explique pourquoi les choses sont comme elles sont, sans argumenter sur un cas ou l'autre.

Mais aussi... la plupart des choses n'ont besoin d'aucune sorte d'accès privilégié, et ceux qui en ont besoin n'en ont généralement pas _vraiment_ besoin pour que l'installation fonctionne. Si l'installation de quelque chose échoue à cause de cela, ce programme d'installation est cassé, comme c'est le cas avec le problème de tomcat cité.
L'activation d'une telle fonctionnalité encouragerait les utilisateurs à s'exécuter en mode privilégié au lieu de résoudre le vrai problème.

@cpuguy83

Et puis nous avons une situation où les builds fonctionnent à un endroit mais pas à un autre.

S'il vous plaît, imaginez un instant que nous avons été transportés par magie dans un monde où la _politique_ est différente, et certaines versions fonctionnent à un endroit mais pas à un autre...

Pourquoi est-ce un gros problème ?
Qui s'en soucie exactement ?

Docker Inc a-t-il considéré que son mantra/exigence du plus petit dénominateur commun de « toutes les versions doivent fonctionner partout » pourrait en fait ignorer un besoin réel du client ?

La politique actuelle consiste à externaliser les coûts d'ingénierie pour les clients afin de « faire en sorte que X intègre le docker » :

Au lieu de fournir cette fonctionnalité dans docker, vous forcez tous les projets tiers dans le monde qui n'ont « pas besoin d'aucune sorte d'accès privilégié » (mais en fait) à d'abord être mis à jour ou mis à jour pour gérer le cas de construction de docker.

Finalement, si Docker doit s'exécuter sur plusieurs plates-formes, 'docker build' ne fonctionnera PAS de la même manière sur tous les systèmes. C'est-à-dire qu'une version d'un conteneur Windows, d'un conteneur Solaris ou même d'un conteneur ARM Linux ne sera pas la même que sur Linux x86-64. Le contexte de sécurité de ceux-ci sera également différent, en fonction de leurs plates-formes.

C'est-à-dire, @cpuguy83 , nous ne pouvons pas toujours présumer que Dockerfiles restera universel. Cependant, je suis d'accord que nous devons minimiser l'écart qu'il y a entre eux. Cela pourrait valoir la peine d'inclure la considération pour les utilisateurs qui souhaitent cette fonctionnalité, aussi dangereuse soit-elle, dans les conversations qui doivent finalement avoir lieu autour du support multi-arch / multi-plateforme.

Les versions ne fonctionnent pas partout car, par exemple, des profils d'armure d'application chargés.
De plus, comment feriez-vous avec des conteneurs Docker pré-cachés intégrés dans une image ?

Le 18. 11. 2014, à 2:53, tamsky [email protected] a écrit :

@cpuguy83

Et puis nous avons une situation où les builds fonctionnent à un endroit mais pas à un autre.

S'il vous plaît, imaginez un instant que nous avons été transportés par magie dans un monde où la politique est différente, et certaines versions fonctionnent à un endroit mais pas à un autre...

Pourquoi est-ce un gros problème ?
Qui s'en soucie exactement ?

Docker Inc a-t-il considéré que son mantra/exigence du plus petit dénominateur commun de « toutes les versions doivent fonctionner partout » pourrait en fait ignorer un besoin réel du client ?

La politique actuelle consiste à externaliser les coûts d'ingénierie pour les clients afin de « faire en sorte que X intègre le docker » :

Au lieu de fournir cette fonctionnalité dans docker, vous forcez tous les projets tiers dans le monde qui n'ont « pas besoin d'aucune sorte d'accès privilégié » (mais en fait) à d'abord être mis à jour ou mis à jour pour gérer le cas de construction de docker.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Ce n'est pas "le programme d'installation" qui est "cassé" dans cette situation, c'est Tomcat 7. J'utilise la pile Tomcat de Bitnami qui intègre Tomcat avec Apache et MySQL. Docker se trouve au bout d'une chaîne d'approvisionnement de services de source, de configuration, d'intégration, de test et de conditionnement. M'obliger à "réparer" Tomcat m'empêche de profiter de cette chaîne d'approvisionnement. Il est beaucoup plus facile de créer l'image que je veux à la main (démarrer un conteneur avec "--privileged", exécuter le programme d'installation, prendre un instantané du conteneur, etc.) que de "réparer" Tomcat.

+1
Je ne peux pas transférer mes rôles de chef vers docker car ils impliquent tous d'utiliser ufw pour ouvrir les ports.
l'ajout de --privileged to build résoudrait ce problème.

+1. Je ne peux pas avoir debootstrap comme étape dans mes Dockerfiles.

+1. Je ne peux pas avoir debootstrap comme étape dans mes Dockerfiles.

Il semblait naturel de construire mon chroot via un Dockerfile / build, mais s'est heurté aux mêmes problèmes que ceux mentionnés par

FROM ubuntu:utopic
ENV HOME /root
RUN sudo apt-get update
RUN sudo apt-get install -y eatmydata
RUN for i in /usr/bin/apt*; do sudo ln -s /usr/bin/eatmydata $(basename $i); done
RUN sudo apt-get install -y debootstrap qemu-user-static binfmt-support
RUN sudo debootstrap --foreign --arch arm64 trusty ubuntu-arm64-chroot
RUN ls ubuntu-arm64-chroot
RUN sudo cp /usr/bin/qemu-aarch64-static ubuntu-arm64-chroot/usr/bin
RUN sudo cp /etc/resolv.conf ubuntu-arm64-chroot/etc
RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log

échoue avec :

Step 11 : RUN sudo DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true LC_ALL=C LANGUAGE=C LANG=C chroot ubuntu-arm64-chroot /debootstrap/debootstrap --second-stage; sudo cat ubuntu-arm64-chroot/debootstrap/debootstrap.log
 ---> Running in 2654257e860a
I: Keyring file not available at /usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https mirror https://mirrors.kernel.org/debian
W: Failure trying to run:  mount -t proc proc /proc
W: See //debootstrap/debootstrap.log for details
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using DSA key ID 437D05B5
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key <[email protected]>"
gpgv: Signature made Thu May  8 14:20:33 2014 UTC using RSA key ID C0B21F32
gpgv: Good signature from "Ubuntu Archive Automatic Signing Key (2012) <[email protected]>"
mount: block device proc is write-protected, mounting read-only
mount: cannot mount block device proc read-only
 ---> de534a4e5458
Removing intermediate container 2654257e860a
Successfully built de534a4e5458

Qu'en est-il au lieu de RUNP , d'avoir un indicateur de construction --insecure .
Pour toutes les commandes RUN, le conteneur suivant serait exécuté avec --add-cap=all . Ceci au lieu de privilégié puisque privilégié fait aussi d'autres choses...
Mais cela pourrait vraiment changer pour implémenter les paramètres complets de privileged si nécessaire à un moment donné sans avoir à modifier le drapeau.

@cpuguy83
Cela ne me dérange pas d'avoir à utiliser un indicateur passé dans docker build qui permet aux commandes RUN d'être privilégiées ou aux commandes RUNP. Il est utile de pouvoir regarder un Dockerfile et dire par les commandes ou quelque chose à l'intérieur, qu'il nécessiterait un accès privilégié, et au moment de l'exécution au lieu d'aller à l'étape 10 et d'erreur, il aurait raccourci au début que le Dockerfile contient des commandes qui nécessitent des privilèges.

Le cas d'utilisation qui m'a amené à ce fil est les montages de liaison, que je veux pouvoir faire intracontainer. Pour le moment, vous ne pouvez les faire que si vous exécutez le conteneur en mode privilégié. Cela vous oblige à enchaîner les commandes au démarrage ou à avoir un script d'initialisation qui s'exécute pour terminer la configuration du système avant le processus que vous vouliez exécuter.

Ce serait bien de pouvoir avoir juste dans le Dockerfile :

RUN mount --bind /dir1 /dir2

Je décrirai davantage mon cas d'utilisation afin qu'il ne s'agisse pas simplement d'une large demande de commandes privilégiées. Mon cas particulier est que je souhaite lier le montage d'un répertoire dans la zone d'application à un volume de données qui a été attaché.

par exemple

/usr/local/application/data -> /mnt/data 
/mnt/data -> HOST:/var/datasets/dataset1

Cela pourrait être résolu en effectuant également le montage du volume directement dans la zone d'application, mais je cherche un moyen de les fournir dans un emplacement commun et de laisser le conteneur d'application effectuer son mappage spécifique. Cela pourrait également être résolu avec des liens symboliques, mais certaines applications ne fonctionnent pas bien avec des liens symboliques comme dossier cible/données. Et si l'application prend en charge la configuration de l'emplacement de son répertoire de données, cela peut également être fait pour pointer vers la zone de montage du volume. Mon cas d'utilisation, l'application ne prend pas en charge la configuration de l'emplacement du répertoire de données, et la réalité est qu'il y aura toujours des applications pour lesquelles vous devrez effectuer un montage de liaison ou un lien symbolique pour séparer correctement leurs données et leur espace d'application.

Cette capacité de faire cela A -> B -> C permet de garder les conteneurs de données génériques et offre une flexibilité dans les différentes combinaisons que vous pouvez réaliser avec --volumes-from avec les conteneurs d'applications et de données.

Vous pouvez également y parvenir en ayant une chaîne de conteneurs avec --volumes-from :

GenericDataContainer -> ApplicationDataContainer -> ApplicationContainer

Ce qui peut être la bonne réponse, mais vous pourriez éviter d'avoir à créer un autre conteneur pour les données d'application si le conteneur d'application pouvait exécuter un montage de liaison.

Je peux y parvenir aujourd'hui en exécutant le conteneur en mode privilégié, puis en exécutant la liaison de montage, mais comme vous le verrez ci-dessous, il n'y a aucun moyen de faire persister cette liaison de montage et elle doit être réinitialisée à chaque démarrage du conteneur. . Les liens symboliques sont persistants sur les commits.

La réponse pour mon cas d'utilisation particulier peut être d'utiliser l'approche de conteneur à 3 chaînes ou le script d'initialisation, mais avoir la possibilité de faire des montages de liaison intracontainer (ou d'autres commandes privilégiées) à partir du Dockerfile serait bien. Il existe probablement d'autres cas d'utilisation pour les montages de liaison qui pourraient être décrits et qui n'impliquent aucun mappage hôte-conteneur qui ne peut pas être résolu avec le chaînage des conteneurs de données.

Je ne sais pas si cela est lié ou plus à un problème spécifique au montage de liaison, mais le fait que les résultats des commandes privilégiées persistent lorsque vous effectuez un commit docker vous permettrait de séparer la construction de l'image docker et l'exécution de l'image docker. Vous pouvez contrôler la zone dans laquelle vous effectuez la construction de docker et les utilisateurs finaux n'obtiennent que le conteneur validé qu'ils peuvent exécuter en mode non privilégié. Ce n'est actuellement pas la cause lorsque vous exécutez un montage et une validation liés. Cela pourrait être plus lié au fonctionnement de /proc/mounts .

Voici un exemple simple

[root@ip-10-0-3-202 ~]# docker run --privileged -i -t --name test_priv centos:centos6 /bin/bash
[root<strong i="17">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Créez un exemple de montage de liaison, créez également un exemple de lien symbolique

[root<strong i="6">@d1d037cb170c</strong> /]# mkdir /var/data1
[root<strong i="7">@d1d037cb170c</strong> /]# mkdir /var/data2
[root<strong i="8">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2
[root<strong i="9">@d1d037cb170c</strong> /]# ln -s /var/data1 /var/data3

Afficher le fichier est vu dans les 3 répertoires

[root<strong i="13">@d1d037cb170c</strong> /]# touch /var/data1/test
[root<strong i="14">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="15">@d1d037cb170c</strong> /]# ls /var/data2
test
[root<strong i="16">@d1d037cb170c</strong> /]# ls /var/data3
test

Afficher /proc/mounts mis

[root<strong i="21">@d1d037cb170c</strong> /]# cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 /var/data2 ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0

Sortez du conteneur qui l'arrête, puis recommencez

[root<strong i="25">@d1d037cb170c</strong> /]# exit
[root@ip-10-0-3-202 ~]# docker start -a -i test_priv
test_priv

/proc/mounts manque le montage de liaison

[root<strong i="7">@d1d037cb170c</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-d1d037cb170c12dab94ebd01c56807210cf2aec50bef52c944f89225c8346827 / ext4 rw,seclabel,relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,seclabel,nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,seclabel,nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0

Le lien symbolique a survécu, mais pas le montage lié

[root<strong i="11">@d1d037cb170c</strong> /]# ls /var/data1
test
[root<strong i="12">@d1d037cb170c</strong> /]# ls /var/data2
[root<strong i="13">@d1d037cb170c</strong> /]# ls /var/data3
test
[root<strong i="14">@d1d037cb170c</strong> /]#

Monter la liaison de réinitialisation

[root<strong i="18">@d1d037cb170c</strong> /]# mount --bind /var/data1 /var/data2

Au lieu de quitter le conteneur, détachez avec ctrl+p ctrl+q puis validez le conteneur

Valider le conteneur en tant que nouvelle image, démarrer un nouveau conteneur à partir de l'image en mode non privé

[root@ip-10-0-3-202 ~]# docker commit test_priv test_priv
74305f12076a8a6a78f492fd5f5110b251a1d361e63dda2b167848f59e3799e2
[root@ip-10-0-3-202 ~]# docker run -i -t --name test_nonpriv test_priv /bin/bash

Vérifiez le /proc/mounts
le montage de liaison est manquant, je ne sais pas ce qui a déclenché les montages supplémentaires /proc/[sys,sysrq-trigger,irq,bus,kcore]

[root<strong i="5">@ba1ba4083763</strong> /]# cat /proc/mounts 
rootfs / rootfs rw 0 0
/dev/mapper/docker-202:1-25352538-ba1ba40837632c3900e4986b78d234aefbe678a5ad7e675dbab7d91a9a68469e / ext4 rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",relatime,discard,stripe=16,data=ordered 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0
shm /dev/shm tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime,size=65536k 0 0
devpts /dev/pts devpts rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
sysfs /sys sysfs ro,seclabel,nosuid,nodev,noexec,relatime 0 0
/dev/xvda1 /etc/resolv.conf xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hostname xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
/dev/xvda1 /etc/hosts xfs rw,seclabel,relatime,attr2,inode64,noquota 0 0
tmpfs /run/secrets tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,nodev,noexec,relatime 0 0
devpts /dev/console devpts rw,seclabel,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
proc /proc/sys proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/sysrq-trigger proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/irq proc ro,nosuid,nodev,noexec,relatime 0 0
proc /proc/bus proc ro,nosuid,nodev,noexec,relatime 0 0
tmpfs /proc/kcore tmpfs rw,context="system_u:object_r:svirt_sandbox_file_t:s0:c327,c505",nosuid,mode=755 0 0

Le lien symbolique a survécu

[root<strong i="9">@ba1ba4083763</strong> /]# ls /var/data1
test
[root<strong i="10">@ba1ba4083763</strong> /]# ls /var/data2
[root<strong i="11">@ba1ba4083763</strong> /]# ls /var/data3
test
[root<strong i="12">@ba1ba4083763</strong> /]# exit

J'essaie actuellement d'exécuter des images docker dans mon étape de construction, en utilisant dind . Donc, actuellement, il n'y a aucun moyen d'utiliser des images docker d'exécution dans votre build ?

Tout le monde, si vous le désirez, essayez '/usr/bin/unshare -f -m -u -i -n -p -U -r -- /path/to/binary'. Cela créera un conteneur à l'intérieur de votre build avec un espace de nom d'utilisateur. Vous pouvez modifier les options pour annuler le partage si nécessaire. En fait, je l'utilise pour exécuter '/sbin/capsh', afin de définir de manière granulaire les capacités de mes processus.

Je ne peux pas dire que cela résoudra tous les cas d'utilisateurs pour les versions privilégiées, mais cela devrait aider certains d'entre vous.

Je suis d'accord que cela devrait faire partie de Docker lui-même, et l'intégration des espaces de noms d'utilisateurs semble être en cours.

@saulshanabrook, vous ne pouvez pas exécuter d'images docker dans une version, pas exactement. J'espère qu'un jour prochain, ce sera possible. J'ai fait des recherches à ce sujet et j'ai découvert que vous pouvez effectuer un "docker pull" à partir d'une version, tant que vous utilisez le stockage VFS. De manière pratique, 'docker save' fonctionne également.

Ce n'est pas une vraie solution pour quelqu'un qui cherche à exécuter des images docker, mais je noterai que 'unshare' et 'capsh' fonctionnent, il est donc possible de faire un runtime de type conteneur dans des conteneurs non privilégiés (comme lors d'un build ). On peut soutenir qu'il est possible de contourner « docker run » et de faire cette étape manuellement, et de réengager les images dans docker. J'ai la plupart de ces travaux aujourd'hui, même si je n'ai pas tout emballé ensemble dans un arc. Finalement, bien sûr, une telle fonctionnalité doit être intégrée à Docker lui-même.

+1 pour docker pull via RUNP

L'impossibilité d'exécuter docker build privilégié favorise la construction manuelle avec un shell et un commit docker, ce qui rend Dockerfiles inutile. Je ne pense pas que l'ajout d'un indicateur privilégié à la construction de docker tracerait une ligne entre les versions et les versions privilégiées ; cette ligne était déjà tracée lorsque le drapeau a été ajouté pour s'exécuter et elle doit être prise en charge.

+1 Cela rend le conteneur docker reproductible à tout moment (il suffit de transporter le fichier docker seul)

+1 devoir complètement déchirer mes rôles de base ansibles juste pour contourner des choses comme celle-ci. J'espérais vraiment que l'adoption de docker me permettrait d'utiliser une grande partie de mon code ansible existant, mais non seulement j'ai déjà créé des rôles personnalisés pour la taille, mais je dois maintenant contourner des problèmes comme celui-ci.

@lsjommer sur quel genre de choses devez-vous travailler ? --privileged est un moyen totalement non sécurisé d'exécuter un conteneur et donne à l'utilisateur dans le conteneur un accès root complet à l'hôte.

Je ne dis pas qu'il ne faut pas mettre cela en œuvre, mais soyons réalistes sur ce dont nous parlons.

De plus, ce serait relativement facile à mettre en œuvre si quelqu'un veut y aller...

@ cpuguy83 C'est à partir de notre rôle de base standard "bare metal" que j'essaie d'adopter dans les conteneurs Docker pour installer toutes les bibliothèques, et il traite de la mémoire partagée mais peut-être que je n'ai même pas besoin de m'en soucier sur la construction du conteneur et n'avez-vous besoin de l'exécuter que sur l'hôte du conteneur ?
http://pastebin.com/P3QQxjNQ

J'admets que je ne comprends pas bien comment Docker gère le partage des ressources.

@ljsommer Donc, la configuration de shm est une bête différente et ne persisterait pas entre les commandes RUN (ou pour le moment où vous docker run ) de toute façon.

@ cpuguy83 Ouais, je pense que c'était principalement de ma faute en ce qui concerne le fait que j'ai rencontré ce que je pensais être un problème que je peux simplement déplacer sur la ligne de base pour l'hôte de conteneur lui-même.
Merci d'avoir pris le temps de répondre et excusez-moi de ne pas m'être correctement renseigné avant de vous plaindre.
;)

Une idée sur RUNP / -privileged pendant le processus de construction ?
Ce serait formidable de définir des tables IP pour limiter l'accès au docker aux adresses IP spécifiées

Je veux aussi RUNP et/ou "docker build --privileged".

FROM ubuntu:latest
MAINTAINER xyz

RUN apt-get -qq update
RUN apt-get -yq install iptables

RUN iptables -t nat -I OUTPUT -p tcp --dport 443 -j DNAT --to-destination 127.0.0.1:8080 && iptables-save > /etc/iptables.rules

Ce Dockerfile ne fonctionne pas en raison de l'erreur suivante, mais fonctionne avec "docker run --privileged"...

getsockopt failed strangely: Operation not permitted

@malcm , @sakurai-youhei : même si vous aviez quelque chose comme RUNP , cela ne fonctionnerait pas dans ce scénario, car les règles iptables ne sont pas persistantes dans le système de fichiers.

Laissez-moi vous expliquer : lorsque vous faites RUN x , Docker exécute x puis prend un instantané du système de fichiers. Les éléments extérieurs au système de fichiers (processus en cours d'exécution, tables de routage, règles iptables, paramètres sysctl...) ne sont pas stockés dans les images Docker.

Si vous voulez des règles iptables personnalisées, une méthode est :

• démarrez votre conteneur par exemple avec --name myapp
• démarrer un autre conteneur, privilégié, unique, pour configurer la règle iptables, par exemple docker run --net container:myapp --privileged iptablesimage iptables -t nat ...

Cela a-t-il du sens?

@jpetazzo : Merci pour votre réponse. Dans mon cas, j'ai mis la deuxième commande pour que la règle iptables persiste en tant que données sur le système de fichiers comme ci-dessous. Cela devrait me permettre de charger la règle iptables après avoir démarré le conteneur avec l'option --privileged.

RUN do-something-with-iptables && iptables-save > /etc/iptables.rules

Sans RUNP ni "build --privileged", je suis obligé d'écrire comme :

ADD iptables.rules /etc/

Oui, cela peut être suffisant, cependant, je dois ajouter iptables.rules à côté de Dockerfile dans mon référentiel.

C'est pourquoi je veux (ou voudrais avoir doucement) RUNP. :)

@jpetazzo @strib
Au-delà des problèmes d'iptables, des montages et d'autres opérations privilégiées, je pense qu'il y a un scénario de construction que nous devrions aborder.

Nous expédions des appliances pour un déploiement dans des machines virtuelles et une installation sans système d'exploitation. Cependant, pour les tests, nous utilisons des environnements de conteneurs. À leur tour, à l'intérieur de ces appareils, nous gérons des conteneurs. Les conteneurs de test doivent donc être basés sur docker-in-docker. Imaginez maintenant que nous ayons une image de service qui doit être pré-chargée dans l'image de test (afin que les images de service ne soient pas téléchargées à partir du registre au moment du test). Pour le moment, nous ne pouvons pas le faire car nous ne pouvons pas exécuter le conteneur d-in-d en mode privilégié lors de la construction du Dockerfile qui utilise d-in-d comme base : le démon docker ne démarre pas, "docker pull " ou " docker load " ne fonctionnera pas.

J'ai eu un problème où, lors de l'exécution sur un hôte RHEL7, su échouait si l'utilisateur actuel était root. Bizarrement, si l'utilisateur actuel était autre chose, su fonctionnait bien. Quoi qu'il en soit, la solution de contournement consistait à transmettre à la commande run le drapeau --add-cap=SYS_RESOURCE ; en raison de ce problème, cependant, il n'a pas été possible de le faire pendant l'étape de construction.

+1 Les scripts autour de Dockerfiles avec docker run et docker commit sont ridicules. Veuillez inclure cette fonctionnalité.

+1 sur la nécessité de cette fonctionnalité. Je pense qu'un "niveau de sécurité" global pourrait être configuré dans un fichier de configuration qui limite les capacités qui peuvent être données à un conteneur. Il devrait y avoir une valeur par défaut sûre (comme aujourd'hui) et un administrateur système pourrait la modifier pour permettre aux conteneurs de s'exécuter avec plus de privilèges. dockerfiles avec une telle instruction RUNP pourrait ne pas s'exécuter avec un message tel que "ce Dockerfile nécessite les capacités suivantes .... pour construire" sur un système qui a de telles limites globales.

Je pense que cela permet un équilibre entre la sécurité et la convivialité.

Nous avons également ce problème en essayant de créer une image avec une base de données propriétaire evli, qui restera sans nom, à l'intérieur.
La base de données veut allouer des quantités massives de mémoire, ce qui n'est pas autorisé par docker.

Notre solution de contournement actuelle est une construction en 2 phases avec une étape run --privileged et une étape de validation séparée.

Peut-être pourrions-nous configurer docker pour autoriser l'allocation de mémoire d'une autre manière. C'est un peu difficile de savoir ce que la base de données veut réellement faire parce que c'est propriétaire.

+1
pour cette fonctionnalité.
pour l'historique et l'exemple de cas d'utilisation, voir ce dupe
https://github.com/docker/docker/issues/12138#issuecomment -90536998
merci @ cpuguy83 d' avoir signalé le dupe

j'ai aussi ce problème, essayer de se connecter à un partage cifs pendant la construction de docker n'est pas autorisé à moins que le drapeau privilégié ne soit fourni, un moyen de contourner cela?

Il y a maintenant une pull request qui implémente cela ; vous pouvez vérifier les progrès là-bas ; https://github.com/docker/docker/issues/12261

Si quelque chose nécessite un mode privilégié, il est possible qu'il modifie l'hôte d'une manière ou d'une autre, ce qui signifie que l'image peut ne pas être portable car ces modifications devraient être exécutées sur d'autres hôtes essayant de consommer l'image.

Une fois que #13171 est fusionné, je pense que nous devrions fermer ceci car cela rendra trivial le lancement de votre propre constructeur et, en tant que tel, autorisera --privileged.
Je ne pense pas que le docker build intégré devrait permettre cela.

Donc @cpuguy83 , si je comprends bien, le moyen de docker build mais avec un paramètre supplémentaire ?

Je suppose qu'une fois l'autre patch mis en place, j'aurais besoin de créer ma propre version de docker build (peut-être docker pbuild ?) pour remplir les fonctionnalités supplémentaires ?

Y a-t-il des progrès sur cette question? J'ai vérifié les PR mentionnés ci-dessus et tous ont échoué.
Est-il possible de rendre une option BUILD --privileged/--granted plus granulaire et de limiter les accès accordés à un groupe spécifique de ressources hôtes uniquement au créateur/propriétaire de l'image ?

+1 pour toute solution qui me permet de faire RUN docker pull dans un Dockerfile.

Cas d'utilisation : j'ai besoin d'un ensemble d'outils pour la conversion d'images et la création de documentation, cependant, tous ces outils ne peuvent pas être installés dans une seule image en raison de bibliothèques conflictuelles. C'est pourquoi je sépare certains de ces outils dans une image séparée et j'aimerais répartir tous les outils dans une seule image, c'est-à-dire une image dans une image. C'est pourquoi je veux faire RUN docker pull dans mon Dockerfile.

@ cpuguy83, il ne semble pas que ce problème ait été résolu à la satisfaction de quiconque. J'ai absolument, à 100%, besoin de pouvoir faire quelque chose d'aussi ennuyeux que d'écrire sur /proc/sys/kernel/core_pattern pendant une construction.

Dans le monde actuel, je peux effectuer cette opération privilégiée via une solution run contournement Dockerfile j'ai produit _jamais_ n'est strictement reproductible, car ils proviennent de dépôts publics aléatoires en constante évolution. je n'avais aucune idée que

1. La consommation publique de mes images était une priorité.
2. Ils avaient besoin, jamais, d'être reproductibles.

Les gens vont faire des solutions de contournement merdiques pour obtenir privileged dans la construction. Je pense que vous devriez absolument aller là où se trouvent vos utilisateurs et autoriser cela dans l'outil de construction de base. Ajoutez un message terrifiant si nécessaire.

cc @thaJeztah , qui semble sympathique à cette position

Écoutez, j'ai créé un PR pour activer cela et il a été rejeté.
Je ne vois pas cela se produire avec le constructeur sous quelque forme que ce soit.

On dirait que vous avez fait le dernier appel. Je vais m'agiter dans le fil de relations publiques lui-même, alors.

Ceci est nécessaire pour installer les anciens packages JDK 1.6 sous CentOS car sa tentative d'enregistrement de RPM est binmft_misc qui échoue sans s'exécuter sous --privileged.

Dockerbuild est un non-étatique pour construire des conteneurs avec.

A reproduire

DE Centos5.11
RUN miam intall -y jre-1.6.0_29-fcs

Nous devons avoir une partie de commande privilégiée de build comme indicateur facultatif. J'essaie de porter l'une de nos applications sur docker en tant que POC et cela échoue pour l'un de nos composants car il a des paramètres IPtables qui ne sont pas appliqués et la construction échoue. Je peux faire les modifications nécessaires manuellement et les valider, mais alors quel est le plaisir de construire docker. Ce n'est qu'une partie de la construction et devrait être facile à porter car il fait déjà partie de la version principale.

Docker devrait pouvoir facilement exécuter des conteneurs intermédiaires avec un ensemble d'options privilégiées.

@shubhamrajvanshi nous sommes en train de déplacer le « constructeur » hors du démon (et vers le client), cela devrait ouvrir la porte à davantage de personnalisations du processus de génération (y compris la possibilité d'implémenter des générateurs personnalisés). Permettre éventuellement des builds "privilégiés" peut être envisagé, mais c'est une décision qui peut être prise après la refactorisation. (Voir https://github.com/docker/docker/blob/master/ROADMAP.md#122-builder)

@shubhamrajvanshi, vous ne pouvez pas modifier iptables dans la construction pour une bonne raison, les paramètres ne colleront jamais.

Il y a très peu de choses que l'on puisse faire avec --privileged qui ait même du sens dans build.

@thaJeztah Merci, ce serait utile.
@ cpuguy83 Serait-ce le cas même si j'utilise le package iptables-persistent sur l'image.

Cela enregistrerait les règles sur le disque, puis elles devraient encore être rechargées, malheureusement.

_SONDAGE UTILISATEUR_

_La meilleure façon d'être averti lorsqu'il y a des changements dans cette discussion est de cliquer sur le bouton S'abonner en haut à droite._

Les personnes énumérées ci-dessous ont apprécié votre discussion significative avec un +1 aléatoire :

@karelstriegel

J'aimerais vraiment cela aussi, pour permettre l'utilisation des pilotes CUDA de nVidia à partir de Docker sur CoreOS. Le programme d'installation qu'ils fournissent construit un module de noyau par rapport à la source du noyau, puis l'installe à l'aide de modprobe. Je ne vois pas comment le faire fonctionner sans une sorte d'option --privileged à construire.

Pourquoi ne pas toujours prendre en charge par défaut le mode privilégié lors de la construction ?

+1
Je souhaite utiliser la commande mysql dans Dockerfile pour centos7.
Bien sûr, nous pouvons utiliser entrypoint.sh mais c'est plus utile si nous pouvons utiliser -privileged pour la construction et l'exécution.

Il n'y a pas besoin de --privileged pour exécuter la commande MySQL.

Ce problème devrait être clos car il ne semble pas que cela va se produire (ou même devrait se produire).
Autoriser les privilèges dans la construction signifie permettre au constructeur de changer des choses sur l'hôte, ce qui fait que l'image ne fonctionne que sur cet hôte (ou sur des hôtes qui ont subi des modifications similaires).

Autoriser les privilèges dans la construction signifie permettre au constructeur de changer des choses sur l'hôte, ce qui fait que l'image ne fonctionne que sur cet hôte (ou sur des hôtes qui ont subi des modifications similaires).

Cela s'applique-t-il au cas de l'utilisateur chroot ?

J'essaie de comprendre comment faire dpkg-depcheck -d ./configure sans quelque chose comme ça.

Pendant la construction (ou l'exécution sans --priviledged), j'obtiens l'erreur ci-dessous - je ne sais pas comment déterminer l'autorisation dont il a besoin ou comment l'activer.

dpkg-depcheck -d ./configure
strace: test_ptrace_setoptions_followfork: PTRACE_TRACEME doesn't work: Permission denied
strace: test_ptrace_setoptions_followfork: unexpected exit status 1
Running strace failed (command line:
strace -e trace=open,execve -f -q -o /tmp/depchJNii2o ./configure
devel<strong i="8">@98013910108c</strong>:~/src/cairo-1.14.2$ 

Après environ 3 ans et 162 commentaires, je pense que ça a assez d'intérêt à faire. Les commentaires selon lesquels un mode privilégié n'est pas nécessaire pour la plupart des cas cités sont vrais, même les miens ; mais ne doit pas être utilisé pour proscrire ce qui pourrait être utile pour des constructions locales, temporaires, exploratoires et/ou opportunes. Publiez des avertissements jusqu'à ce que les vaches pètent une harmonie, imprimez des avertissements en ligne de commande, insultez et dénoncez son utilisation, mais donnez de la flexibilité aux gens. La portabilité n'est pas toujours l'intérêt premier de tout le monde.

_SONDAGE UTILISATEUR_

_La meilleure façon d'être informé des mises à jour est d'utiliser le bouton _S'abonner_ sur cette page._

Veuillez ne pas utiliser de commentaires « +1 » ou « J'ai ça aussi » sur les problèmes. Nous automatiquement
recueillir ces commentaires pour garder le fil court.

Les personnes répertoriées ci-dessous ont voté pour ce problème en laissant un commentaire +1 :

@robeferre

+1

J'ai vraiment besoin de monter un volume NFS dans un conteneur Docker, jusqu'à présent je ne pouvais pas créer le partage NFS sans l'indicateur "--privileged=true". Le meilleur des cas à mon avis est de construire l'image à l'aide de la commande privilégiée. Comment est-ce possible?

+1

Step 19 : RUN lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root
 ---> Running in 4c51b7cf0058
lxc_container: lxccontainer.c: create_run_template: 893 error unsharing mounts
lxc_container: lxccontainer.c: create_run_template: 1084 container creation template for percise failed
lxc_container: lxc_create.c: main: 274 Error creating container percise
The command '/bin/sh -c lxc-create -t ubuntu.sf -n percise -- -r precise -a i386 -b root' returned a non-zero code: 1

J'essaie d'installer gobject-introspection dans le système gentoo dans docker pendant la construction mais cela échoue avec cette erreur :

• ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Opération non autorisée

Le même résultat lorsque j'essaie de l'installer manuellement dans un conteneur, mais lorsque je l'essaye à partir d'un conteneur lancé en mode privilégié (docker run --privileged), cela fonctionne bien.

Le même problème lorsque j'essaie d'installer la glibc.

J'ai donc également besoin d'un moyen d'exécuter une commande privilégiée pendant la construction.

J'utilise docker version 1.10.1 et le problème avec la glibc n'apparaît pas dans 1.9

Dans la version 1.10, quelque chose est cassé et nous ne pouvons pas créer de conteneurs 32 bits, car la mise en réseau n'est pas disponible
--privileged ou --security-opt seccomp:unconfined for BUILD - est vraiment nécessaire.
Ou les directives correspondantes dans Dockerfile

gros +1 de moi

C'est un vrai problème pour moi que je ne puisse pas utiliser la commande 'mount' pendant la construction.
J'essayais de surmonter la limitation selon laquelle un répertoire hôte ne peut pas être monté dans un conteneur pendant la construction, j'ai donc configuré un serveur NFS sur l'hôte et essayé de monter un partage NFS, juste pour découvrir que ce n'est pas possible à cause du mode non privilégié.

Dans mon cas d'utilisation, je dois installer des éléments dans l'image sans les copier dans le contexte de construction et les AJOUTER avant de l'installer.

J'ai l'impression de me retrouver sans options.

thaJeztah a fait référence à ce problème le 10 mars
Régression du comportement LTTng après la mise à niveau vers 1.10.2 #20818 Fermé

Non, ce n'est pas fermé, nous utilisons 1.11.0-0~wily et dans les conteneurs 32 bits, le réseau ne fonctionne pas depuis 1.10.0, mais 1.9.x a bien fonctionné.
Seul -privileged peut nous aider à démarrer des conteneurs. Mais on ne peut pas construire de nouveau

Je suis étonné que quelque chose de si manifestement nécessaire à tant de personnes n'ait pas été mis en œuvre, même si les gens le suppliaient depuis 2,5 ans dans ce seul fil et étant donné que les gens ont soumis des PR pour mettre en œuvre cette fonctionnalité.

D'accord @ctindel , ce problème est l'une des raisons pour lesquelles je migre de docker vers rkt .

@ctindel C'est quelque chose que nous ne sommes pas prêts à mettre en œuvre ou à prendre en charge. L'implémentation en elle-même est assez simple (je l'ai même implémentée moi-même pour que nous puissions en discuter), là n'est pas le problème.

--privileged est un tank, et l'autoriser lors de la construction est dangereux et affecte grandement la portabilité des images.

Brian,

Si vous avez un travail autour, pouvez-vous s'il vous plaît le partager avec moi aussi. J'aimerais
J'apprécie cela.

Merci
Shubham Rajvanshi
669-300-8346

Le lundi 2 mai 2016 à 14h30, Brian Goff [email protected] a écrit :

@ctindel https://github.com/ctindel C'est quelque chose que nous ne sommes pas prêts à faire
mettre en œuvre ou soutenir. La mise en oeuvre en elle-même est assez simple (j'ai même
mis en œuvre moi-même pour que nous puissions en discuter), ce n'est pas le problème.

--privileged est un tank, et le laisser en construction est dangereux, et
affecte grandement la portabilité des images.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/docker/docker/issues/1916#issuecomment -216369957

Je ne comprends pas l'effet sur la portabilité. Comment les opérations privilégiées au moment de la construction affectent-elles la portabilité ? Je veux dire, il n'est pas difficile de créer des images non portables de différentes manières avec ou sans privilège, mais existe-t-il un moyen pour que les images construites avec des opérations privilégiées soient nécessairement non portables ?

Je ne pense pas que chaque conteneur doive être portable. Certains conteneurs sont créés pour être partagés avec la communauté et d'autres peuvent être créés pour déployer des applications internes.

Le problème de portabilité avec une application qui nécessite une exécution en mode privilégié réside dans l'application elle-même.

Le mode privilégié est le moyen de dernier recours pour que l'application fonctionne sans modifications de code.

Je pense qu'un créateur d'images qui nécessite une création en mode privilégié comprend qu'un tel conteneur peut également nécessiter une exécution en mode privilégié.

Il doit être clairement documenté que la construction en mode privilégié est déconseillée car cela pourrait créer des problèmes de portabilité.

Envoyé depuis Outlook Mobilehttps://aka.ms/blhgte

Le lundi 2 mai 2016 à 14h53 -0700, "Trevor Blackwell" < [email protected] [email protected] > a écrit :

Je ne comprends pas l'effet sur la portabilité. Comment les opérations privilégiées au moment de la construction affectent-elles la portabilité ? Je veux dire, il n'est pas difficile de créer des images non portables de différentes manières avec ou sans privilège, mais existe-t-il un moyen pour que les images construites avec des opérations privilégiées soient nécessairement non portables ?

Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/docker/docker/issues/1916#issuecomment -216375159

@tlbtlbtlb Parce que le mode privilégié vous donne un accès complet à l'hôte. Peut-être que j'ai mis quelque chose de simple comme shmmax ou quelque chose de bien pire.
Je garantis que ces choses se produiront le premier jour où cela sera disponible.

@davidl-zend "portable" ne veut pas dire partager avec la communauté. Cela signifie passer d'une machine à une autre.

@ cpuguy83 Comme d'autres l'ont souligné, il existe également de nombreuses autres façons de casser la portabilité des images. Tout ce que vous faites en n'ayant pas de processus pour la construction privilégiée, c'est de forcer les gens à avoir un processus en deux étapes, soit en construisant partiellement à partir d'un Dockerfile, puis en modifiant manuellement le conteneur et en effectuant une validation, soit en construisant partiellement à partir d'un Dockerfile et en terminant l'installation privilégiée la première fois que le conteneur est lancé, ce qui est nul car cela signifie que si vous faites quelque chose qui prend du temps, le premier démarrage peut prendre quelques minutes.

Compte tenu des commentaires que j'ai vus sur divers forums, je suis prêt à parier que BEAUCOUP de gens font déjà exactement cela pour contourner la limitation du docker qui existe aujourd'hui.

Une fois que vous avez une architecture où la portabilité des images est brisée de dizaines d'autres manières, à quoi bon s'incliner contre ce moulin à vent spécifique ?

De toute évidence, vous ne pourrez plus faire en sorte que docker hub ou travis-ci construise votre image, mais les personnes qui en ont besoin en mode privilège le comprendraient de toute façon.

@ctindel J'aimerais voir des exemples de portabilité d'image cassée

Faire ce genre de choses au premier démarrage du conteneur est _exactement_ la bonne voie à suivre.
C'est une configuration d'exécution qui ne devrait pas être dans l'image.

@ cpuguy83 Êtes-vous en

Je n'essaie pas d'être irritable, je dis juste qu'il s'agit d'une limitation sévère de la plate-forme sur laquelle les gens travaillent de manière maladroite.

Par exemple, il existe des paquets Debian tiers (et probablement des RPM) qui ne peuvent pas être installés correctement à moins que vous n'ayez certaines capacités dans le système. L'installation d'un paquet Debian n'est pas une "configuration d'exécution", c'est une partie effrayante du processus d'installation.

@ctindel Je ne discute pas du tout de cela. La différence est de soutenir le comportement. S'il n'y avait pas de différence, nous n'aurions pas cette discussion.

Pour moi, je suis un adulte consentant et je veux pouvoir faire rouler une image packstack sur un tas de nœuds. Construire avec des bombes Dockerfile actuellement, je dois donc tricher pour contourner les restrictions de docker.

@ cpuguy83 Il n'est toujours pas clair pour moi (et je pense que d'autres dans ce fil de discussion) ce que l'on gagne exactement en ne fournissant pas cette option que les gens contournent d'une autre manière. Le genre de pureté architecturale (je n'ai pas de meilleur mot pour cela) pour lequel vous semblez plaider a disparu à la minute où l'option de validation a été ajoutée de toute façon, donc je ne comprends vraiment pas quelle différence il y a si cela est fait via un Dockerfile avec build privilégié ou via un commit docker dans un conteneur privilégié.

Sauf qu'une voie est un PITA flippant pour les gens et qu'une voie s'intègre très bien dans le mécanisme actuel de construction avec Dockerfile.

De plus, vous n'avez pas répondu à ma question. Pourquoi considérez-vous la simple installation d'un paquet Debian tiers (ou packstack) comme une « configuration d'exécution » ?

@ctindel Portabilité. Ce n'est pas parce que quelque chose peut être fait qu'il est pris en charge, et l'inclure dans build , ce qui le rend pratique pour tout le monde, cela signifie qu'il est pris en charge.
Nous _serions_ inondés de problèmes d'images qui ne fonctionnent pas entre les hôtes... ce qui va à l'encontre de la raison d'être de Docker.

Si un package nécessite même --privileged pour être installé, il doit être adressé avec le package. L'installation ne devrait pas nécessiter --privileged ... et si cela l'exige vraiment, alors c'est un signe que l'installation elle-même n'est pas portable (nécessite de changer les choses sur l'hôte)... J'aimerais même voir docker être exécutable dans un conteneur sans --privileged (notez que c'est exécutable, vous pouvez l'installer tout ce que vous voulez sans problème sans --privileged).

Mais permettre que cela soit fait via docker commit signifie qu'il est également pris en charge!

Je ne comprends pas, vous obligez des tonnes de personnes à contourner les limitations de ce produit parce que vous craignez que quelqu'un se plaigne personnellement d'une sorte d'image non prise en charge ?

Vous n'avez toujours pas répondu à ma question sur la raison pour laquelle l'acte d'installer un package (je ne parle même pas de le configurer ici) est un acte de "configuration d'exécution". Dire simplement "portabilité" ne veut rien dire.

Y a-t-il quelque chose de spécifique à x86_64 à propos de docker ? N'y aura-t-il pas éventuellement des images Docker conçues pour une architecture de processeur spécifique ? Cela ne les rend-il pas également non portables ? Je veux dire toute cette idée que d'une manière ou d'une autre, vous pourrez toujours prendre n'importe quelle image docker et l'exécuter sur n'importe quel hôte docker dans le monde, indépendamment des tonnes d'autres variables, semble de toute façon impossible, donc je ne comprends pas le besoin très fort de pousser revenir sur cette caractéristique particulière que les gens demandent.

BTW, permettez-moi de vous remercier ici pour vos réponses et votre engagement continu. Beaucoup d'autres projets github où les threads de problèmes sont ignorés !

Je suis d'accord avec le fait que les gens travaillent autour de cela en utilisant docker run --privileged avec docker commit . J'ai fait une solution comme ça pour deux entreprises jusqu'à présent. Les gens FERONT des images comme ça et il ne sert à rien d'agir comme si c'était quelque chose d'horrible, d'horrible.

Bon sang, si vous avez tellement peur de prendre en charge des conteneurs qui ont été construits avec --privileged alors indiquez-le clairement dans la documentation afin que les gens sachent parfaitement qu'ils le font à leurs risques et périls. Bien que je n'aie pas vu d'effets négatifs jusqu'à présent. Mais là encore, nous n'avons pas essayé d'exécuter des conteneurs sur différentes distributions.

@PerilousApricot, qu'est-ce qui cause réellement le problème avec packstack ? Nous sommes heureux de résoudre des problèmes spécifiques ou d'aider à les résoudre en amont, mais ne pensez pas qu'ajouter simplement --privileged qui donne un accès root complet et sans entrave à votre serveur hôte est la bonne façon de le faire. Tous les cas que je connais où les gens ont soulevé des problèmes de construction spécifiques peuvent généralement être résolus, car la plupart des choses n'ont en fait pas besoin d'un accès root sur la machine hôte pour faire une construction.

@justincormack Quelle est la solution pour un package tiers (c'est-à-dire qui ne peut pas être modifié) qui démarre son propre service où le script d'initialisation doit monter un système de fichiers tmpfs ? Je veux dire même en ignorant --privileged pour l'instant, il n'y a également aucun moyen de faire un --cap-add ou un --security-opt apparmor:unconfined lors d'une construction (je ne pense pas?)

@ctindel Il ne devrait pas essayer de monter un tmpfs lors de l'installation. S'il a besoin de tmpfs au moment de l'exécution, c'est parfait, mais au moment de l'installation, ce n'est certainement pas correct.

@ cpuguy83 Vous

C'est le but de toute cette discussion, vous imposez des restrictions arbitraires qui rendent beaucoup plus difficile l'utilisation de docker en raison d'une préoccupation philosophique concernant les demandes de soutien de personnes qui "le font mal".

C'est comme dire que les systèmes d'exploitation ne devraient pas permettre aux gens de modifier les classes de planification des processus, car si vous le faites mal, cela peut entraîner une inversion de priorité. Ou que personne ne devrait fabriquer un marteau car il est possible de frapper votre pouce si vous l'utilisez mal.

Comme cela a été dit à plusieurs reprises, docker SUPPORTE DÉJÀ CELA via la commande commit, c'est juste plus douloureux pour vos utilisateurs. Les personnes qui ne veulent pas de cette fonctionnalité ne l'utiliseront pas, et les adultes consentants qui souhaitent l'utiliser en comprenant les limites peuvent le faire les yeux grands ouverts.

@ctindel Plutôt non, vous ne pouvez pas gérer cette bombe nucléaire car vous pourriez tuer tout le monde dans un rayon de 50 km.

De quoi a-t-il besoin dans ce paquet pour charger un tmpfs lors de l'installation ? L'installation extrait littéralement les fichiers d'un format d'archive vers le rootfs.

Tout peut être modifié.
C'est une modification beaucoup plus simple et plus sûre à faire en amont pour ne pas monter un tmpfs lors de l'installation que pour activer les privilèges lors de la construction.

Docker concerne la portabilité de la charge de travail. L'activation des privilèges lors de la construction (ou des privilèges supplémentaires, ou la modification des profils de sécurité, etc.) casse fondamentalement cela et n'est pas quelque chose que nous pouvons accepter aujourd'hui.

commit et build sont deux choses très différentes.

FROM python

ENV PACKSTACK_VERSION 7.0.1
RUN cd /opt && git clone https://github.com/openstack/packstack.git \
  && cd packstack \
  && git checkout $PACKSTACK_VERSION \
  && rm -rf .git \
  && python setup.py install

Aucun privilège requis.

L'église de la rentabilité.
Un jour, la portabilité "forcée" tuera ce projet - il le fait déjà.
Tant de fonctionnalités sont refusées à cause d'une portabilité insaisissable, tant de progrès ne sont pas réalisés à cause de cela .....
Un jour, quelqu'un créera un projet et rendra la portabilité facultative. Rêves... rêves.... Amen.

Si nous le décomposons en deux cas :

1. Les installateurs qui utilisent des opérations privilégiées de manière frivole, comme le montage de tmpfs pour les performances. De tels installateurs pourraient facilement être corrigés (mais peut-être pas dans un avenir proche).

Dans ce cas, c'est une philosophie valable pour Docker de repousser les installateurs mal comportés. La plupart des installateurs ont une sorte de solution de contournement qui allonge un peu le Dockerfile.

1. Des programmes d'installation qui dépendent fondamentalement d'opérations privilégiées, comme l'installation de modules de noyau pour les pilotes GPU. Ceux-ci sont également fondamentalement non portables. Ils ne fonctionneront pas sur docker-machine pour Mac, par exemple.

Dans ce cas, l'expérience Docker est de toute façon interrompue. Je ne peux pas utiliser docker-machine sur Mac, par exemple, je ne peux créer l'image que sur une machine hôte cible compatible. Mon cas d'utilisation consistait à installer les pilotes GPU nVidia sur un système d'exploitation hôte (CoreOS), ce qui décourageait l'installation directe dans le système d'exploitation hôte.

Donc, je suppose que j'en suis venu à voir l'intérêt de ne pas soutenir --privilégié dans les deux cas. Je pense que ce qui m'a fait changer d'avis, c'est la commodité de créer des images sur mon ordinateur portable à l'aide de docker-machine, plutôt que de pousser d'abord mon code dans une boîte Ubuntu et de le construire là-bas.

@tlbtlbtlb Je ne comprends pas à quelle "vertu" vous faites référence. Considérez quelque chose qui n'est pas frivole, mais il y a des tonnes d'images docker qui s'exécuteront dans un environnement mais pas dans un autre. Par exemple, vous pouvez monter un volume hôte dans un conteneur mongodb allant de linux->linux car et le pilote de stockage mmapv1 fonctionnera correctement, mais vous ne pouvez pas transmettre un répertoire mac osx via virtualbox à un conteneur mongodb sur votre ordinateur portable car le Les trucs mmap ne fonctionneront pas correctement dans ce cas.

Je me rends compte que ce n'est pas un problème en ce qui concerne la construction, mais l'idée que les images docker sont "portables" et peuvent "s'exécuter n'importe où" est un non-sens total à ce stade. S'il est vrai qu'ils ne peuvent courir nulle part, quel est l'intérêt de dire qu'ils devraient pouvoir « construire n'importe où » ?

Le fait est que l'image mongodb fonctionne partout. Fournir une configuration d'exécution invalide est une bête différente.

Docker a une séparation très spécifique et intestinale de la configuration portable et de la configuration non portable.

Que dis-tu de ça ?
J'ai besoin d'avoir mon ips réel à l'intérieur du conteneur pour ma passe de vérification de configuration nginx.

c'est mon Dockerfile :

FROM ubuntu:14.04.4

RUN apt-get update
RUN apt-get install -y software-properties-common
RUN add-apt-repository ppa:nginx/stable
RUN apt-get update
RUN apt-get install -y nginx-full vim
RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
RUN ifconfig lo:1 192.168.168.57 netmask 255.255.255.0 up
RUN ifconfig lo:2 192.168.168.58 netmask 255.255.255.0 up

ADD . /etc/nginx

➜  nginx git:(ha-node-01) ✗ docker build -t nginx4test .
Sending build context to Docker daemon 976.4 kB
Step 1 : FROM ubuntu:14.04.4
 ---> 90d5884b1ee0
Step 2 : RUN apt-get update
 ---> Using cache
 ---> eea42cb6135d
Step 3 : RUN apt-get install -y software-properties-common
 ---> Using cache
 ---> 9db86ab17850
Step 4 : RUN add-apt-repository ppa:nginx/stable
 ---> Using cache
 ---> 5ed2266a93a9
Step 5 : RUN apt-get update
 ---> Using cache
 ---> 09fcfdc1fed3
Step 6 : RUN apt-get install -y nginx-full vim
 ---> Using cache
 ---> cc0c1662e009
Step 7 : RUN ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up
 ---> Running in 5d962ec4e35d
SIOCSIFADDR: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
SIOCSIFNETMASK: Operation not permitted
SIOCSIFFLAGS: Operation not permitted
The command '/bin/sh -c ifconfig lo:0 192.168.168.70 netmask 255.255.255.0 up' returned a non-zero code: 255

Bien sûr, si j'exécute un conteneur avec l'option de privilèges, je peux configurer l'ip vers l'interface de bouclage. Mais c'est un script de plus à ajouter.

@cpuguy83 J'ai environ 20 lignes d'entrées iptable J'aimerais RUN dans mon Dockderfile mais je ne peux pas car j'ai besoin de --cap-add=NET_ADMIN . Ces commandes doivent se produire indépendamment de la personne qui exécute le conteneur et quelle que soit la machine sur laquelle elles l'exécutent (le conteneur exécute une application interne). Où/comment me suggérez-vous de le faire en fonction de ce dont vous avez discuté ci-dessus ?

@MatthewHerbst Malheureusement, les règles iptables ne persisteront pas / ne pourront pas persister avec l'image.

@cpuguy83 J'utilise une image centos:6 et je peux exécuter /sbin/service iptables save pour conserver les règles dans le système de fichiers. Je pense qu'il s'agit d'une capacité similaire sur Ubuntu et d'autres via le package iptables-persistent .

Vous pouvez simplement générer les règles iptables pour ce fichier, il n'est pas nécessaire de
les appliquer réellement. La situation du réseau dans laquelle le conteneur est exécuté peut
être très différent, vous devez donc simplement appliquer les règles au moment de l'exécution (si cela, vous
peut-être mieux avec l'hôte qui les génère).

Le 16 mai 2016 à 16h03, "Matthew Herbst" [email protected] a écrit :

@ cpuguy83 Je suis sur CentOS et je peux exécuter run /sbin/service iptables save to
persister les règles dans le système de fichiers. je crois que c'est pareil
capacité sur Ubuntu et autres via le package iptables-persistent.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub

@justincormack ne sais pas pourquoi je n'y ai pas pensé ! Merci!

Comment êtes-vous censé exécuter des commandes nécessitant des privilèges lors de l'utilisation de docker service ? J'ai besoin de définir le nom d'hôte sur quelques-unes de mes machines, mais malheureusement, cela nécessite des privilèges.

@nostrebor qui n'a aucun rapport avec ce problème ouvert.
Nous évaluons les options qui doivent exister pour les services plutôt que de les copier 1 à 1. Le mode privilégié ne sera probablement pas en 1.12 pour les services.

J'essaie des builds docker qui compilent quelque chose pour l'installation, mais il doit être compilé avec les bibliothèques qui existent sur un système de fichiers réseau CVMFS. Bien sûr, je ne peux pas monter CVMFS sans exécuter --privileged, donc je ne peux pas du tout le faire en utilisant un Dockerfile.

@cpuguy83 @tlbtlbtlb Il s'agit d'un cas d'"installateur" dépendant fondamentalement d'une action privilégiée. Mais ce n'est pas ce que j'appellerais une "utilisation frivole", j'ai juste besoin d'accéder aux bibliothèques partagées sur un système de fichiers réseau. Pourtant, l'installation dans ce cas ne consiste PAS simplement à extraire des fichiers d'une archive.

Je ne comprends pas en quoi le montage d'un système de fichiers réseau est un problème de portabilité. (Tous nos environnements cibles auront accès à ce système de fichiers. Ils y sont obligés car ils créent un autre code qui doit ÉGALEMENT être lié au code binaire sur le système de fichiers réseau.)

Dois-je essayer une approche différente? Dois-je monter CVMFS sur l'hôte et partager ce répertoire avec le conteneur ou quelque chose ? Je ne veux pas avoir à configurer un système de construction externe juste pour créer cette image - l'image sur laquelle elle est basée a déjà un système de construction complet qui fera le travail. J'ai juste besoin de pouvoir monter CVMFS.

J'étais enthousiaste à l'idée de faire cela avec un Dockerfile, mais il semble que je devrai le faire à la dure en utilisant des scripts avec docker run --privileged , ou utiliser autre chose au lieu de docker. Existe-t-il un moyen de monter un système de fichiers dans un conteneur _sans_ avoir un accès privilégié ?

J'ai fait une solution de contournement, en plaçant/en faisant écho à des commandes privilégiées dans un script et en utilisant l'instruction CMD pour exécuter le script au point d'entrée du conteneur, donc après avoir construit une image comme celle-ci, je peux simplement exécuter le conteneur en mode privilégié et tout fonctionne.

@drstapletron , selon la documentation du CERN cvmfs , vous avez deux options pour le moment , soit monter les cvmfs de l'hôte au conteneur, soit installer les cvmfs dans un conteneur privilégié.

Pour le cas des secondes, je viens d'écrire un fichier docker pour les gars de cmssw, ici :
https://github.com/iahmad-khan/system-admin/blob/master/cvmfs-inside-docker.Dockerfile

donc en utilisant ce fichier, vous pouvez simplement créer une image (ou peut-être la récupérer à partir de cmssw dockerhub) et l'exécuter en mode P, et tout sera déjà là dans le conteneur ( ls /cvmfs/*)

Je ne sais pas si cela a été couvert ci-dessus car il s'agit d'une assez longue liste de commentaires sur ce problème. Moi aussi, j'aimerais avoir les commandes de construction --privileged. Mon cas d'utilisation actuel consiste à contourner un problème que j'ai rencontré lors de la construction de l'ebuild go sur une gentoo stage3. Si je n'utilise pas de conteneur, les instructions actuelles du manuel gentoo font que systemd se comporte de manière erratique une fois que je 'umount -l /mnt/gentoo/dev{/shm,pts,} && umount -l /mnt/gentoo/{ proc,sys}' à partir d'un système démarré avec systemd... Lorsque je déplace mon build stage3 dans un conteneur docker, tout fonctionne bien jusqu'à ce qu'un build nécessite ptrace, ou une autre fonctionnalité restreinte... dont le go-1.7.1. ebuild semble exiger.

Pour l'instant, j'exécute simplement la construction dans une commande d'exécution de docker, en validant puis en poursuivant à partir de là, mais il serait préférable d'activer ptrace dans la commande de construction de docker elle-même pour éviter les étapes manuelles.

J'aimerais aussi cette fonctionnalité. Je veux créer un environnement de construction, mais cela nécessite un module de noyau et modprobe ne coopérera pas avec moi lorsque je construis. Existe-t-il des solutions de contournement pour cela?

Spécifiquement:

modprobe vcan && \
ip link add type vcan && \
ifconfig vcan0 up

Cela semble être un cas d'utilisation tout à fait raisonnable.

@seltzy Je suggère de ne pas retenir votre souffle en attendant que quelqu'un de docker reconnaisse le caractère raisonnable de votre cas d'utilisation.

En ce qui concerne l'architecture et l'inclusion de fonctionnalités, ils sont très lourds, pragmatiques, distants et ont tendance à ignorer tous les cas d'utilisation qui ne correspondent pas à _leur_ feuille de route.

Nous, les gens ordinaires, devons comprendre que l'équipe docker prend des décisions d'architecture qui répondent à leurs propres besoins (probablement des clients commerciaux et des intérêts personnels), et ces décisions se chevauchent rarement avec notre (l'utilisateur final public) très laborieusement conçu problèmes que nous déposons ici.

Ils sont bien entendu libres d'allouer leurs ressources d'ingénierie de cette manière.
Mais cela fournit un bilan qui demanderait à l'imagination si l'entreprise était jamais décrite comme "prenant au sérieux les besoins des utilisateurs".

@tamsky tu as

@tamsky Je peux comprendre pourquoi vous pensez cela, puisque le projet n'a pas accepté une fonctionnalité que vous désirez clairement.

Je peux vous assurer que cela n'a rien à voir avec une quelconque décision commerciale. Le fait est que --privileged lors de la construction donnera lieu à des images non portables.
Des choses comme modprobe dans l'environnement de build ne sont pas utiles et peuvent même amener deux builds à donner des résultats totalement différents.

J'ai moi-même implémenté --privileged sur build. Ce n'est pas un problème d'ingénierie, et c'est vraiment assez trivial à mettre en œuvre. C'est le soutenir qui est le problème.
Pour les utilisateurs avancés, un générateur personnalisé peut être implémenté, même en réutilisant le code existant, en utilisant les API existantes qui peuvent inclure un support privilégié.

Cela dit, cette question est toujours ouverte pour une raison. C'est parce que les gens écoutent.

Merci pour votre considération.

@cpuguy83 Merci pour l'explication. Je ne savais pas que c'était un problème de portabilité. Je suppose que mon désir pour cela est alimenté par un malentendu.

Quelle est la démarche philosophique générale à adopter face à la tentation d'avoir une construction privilégiée ?

@seltzy ne

@ cpuguy83 J'attends toujours une réponse sur mon cas d'utilisation. Le système de construction de notre institution est distribué sur un système de fichiers réseau que je dois monter dans mon conteneur. Cela nécessite que le conteneur s'exécute en mode privilégié. La décision de mon établissement d'utiliser un système de fichiers réseau pour la distribution de logiciels n'est pas inhabituelle pour la physique des particules. Vous prétendez que --privileged lors de la construction crée des images non portables, mais cela n'a aucun rapport avec mon cas d'utilisation. Notre modèle de développement a déjà abandonné toute portabilité que nous _pourrions_ perdre en raison de notre utilisation d'un système de fichiers réseau (vraiment ?). Nous avons juste besoin que la machine de développement soit sur le point de la monter.

@ cpuguy83 PS, vous avez mentionné un constructeur personnalisé. Où puis-je trouver des informations à ce sujet ? Merci!

Toute cette discussion sur la portabilité des conteneurs est de toute façon un hareng rouge géant. Vous pouvez déjà accomplir la même chose en créant une image de l'étape 1, en lançant un conteneur en mode privilégié, en faisant tout ce que vous avez à faire, puis en utilisant docker commit pour créer l'image finale à partir de ce conteneur.

Une fois qu'ils ont ajouté l'option de commit docker, toute notion de portabilité d'image a de toute façon disparu, donc forcer les gens à le faire en 3 étapes au lieu de 1 ne gagne rien et ne sert qu'à ennuyer les gens qui pourraient vraiment utiliser une option de construction privilégiée.

@drstapletron Le montage d'un système de fichiers n'est pas nécessairement quelque chose qui peut
Le problème ici est d'avoir la capacité de monter un système de fichiers signifie également être capable de faire un tas d'autres choses désagréables.

@ctindel Oui, vous pouvez faire tout ce que vous voulez dans les conteneurs que vous créez. Le fait que docker build soit "la" méthode de création d'images prise en charge, signifie cependant que nous devons nous assurer que les images créées avec _sont_ portables.

Les images portables ne sont pas un hareng rouge. La portabilité de la charge de travail est l'objectif principal de la conception de Docker. Notre directive principale, pour ainsi dire.

@seltzy La plupart des choses qui nécessitent des privilèges supplémentaires appartiennent à l'exécution, car la plupart du temps, les privilèges élevés sont utilisés pour modifier l'hôte d'une manière ou d'une autre.
Cela dit, je peux certainement comprendre que certaines choses sont nécessaires au moment de la construction (comme le montage nfs ci-dessus).... mais même avec le cas de NFS et la construction manuelle de l'image (pas avec docker build ), je ne donnerais pas au conteneur --privileged ni aucune capacité supplémentaire, à la place, je monterais l'exportation nfs en tant que volume.

@drstapletron mount ne nécessite pas --privileged seulement un ensemble de capacités plus restreint et est beaucoup plus susceptible de se produire plus tôt qu'un mode privilégié complet, car cela donne un accès root complet à l'hôte que la plupart des gens font pas envie. (Il y a toujours des problèmes de sécurité mais ils sont plus gérables).

J'ai donc un cas d'utilisation entièrement portable et ne modifiant pas l'hôte. Il est même open source et vous pouvez le voir ici .

Fondamentalement, je souhaite exécuter Mock dans un conteneur Docker portable pour créer une image ISO CentOS personnalisée. Mock, pour ceux qui ne le savent pas, est un constructeur de RPM conteneurisé. Le problème est que, comme il utilise des conteneurs, j'ai besoin de --privileged ou de --cap-add . Idéalement, je pense que docker build fonctionnerait comme une fonction, prenant quelques arguments et renvoyant son résultat final. Sans ces drapeaux, cependant, je ne peux pas faire cela.

Pareil ici ! Utiliser une simulation dans docker est un cauchemar à cause de cela :(

Sending build context to Docker daemon 9.728 kB
Step 1 : FROM centos
 ---> 980e0e4c79ec
Step 2 : MAINTAINER Gregory Boddin
 ---> Using cache
 ---> 93e709c87f25
Step 3 : RUN yum install -y spectool mock
 ---> Using cache
 ---> 7006ef8d0276
Step 4 : RUN useradd mock -g mock
 ---> Using cache
 ---> bfb931c56d89
Step 5 : ADD *.cfg /etc/mock/
 ---> Using cache
 ---> 15521d2822b1
Step 6 : RUN su mock -c"/usr/bin/mock -r edge-5-x86_64 --init"
 ---> Running in 542a742b6017
INFO: mock.py version 1.2.17 starting (python version = 2.7.5)...
Start: init plugins
INFO: selinux disabled
Finish: init plugins
Start: run
ERROR: Namespace unshare failed.

@cpuguy83 a écrit :

Le fait est que --privileged on build cédera aux images non portables.

Pourquoi ne pas autoriser --privileged pour ceux qui n'ont pas besoin d'une grande portabilité ?
Une simple note dans la documentation officielle serait un compromis raisonnable (par exemple _Avertissement : passer --privilege à la commande build peut entraîner une image moins portable !_). Cela résoudrait les exigences de presque tout le monde ; certains utilisateurs n'ont pas besoin de portabilité, d'autres le font, un avertissement suffirait à répondre aux besoins de chacun.

Je suis certain que le manque de build --privileged complique considérablement mon cas d'utilisation actuel.

Il pourrait s'appeler --non-portable . Je n'ai pas encore utilisé les parties de déploiement de docker, mais l'isolation + le système de fichiers de superposition ont été vraiment utiles sans cela.

J'ai besoin d'utiliser un logiciel propriétaire qui nécessite l'installation d'un conteneur privilégié. Il n'y a rien que je puisse faire à ce sujet. Je suis obligé de faire le processus de construction, d'exécution et de validation en 3 étapes.

La portabilité des conteneurs ne signifie rien pour moi ou mon entreprise, en fait, je parie que cela ne signifie rien pour la grande majorité des entreprises. Ce qui est important, c'est que j'aimerais conserver moins de logiciels, donc je pense que choisir la portabilité plutôt que la convivialité dans ce problème est préjudiciable à Docker.

+1 pour cela, dans le processus de construction, nous utilisons setfacl, cela échoue pendant la construction et les services ne démarrent pas dans le conteneur. Je pense qu'en tant qu'utilisateurs finaux, nous ne devrions pas être limités, utilisez l'option --priviledge uniquement si vous en avez besoin et que la valeur par défaut est désactivée.

+1 pour cela. Dans notre processus de construction, il est nécessaire de monter les fichiers /proc et /dev. Idéalement, nous devrions pouvoir inclure l'étape de montage dans le fichier docker.

@samsun387 Pourquoi votre processus de génération l'exige-t-il ?

@skshandilya setfacl n'est pas portable et je serais surpris si les acl pouvaient être conservées dans une image.

@robhaswell "nécessite un conteneur privilégié" n'aide pas beaucoup. Qu'est-ce qui est réellement utilisé lors de l'installation ?

+1. mock init en a besoin.
presque lu tout le numéro. Je ne comprends pas pourquoi les gens continuent de demander "pourquoi as-tu besoin de ça" pendant 3 ans d'affilée.

@Betriebsrat Parce que "X a besoin de ça" n'est pas vraiment utile.
Que fait « X » ? Pourquoi « X » a-t-il besoin de cela pendant la phase de construction ?

Par exemple, le cas ci-dessus avec des capacités pour monter /proc et /dev ne semble vraiment pas être le bon endroit pour la phase de construction, et semble même que l'image serait liée à l'hôte dans un tel un cas.

« privilégié » est aussi un réservoir. Il ouvre absolument tout, désactive toutes les fonctionnalités de sécurité, donne un accès en écriture à des endroits généralement en lecture seule... où quelqu'un a probablement juste besoin de pouvoir faire une chose très spécifique.

Ces questions sont posées afin que nous puissions obtenir le cas d'utilisation réel et comment nous pourrions satisfaire un tel cas.

Au fait, quand je dis « fonctionnalités de sécurité », je veux dire deux choses :

1. Choses pour empêcher le piratage
2. Isolation des problèmes d'application des problèmes d'hôte (c'est-à-dire que la construction de l'image ne doit pas lier l'image à l'hôte sur lequel elle est construite).

On dirait que le mien a été résolu par 21051, je suis sorti, pour l'instant :)

@shykes a dit le 28 novembre 2013 @ https://github.com/docker/docker/pull/2839#issuecomment -29481246 ::

Désolé, la conception actuelle consiste à appliquer '1 source, 1 build', c'est pourquoi nous n'autorisons aucun argument à docker build autre que le répertoire source.

Je comprends le fait que certaines versions ne peuvent actuellement pas avoir lieu car elles nécessitent des opérations privilégiées. Pour gérer cela correctement, nous pourrions avoir besoin de 1) permettre à un Dockerfile d'exprimer le besoin d'être construit de manière privilégiée, et 2) implémenter un système d'autorisation/trus qui permet à docker de suspendre la construction, d'avertir correctement l'utilisateur du risque, exposer des informations sur l'origine et la fiabilité du Dockerfile, puis collecter la décision de l'utilisateur d'autoriser ou de refuser la construction.

@cpuguy83 , la conception a-t-elle changé du tout par rapport à l'application : "1 ​​source, 1 build" ?
Le projet Docker est-il prêt à modifier cette conception et à autoriser cette fonctionnalité demandée par la communauté ?

Le commentaire de Shykes ci-dessus semble expliquer ce que "nous pourrions avoir besoin de faire" pour résoudre ce problème. Dans le même temps, le langage utilisé ("pourrait") semble donner au projet Docker beaucoup de place pour trouver des raisons supplémentaires de rejeter ce changement de conception.

L'ajout d'une déclaration NEEDS_PRIVILEGED a du sens, mais tous ces trucs sur la pause de la construction ? Échouez simplement avec une erreur et laissez l'opérateur passer l'option --privileged s'il souhaite effectivement autoriser la construction privilégiée.

@ cpuguy83 le fait est que les personnes qui ont besoin du mode privilégié dans la construction sont généralement des utilisateurs docker commit dans le cadre de leur build pour l'étape qui en a besoin.

Vous n'empêchez en aucun cas les gens d'utiliser le mode privilégié dans la construction, vous le rendez simplement ennuyeux à faire.

Si votre objectif est de le rendre ennuyeux à faire, dites-le simplement et fermez ce problème au lieu de le laisser durer des années et des années.

Dites « nous ne résoudrons pas cela parce que nous voulons que ce soit ennuyeux à faire » et fermez ce problème.

/fil

@cpuguy83 , d'après ce que j'ai compris, Mock utilise unshare(2) avec le drapeau CLONE_NEWNS -- et peut-être d'autres -- lorsqu'il crée son environnement chroot/container. Cela nécessite au moins CAP_SYS_ADMIN .

Que fait « X » ? Pourquoi « X » a-t-il besoin de cela pendant la phase de construction ?

Dans notre cas d'utilisation, nous ne savons pas. C'est une merde propriétaire que nous ne pouvons pas changer. Le fait est que notre entreprise ne se soucie pas de la "sécurité" (dans ce contexte) ou de la portabilité, ou de l'une des préoccupations qui ont été énumérées. Nous voulons juste mettre cette foutue merde dans un conteneur et passer à quelque chose de précieux.

Comme le dit @PonderingGrower , nous allons le faire de toute façon, c'est juste une question de temps que nous perdons en le faisant.

les personnes qui ont besoin du mode privilégié dans la construction sont généralement des utilisateurs expérimentés qui savent parfaitement quels sont les risques de son utilisation

Je ne suis pas du tout d'accord avec cette hypothèse. Dans l'ensemble, les personnes qui utilisent --privileged sont la même catégorie d'utilisateurs qui exécutent aveuglément chmod -r 777 "parce que quelqu'un a écrit qu'il a résolu le problème"

Dans notre cas d'utilisation, nous ne savons pas. C'est une merde propriétaire que nous ne pouvons pas changer. Le fait est que notre entreprise ne se soucie pas de la "sécurité" (dans ce contexte) ou de la portabilité, ou de l'une des préoccupations qui ont été énumérées.

"dans ce contexte" ici, ce qui signifie : donner à "une merde propriétaire" un accès root sur votre hôte.

@thaJeztah Je n'ai aucun problème avec ça. C'est un logiciel que nous avons acheté et pour lequel nous payons l'assistance. Si nous n'utilisions pas de conteneurs, l'installation aurait toujours besoin de root.

Nous avons besoin de cette fonctionnalité pour utiliser dind lors de la construction afin de préconfigurer certains conteneurs à l'intérieur de celui que nous construisons.

De quoi parlez-vous ici depuis 3 ans ?

docker run a une option --cap-add , --cap-drop et d'autres. Donc la commande RUN dans Dockerfile veut avoir les mêmes options. Donc, Dockerfile veulent envoyer des requêtes à la machine parente et lui demander d'ajouter/supprimer certains privilèges.

La machine parente peut faire ce qu'elle veut avec ces requêtes. Vous pouvez rendre le shell interactif, vous pouvez créer une boîte de dialogue de confirmation de l'interface graphique, etc. Pourquoi discutez-vous de la résolution de ces demandes dans ce numéro ?

Un nombre important d'utilisateurs de docker souhaitent avoir la possibilité de --cap-add ou --privileged dans la commande build, pour imiter ce qu'il y a dans la commande run.

C'est pourquoi ce ticket est ouvert depuis 3 ans avec des gens qui interpellent constamment même si les mainteneurs ne sont pas intéressés à donner aux utilisateurs ce qu'ils veulent dans ce cas spécifique.

@ctindel C'est certainement le problème de ce problème. Il y a un écart entre docker build --cap-add et RUN --cap-add .

Certaines personnes souhaitent résoudre les demandes de privilèges de la machine enfant avec seulement docker build --cap-add=caps_array . Qu'est-ce que c'est? C'est juste : caps_array.include? requested_cap .

Certaines personnes veulent pre_requested_caps.include? requested_cap . Certaines personnes veulent stdout << requested_cap, stdin.gets == 'y' .Certaines personnes veulent gui_confirm requested_cap . Certaines personnes voudront certainement UAC_fullscreen_dialog requested_cap .

La méthode de résolution de requested_cap dépend des goûts de l'utilisateur et je pense que cette question ne sera jamais posée.

Mais RUN --cap-add n'a rien à voir avec les goûts des gens. Qu'est-ce qu'on attend?

@andrew-aladev Je ne comprends pas vraiment ce que dit votre message. Le fait est que les gens ont des logiciels tiers (RPM, DEB, etc.) qui ne sont pas sous leur contrôle, qu'ils souhaitent installer dans une image au moment de la "création docker", et qui nécessitent des capacités supplémentaires pour s'installer correctement. Puisqu'il s'agit de RPM tiers, il n'y a aucun moyen de résoudre le besoin de privilèges accrus pendant la phase d'installation.

Ils contournent le problème en exécutant un conteneur avec ces capacités accrues, en installant leur logiciel, puis en créant une image à partir de ce conteneur. C'est pénible et montre clairement qu'il n'y a aucune raison fonctionnelle d'interdire l'ajout de plafonds au moment de la construction, car la même fin peut être atteinte de manière détournée.

@ctindel Mon anglais n'est pas très bon, désolé.

Je connais. J'ai essayé d'émerger la glibc et j'ai reçu ptrace not permitted .

docker peut exécuter par lui-même un conteneur avec des capacités augmentées/réduites. RUN dans Dockerfile devrait prendre en charge --cap-add , --cap-drop , etc.

Imaginons que notre Dockerfile aura RUN --cap-add=SYS_PTRACE -- emerge -v1 glibc . Comment ça marcherait ?

1. La machine enfant envoie une demande au parent et demande SYS_PTRACE .
2. Le parent permet des capacités étendues.
3. Le parent crée un nouveau conteneur avec SYS_PTRACE autorisé.

Je vois que personne dans ce dossier n'en discute réellement. Les gens discutent simplement d'une méthode permettant d'autoriser ces capacités.

@thaJeztah a dit

Dans l'ensemble, les personnes qui utilisent --privileged sont la même catégorie d'utilisateurs qui exécutent aveuglément chmod -r 777

Cet homme veut une méthode de validation des capacités requises plus flexible que juste log :info, requested_cap; return privileged? .

@ctindel tu as dit

L'ajout d'une déclaration NEEDS_PRIVILEGED a du sens, mais tous ces trucs sur la pause de la construction ? Échouez simplement avec une erreur et laissez l'opérateur passer l'option --privileged s'il souhaite effectivement autoriser la construction privilégiée.

Vous voulez rendre le shell interactif. Vous voulez stdout << requested_cap, stdin.gets == 'y' . C'est l'autre méthode de validation des capacités requises.

@cpuguy83 a dit

quelqu'un a probablement juste besoin d'être capable de faire une chose très spécifique... des choses pour empêcher le piratage.

Cet homme veut docker build --cap-add=caps_array caps_array.include? requested_cap . C'est l'autre méthode de validation des capacités requises.

Je demande donc : Pourquoi RUN dans Dockerfile n'ont toujours pas de support de --cap-add , --cap-drop , etc ? Personne ne conteste cela. 3 ans ont passé !

@andrew-aladev Je suppose que personne n'a plaidé en faveur de cette syntaxe car il a été clairement indiqué que la syntaxe du fichier docker est gelée jusqu'à ce que le constructeur soit réécrit/refactorisé/découplé du moteur principal. https://github.com/docker/docker/issues/29719#issuecomment -269342554

Plus précisément, le titre du problème et l'OP demandent --privileged build

cela donne un coup de poing à Fonzie : .

être capable d'exécuter strace dans l'étape build aide beaucoup.
actuellement, je contourne ce problème en déplaçant toutes les choses dont j'ai besoin pour déboguer vers l'étape run - pas idéal.

est-ce que quelqu'un sait pourquoi cela fonctionnerait dans l'étape run et non dans l'étape build ? c'est-à-dire les raisons historiques.
existe-t-il une alternative à strace qui fonctionne sans beaucoup d'autorisations ou de configuration ?

Une solution/solution de contournement est proposée dans
https://github.com/docker/docker/issues/6800#issuecomment -50494871 :

si vous rencontrez des problèmes dans la construction de docker, vous pouvez utiliser un "conteneur de constructeur":
docker run --cap-add [...] mybuilder | docker build -t myimage -

Quelqu'un (éventuellement @tiborvass) pourrait-il préciser cela ? Quel genre de mybuilder ici ?
Le nom de l'image avec un ENTRYPOINT ? Ou l'image fait-elle partie de [...] et mybuilder fait référence
à un script shell ? Et comment convaincre docker run de passer le context.tar.gz dans le docker build -
si c'est vraiment ce qui se passe ici. Merci d'avance Steffen

@sneumann mybuilder serait un nom d'image et aurait en effet quelques CMD ou ENTRYPOINT . Le contrat pour que cette solution de contournement fonctionne est que mybuilder devra tar le contexte à partir du conteneur et le laisser aller à stdout. Cela est transmis au stdin de docker build , grâce au shell pipe | et est considéré comme le contexte car le chemin de contexte pour docker build -t myimage - est - .

un peu étrange en regardant le code, il semble que cette option soit disponible dans la commande build :

• run : je suppose que container signifie ici run - https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/container/opts.go #L485.
• build : https://github.com/docker/docker/blob/bb0a532fc21cb6b9390fb7e5eb0054bdc8045bbc/cli/command/image/build.go#L108.

quelqu'un de plus au courant a-t-il une idée de la raison pour laquelle il n'est pas appliqué ?

@mbana le --security-opt est destiné aux conteneurs Windows natifs, qui prennent en charge "credentialspec" https://github.com/docker/docker/pull/23389

est-il possible de le modifier et de le faire persister pour que le futur build active ptrace ?

pour ceux que ça intéresse voici quelques bons liens :

• http://www.projectatomic.io/docs/docker-building-images/ - comment construire l'image en utilisant la technique décrite ci-dessus. c'est-à-dire, utilisez run à build l'image.
• https://blog.afoolishmanifesto.com/posts/how-to-enable-ptrace-in-docker-1.10/ - divers

J'ai vu de nombreuses réclamations de diverses personnes selon lesquelles cette fonctionnalité n'est pas nécessaire car les versions peuvent être modifiées pour ne pas nécessiter certaines opérations privilégiées, mais aucune suggestion sur ce qu'il faut faire à propos du cas "docker in docker". Si une construction doit exécuter des commandes docker , par exemple pour extraire certaines images que nous voulons envoyer à l'intérieur de celle-ci, ou pour construire une sous-image, comment sommes-nous censés le faire sans une sorte de privilège option de construction ?

Pour l'instant, je vais contourner ce problème en utilisant docker run et docker commit mais ce serait formidable si docker build pouvait prendre en charge ce cas d'utilisation.

@scjody On dirait que tu veux #31257

@ cpuguy83 Je ne suis pas sûr que cela couvre ce qui se passe dans ce cas, mais je vais

Salut, j'aimerais mettre mon nom dans le chapeau s'il vous plaît-implémentez-ce. Ou peut-être existe-t-il une solution différente à mon problème (docker noob ici) que quelqu'un pourrait m'indiquer ?

J'essaie de créer une image basée sur l'image officielle centos/systemd et de la provisionner avec Saltstack. Cela nécessite de démarrer (et peut-être de redémarrer) le démon salt-minion avec systemd, ce qui ne peut pas être fait (AFAIK) sans mode privilégié.

@onlyanegg Je pense que dans cette situation, Saltstack remplace en grande partie la fonctionnalité du constructeur; gardez à l'esprit que chaque instruction RUN est exécutée dans un nouveau conteneur, auquel point le conteneur de construction précédent est arrêté et validé dans une image/un calque.

Avez-vous envisagé d'effectuer la compilation en exécutant un conteneur et en validant les résultats ( docker commit ) ?

Merci d'avoir répondu, @thaJeztah. Je n'avais pas réalisé que c'était ce que faisait la directive RUN . J'ai lu la plupart de ce problème, donc je suis au courant de la solution docker commit contournement docker build -> docker run -> docker commit , ce que je finirai probablement par faire. Je suis juste plus en faveur d'avoir un seul fichier pour décrire mon image - cela semble plus net. Peut-être que je peux mettre toutes ces étapes dans les post-processeurs du packer et ensuite j'aurai ça.

Pourquoi celui-ci est-il autant ignoré ? À l'heure des conteneurs, des kubernetes et des minikube, et de l'utilisation de docker dans l'unification de l'environnement de CI et de développement, cette fonctionnalité est vraiment cruciale.

@onlyanegg vous devriez pouvoir redémarrer les services _sans_ en mode privilégié. Si vous avez un Dockerfile illustrant cela (c'est-à-dire "la commande RUN à la ligne 8 de ce Dockerfile ne fonctionne pas car elle nécessite un mode privilégié"), je serais plus qu'heureux d'y jeter un œil !

@derberg justement ! A l'heure des conteneurs, CI, CD, il est important que les outils de build puissent être contenus (au sens de la sécurité). Si vous autorisez le mode privilégié, vous devez changer radicalement la façon dont vous utilisez les outils CI comme Jenkins, Travis, Codeship, etc. Même question : si vous avez un Dockerfile qui nécessite le mode privilégié, je serais heureux d'y jeter un coup d'œil pour suggérer des alternatives.

Merci!

@jpetazzo essaie d'obtenir une image docker avec docker à l'intérieur :

FROM ubuntu:16.04

# Get dependencies for curl of the docker
RUN apt-get update && apt-get install -y \
    curl \
    sudo \
    bash \
    && rm -rf /var/lib/apt/lists/*

RUN curl -sSL https://get.docker.com/ | sh

Maintenant, construisez-le et démarrez-le. Après le démarrage, exécutez service docker start pour démarrer le démon docker. Vérifiez ensuite l'état du service service docker status :

• avec le statut d'indicateur privilégié est ok et vous pouvez démarrer le conteneur sans problèmes
• sans le drapeau, ça ne commence jamais

@jpetazzo ech, vous venez de remarquer que vous êtes le créateur de https://github.com/jpetazzo/dind :) vous connaissez donc le concept docker in docker :)

Quoi qu'il en soit, vous savez donc que le drapeau privilégié est nécessaire pour exécuter. Alors maintenant, vous pouvez imaginer un groupe de personnes travaillant sur un environnement et souhaitant avoir un environnement unifié pour le développement avec déjà des éléments préconfigurés à l'intérieur, par exemple minikube avec des composants préinstallés ou autre chose

Alors, existe-t-il un moyen de monter un partage NFS ou SMB dans docker build ?

@derberg, ces étapes ne fonctionneront pas, même si le conteneur de construction exécutait --privileged ; les packages docker (et le script d'installation) installent (par exemple) des packages de noyau sur Ubuntu 16.04.
C'est exactement la raison --privileged laquelle docker build , car il serait capable d'apporter des modifications sur le _host_.

Même si docker aura besoin de privilèges lors de l'exécution, l'installation elle-même n'en a pas besoin ; par exemple, voici les étapes à suivre pour installer docker dans votre image ;

docker build -t foo -<<'EOF'
FROM ubuntu:16.04

RUN apt-get update && apt-get install -y \
    apt-transport-https \
    ca-certificates \
    curl \
    software-properties-common \
    && rm -rf /var/lib/apt/lists/*

RUN curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
RUN add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable"
RUN apt-get update && apt-get install -y docker-ce \
    && rm -rf /var/lib/apt/lists/*
EOF

Et vous pouvez l'exécuter sans problème (j'utilise --privileged ici, mais des autorisations plus précises sont peut-être possibles) :

docker run -it --rm --privileged -v /var/lib/docker foo dockerd --debug

Voici comment je contourne ce problème, pour les personnes qui ont vraiment besoin de construire une image docker en mode privilégié. Cela peut ne pas résoudre tous les cas, mais peut aider dans certains.

Cette méthode nécessite un Dockerfile, un fichier docker-compse et un script shell.

Le fichier Docker

C'est la même chose dont vous auriez besoin pour construire l'image. La seule différence, arrêtez-vous là où vous devez effectuer des opérations privilégiées, ne les incluez pas. Ils doivent être exécutés par le docker-compose, en tant que script. Par exemple:

FROM ubuntu:16.04
RUN apt-get update && apt-get install <your packages>
# And more commands
......

## Below are the operations you intended to run in privileged mode when building the image, which does not work.
# More commands....
## But they now are moved to a separated shell script and it will be included in the image
COPY further-commands-to-run-in-privileged-mode.sh /

Ces commandes supplémentaires qui doivent être exécutées en mode privilégié sont maintenant dans further-commands-to-run-in-privileged-mode.sh . Il est inclus dans l'image et sera ensuite exécuté par docker composer pour terminer le processus de génération.

Le fichier de composition docker

Le fichier de composition est la clé. Il construira d'abord l'image à partir de Dockerfile ci-dessus et démarrera un conteneur à partir de cette image en mode privilégié , puis vous pourrez y effectuer votre opération privilégiée. Par exemple:

version: '3'

services:
  your_service:
    container_name: your_container
    # First build the image from the Dockerfile
    build:
      # Change this to where you keep above Dockerfile
      context: ../docker-build
    image: "your_image_name:your_image_tag"

    # Then start a container from the just built image in privileged mode to finish what's left
    entrypoint: /further-commands-to-run-in-privileged-mode.sh
    privileged: true

Construire l'image

Les étapes ci-dessous peuvent également être enregistrées dans un script shell.

# First build the image and container(in privileged mode)
docker-compose -f docker-compose.yml up

# Then commit the temporary build container to a new image, change the ENTRYPOINT to what you want
docker commit \
    -c 'ENTRYPOINT ["/bin/bash"]' \
    <build container name> \
    <final image name>:<final image tag>

# Remove the temporary build container
docker rm <build container name>

@thaJeztah Je n'ai pas de problème avec l'installation, j'ai un problème avec le démarrage du service docker pendant la construction et l'extraction de certaines images pour les rendre disponibles dans l'image

Ajoutez le script suivant à votre Dockerfile et vous verrez que le service Docker ne démarre jamais

#!/bin/bash

service docker start

sleep 20

service docker status

docker pull busybox

@derberg OK, je vois ! _Personnellement_, si je voulais inclure des images dans un conteneur dind , je les téléchargerais (par exemple avec reg ) et je les chargerais au premier démarrage du conteneur. Pourquoi? Parce que si vous extrayez les images pendant la construction, l'image ne fonctionnera _que si dind est démarré avec le même pilote de stockage_. En d'autres termes, votre image peut ou non fonctionner sur une autre machine.

De plus, si vos images sont grandes (c'est-à-dire autre chose que, disons, busybox ou alpine ), vous vous retrouverez avec une très grande image DinD...

J'aimerais en savoir plus sur votre cas d'utilisation final - car je suis sûr que nous pouvons vous aider à trouver un moyen plus efficace que de créer une énorme image DinD :-)

(Sinon, la solution proposée par @kraml est plutôt élégante !)

Voir également https://github.com/moby/moby/blob/master/contrib/download-frozen-image-v2.sh
Télécharge des images en utilisant uniquement bash+curl+tar.
Nous l'utilisons ici : https://github.com/moby/moby/blob/master/Dockerfile#L171

@jpetazzo, nous dind approche

J'ai rencontré ce problème en essayant de créer une image contenant une application héritée (cas d'utilisation assez normal), où le programme d'installation a essayé d'exécuter des commandes sysctl et a échoué.

Pour en revenir à ce fil et passer en revue les 4 années entières (!!!) d'allers-retours sur la question de savoir comment ajouter une sorte de capacités privilégiées à la commande docker build, il semble que les options disponibles dans cette situation sont soit un un tas de commandes sed pour modifier le programme d'installation afin de supprimer les appels sysctl, ou une construction en plusieurs étapes -> exécuter -> pipeline de validation. Je suis d'accord avec @derberg que 'build -> run -> commit' semble être une solution de contournement (imo une solution de contournement grossière / hacky) et je ne pense pas que mon cas d'utilisation soit si unique. En vérifiant d'autres threads, j'ai vu de nombreuses personnes signaler des problèmes avec diverses installations d'applications et de bases de données avec des commandes docker build ayant échoué en raison d'un manque de privilèges.

À ce stade, la commande docker run prend en charge des options « privilégiées » étendues, ainsi qu'un « contrôle précis des capacités à l'aide de --cap-add et --cap-drop ». Et donc, je pense que les objections sur une base de sécurité ou technique sont sans objet. Si l'option d'exécution privilégiée est ajoutée avec '--cap-add' et '--cap-drop', un ingénieur soucieux de la sécurité pourrait choisir de limiter une build privilégiée pour n'inclure que les capacités spécifiques requises pour sa build.

Salut ,

J'ai déjà signalé cela avant, même problème.

Qu'en est-il de ceux qui souhaitent simplement exécuter un conteneur par machine virtuelle avec le même identifiant utilisateur sur la machine virtuelle et le conteneur, en utilisant docker comme outil de packaging ?

Y a-t-il toujours un problème de sécurité lié à cela?

Couru dans ce problème. Pourrait vraiment utiliser des capacités pour la construction.

J'ai aussi rencontré ce problème.
C'est très utile lors de l'utilisation de docker en tant qu'esclaves CI/CD, ce qui peut nécessiter une autorisation privilégiée sur docker build pour installer les chaînes d'outils de construction/test CI/CD lors de la création de l'image docker esclave.
J'attends cette fonctionnalité depuis des années et j'espère vraiment qu'elle pourra être prise en charge à l'avenir.

Je ne comprends vraiment pas pourquoi il y a tant de recul de la part des développeurs concernant --privileged for docker image.
Si les utilisateurs veulent se tirer une balle dans le pied, pourquoi ne pas les laisser faire ? Il suffit de mettre un message d'avertissement et c'est tout. Il existe déjà des solutions de contournement pour obtenir la même chose, pourquoi ne pas faciliter la tâche aux utilisateurs qui en ont vraiment besoin ??
Cela fait 4-5 ans et il n'y a eu aucun progrès à ce sujet.
Juste incroyable...

À ce jour, même cette fonctionnalité n'a pas encore été implémentée :
RUN --cap-add=SYS_PTRACE
qui répondrait aux besoins de nombreux utilisateurs.

Pourriez-vous s'il vous plaît suggérer comment je peux construire ce Dockerfile sur l'hôte Gentoo Linux :

FROM gentoo/stage3-amd64
# Download and extract latest portage
RUN wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2 && \
    wget http://distfiles.gentoo.org/snapshots/portage-latest.tar.bz2.md5sum && \
    md5sum -c portage-latest.tar.bz2.md5sum 
RUN tar -xjvf portage-latest.tar.bz2 -C /usr
RUN emerge dev-lang/go

parce que je reçois cette erreur lors de l'émergence de dev-lang/go :

##### Building Go bootstrap tool.
cmd/dist
 * /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/trace.c:_do_ptrace():75: failure (Operation not permitted):
 * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x0000000000000000, 0x0000000000000000): Operation not permitted
/usr/lib64/libsandbox.so(+0xb692)[0x7fd10e265692]
/usr/lib64/libsandbox.so(+0xb778)[0x7fd10e265778]
/usr/lib64/libsandbox.so(+0x6259)[0x7fd10e260259]
/usr/lib64/libsandbox.so(+0x6478)[0x7fd10e260478]
/usr/lib64/libsandbox.so(+0x7611)[0x7fd10e261611]
/usr/lib64/libsandbox.so(execve+0x3f)[0x7fd10e2634ff]
bash[0x41d8ff]
bash[0x41f387]
bash[0x420138]
bash[0x4219ce]
/proc/330/cmdline: bash ./make.bash 

 * ERROR: dev-lang/go-1.9.2::gentoo failed (compile phase):
 *   build failed
 * 
 * Call stack:
 *     ebuild.sh, line 124:  Called src_compile
 *   environment, line 1034:  Called die
 * The specific snippet of code:
 *       ./make.bash || die "build failed"
 * 
 * If you need support, post the output of `emerge --info '=dev-lang/go-1.9.2::gentoo'`,
 * the complete build log and the output of `emerge -pqv '=dev-lang/go-1.9.2::gentoo'`.
 * The complete build log is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-lang/go-1.9.2/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-lang/go-1.9.2/work/go/src'
 * S: '/var/tmp/portage/dev-lang/go-1.9.2/work/go'

Comment puis-je l'exécuter sans --cap-add=SYS_ADMIN --device /dev/fuse ou --privileged ?

RUN apt-get -y install unionfs-fuse
RUN unionfs-fuse -o cow dir1=RW:dir2=RO dir3/

Je peux le faire avec un fichier bash séparé dans le point d'entrée, mais j'ai besoin d'un seul Dockerfile

@amd-nick qu'attendez-vous de la ligne RUN unionfs-fuse ... pendant la construction ? Même si cela fonctionnait, le système de fichiers ne serait monté que pendant ce seul RUN , et serait parti à l'étape suivante.

@thaJeztah c'est difficile à expliquer pour moi. J'essaye de modifier ce repo . Puis-je simplement sauter cette ligne sur le bâtiment ?

salut

Au hasard, la construction du docker choisit un nom d'hôte commençant par zéro « 0 » qui casse notre application, j'ai essayé d'exécuter « nom d'hôte » dans ce cas dans mon DockerFile mais j'ai rencontré le même problème.

J'aimerais également avoir une option pour exécuter la construction de docker avec RUNP ou obtenir une option pour choisir le nom d'hôte pendant la construction.

Quelqu'un a-t-il essayé de construire ce genre d'images avec Kaniko ? Je viens de le faire avec le Dockerfile de @maneamarius sur Docker pour Mac et il semble se construire avec succès une fois que vous appelez la commande "build" docker run Kaniko avec --cap-add=SYS_PTRACE . Cependant, j'ai un peu de mal à charger localement l'archive tar résultante, l'utilisation de la RAM est un peu élevée car elle ne peut pas utiliser les overlayfs, et la mise en cache des couches est toujours WIP. Les choses pourraient bien fonctionner si je pousse vers un registre, mais je n'ai pas encore essayé.

docker run --cap-add=SYS_PTRACE --rm -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest --dockerfile=Dockerfile --context=/workspace --tarPath=/workspace/test.tar --destination=test  --single-snapshot

Avoir cette fonctionnalité aiderait grandement les efforts pour créer des images Docker via Puppet sur des images de base Redhat/CentOS.

Depuis ma dernière publication, j'ai suivi les changements dans Kaniko . Ils ne sont plus archivés en mémoire et archivés sur le disque, ce qui signifie la prise en charge des Dockerfiles décrivant de grandes images. La mise en cache de la couche est encore WIP mais ils ont une option pour mettre en cache les images de base pour le moment (Cela signifie actuellement pas rapide RUN itération enregistrer et exécuter genre de travail , mais nous pouvons mettre en cache alpine , ubuntu , et quelles que soient les bases populaires disponibles).

C'est à un stade où j'ai réussi à créer le @maneamarius qui émerge Golang dans une image Gentoo dans ce projet/démo sans modifier le Dockerfile de @maneamarius ou le découper de quelque manière que ce soit ( EDIT : j'ai depuis a dû modifier le Dockerfile pour épingler l'image de base gentoo à la version qui était latest au moment de ce post. Sinon, elle n'est toujours pas modifiée. ) :

https://github.com/nelsonjchen/kaniko-privileged-maneamarius-moby-1916

J'ai également configuré Azure Pipelines pour créer le Dockerfile dans une image avec Kaniko avec --cap-add=SYS_PTRACE , charger l'archive de sortie de Kaniko et exécuter go version dans l'image générée. J'ai pensé qu'une "preuve de vie" interactive serait intéressante. Certains des commentaires précédents ici concernaient également les systèmes CI, alors j'ai pensé que je configurerais un système CI public pour qu'il fonctionne également. BTW, Travis CI a été pris en compte mais la sortie de build était trop longue et elle s'est terminée et Azure est parfaitement satisfait de 166 000 lignes de sortie. Si le Dockerfile était construit avec environ 70 000 lignes de sortie en moins, il aurait probablement réussi sur Travis CI. Un lien vers les sorties de build Azure Pipeline se trouve en haut du fichier README.

Utiliser buildah Luke

Je ferme ce problème, car la fonctionnalité est maintenant disponible en tant que docker buildx build --allow security.insecure

https://github.com/docker/buildx/blob/master/README.md# --allowentitlement
https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run ---securityinsecuresandbox

@AkihiroSuda J'ai mis à jour mon docker vers la version 19.03 pour essayer buildx . Quand j'essayais la commande que vous avez mentionnée, cela me donne une erreur

$ docker buildx build --allow security.insecure -t sample-petclinic -f Dockerfile .
[+] Building 0.0s (0/0)                                                                                                                                                         
failed to solve: rpc error: code = Unknown desc = entitlement security.insecure is not allowed

Docker version :

Client: Docker Engine - Enterprise
 Version:           19.03.2
 API version:       1.40
 Go version:        go1.12.8
 Git commit:        c92ab06
 Built:             Tue Sep  3 15:57:09 2019
 OS/Arch:           linux/amd64
 Experimental:      true

Server: Docker Engine - Enterprise
 Engine:
  Version:          19.03.2
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.12.8
  Git commit:       c92ab06
  Built:            Tue Sep  3 15:55:37 2019
  OS/Arch:          linux/amd64
  Experimental:     true
 containerd:
  Version:          1.2.6
  GitCommit:        894b81a4b802e4eb2a91d1ce216b8817763c29fb
 runc:
  Version:          1.0.0-rc8
  GitCommit:        425e105d5a03fabd737a126ad93d62a9eeede87f
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

documentation buildx : For entitlements to be enabled, the buildkitd daemon also needs to allow them with --allow-insecure-entitlement

Merci @AkihiroSuda . Cela a fonctionné maintenant.

juste pour ajouter un autre cas d'utilisation.
J'essaie de réparer une version dockerfile d'un conteneur ibmdb2 avec une base de données de test
IBM a supprimé l'image v10 du hub. Mais l'image DB v11 ne commence que par --privileged.
Ainsi, tout le code qui configure la base de données dans le Dockerfile n'est plus fonctionnel car le db2 ne démarre pas sans privilège. :(
Il semble y avoir une solution de contournement compliquée avec l'utilisation de docker run et docker commit.
Dans un pipeline de build productif, cela crée beaucoup de complexité supplémentaire.

Je dois demander comme https://github.com/maneamarius dans https://github.com/moby/moby/issues/1916#issuecomment -361173550

Pourquoi est-ce si important de soutenir cela ? La construction exécute une exécution sous le capot.

Dans ce cas d'utilisation spécifique, une option de construction privilégiée prendrait en charge une sorte de "compatibilité descendante" et je sais que je ne suis pas le seul à avoir eu ce problème après mes recherches sur le Web.

@uvwild Je ne sais pas si cela aide votre cas d'utilisation, mais vous pouvez essayer de construire avec kaniko Votre image sera construite sans démon docker et vous pourrez extraire l'image une fois que c'est fait et utiliser kaniko revient à exécuter un conteneur vous pouvez utiliser --privileged ou --cap-add <capability which is needed> qui pourraient résoudre votre problème.

J'accepte que ce n'est pas une solution complète que vous attendiez, mais une solution de contournement plus simple qui peut s'intégrer dans votre pipeline de construction.

EDIT : comme l'a dit @alexey-vostrikov, buildah pourrait être une solution plus réalisable pour les cas d'utilisation nécessitant --privileged pour créer une image