web-dev-qa-db-fra.com

Pourquoi le conteneur docker invite-t-il "Autorisation refusée"?

J'utilise la commande suivante pour exécuter un conteneur docker et mapper un répertoire de l'hôte (/root/database) au conteneur (/tmp/install/database): 

# docker run -it --name Oracle_install -v /root/database:/tmp/install/database bofm/Oracle12c:preinstall bash

Mais dans le conteneur, je ne peux pas utiliser ls pour lister le contenu dans /tmp/install/database/ bien que je sois root et que je dispose de tous les privilèges: 

[root@77eb235aceac /]# cd /tmp/install/database/
[root@77eb235aceac database]# ls
ls: cannot open directory .: Permission denied
[root@77eb235aceac database]# id
uid=0(root) gid=0(root) groups=0(root)
[root@77eb235aceac database]# cd ..
[root@77eb235aceac install]# ls -alt
......
drwxr-xr-x. 7 root root  4096 Jul  7  2014 database

Je vérifie /root/database dans l'hôte et tout semble aller pour le mieux: 

[root@localhost ~]# ls -lt
......
drwxr-xr-x.  7 root root       4096 Jul  7  2014 database

Pourquoi le conteneur docker invite-t-il "Autorisation refusée"? 

Mettre à jour:
La cause fondamentale est liée à SELinux. En fait, j'ai rencontré un problème similaire numéro l'année dernière.

linuxdockerpermissionspermission-denieduser-permissions
7
Nan Xiao

Une autorisation refusée dans un conteneur pour un répertoire partagé peut être due au fait que ce répertoire partagé est stocké sur un périphérique. Par défaut, les conteneurs ne peuvent accéder à aucun périphérique. L'ajout de l'option $docker run --privileged permet au conteneur d'accéder à all devices et d'effectuer des appels du noyau. Ceci n'est pas considéré comme sécurisé.

Une méthode plus simple pour partager un périphérique consiste à utiliser l'option docker run --device=/dev/sdb (si /dev/sdb est le périphérique que vous souhaitez partager).

De la page de manuel:

  --device=[]
      Add a Host device to the container (e.g. --device=/dev/sdc:/dev/xvdc:rwm)

  --privileged=true|false
      Give extended privileges to this container. The default is false.

      By default, Docker containers are “unprivileged” (=false) and cannot, for example, run a Docker daemon inside the Docker container. This is because by default  a  container is not allowed to access any devices. A “privileged” container is given access to all devices.

      When  the  operator  executes  docker run --privileged, Docker will enable access to all devices on the Host as well as set some configuration in AppArmor to allow the container nearly all the same access to the Host as processes running outside of a container on the Host.
4
Auzias

J'ai eu un problème similaire lors du partage d'un point de montage NFS en tant que volume à l'aide de docker-compose. J'ai pu résoudre le problème avec:

    docker-compose up --force-recreate

Même si vous avez trouvé le problème, cela peut aider quelqu'un d'autre.

0
d g

Une autre raison est une incompatibilité avec l'UID/GID. Cela se traduit souvent par la possibilité de modifier un montage en tant que root, mais pas en tant qu’utilisateur des conteneurs.

Vous pouvez définir l'UID. Ainsi, pour un conteneur ubuntu s'exécutant sous ubuntu, vous devrez peut-être ajouter :uid=1000 (vérifier avec id -u) ou définir localement l'UID, selon votre cas d'utilisation.

uid = valeur et gid = valeur

Définit le propriétaire et le groupe des fichiers dans le système de fichiers (par défaut: uid = gid = 0)

Il y a un bon blog à ce sujet ici avec cet exemple tmpfs

docker run \
       --rm \
       --read-only \
       --tmpfs=/var/run/prosody:uid=100 \
       -it learning/tmpfs

http://www.dendeer.com/post/docker-tmpfs/

0
KCD