chown et chmod sur les volumes docker

[Taribam]

Bonjour,

Dans un soucis de sécurité, en utilisant les PUID et PGID d'un utilisateur DSM dans le docker-compose, l'idéal est-il qu'il soit propriétaire du dossier /volume1/Docker/XXXXXX et quels sont les droits minimaux a donner au dossiers et fichiers (chmod...) ?

Par ailleurs, je ne suis pas sûr d'avoir tout compris à ce niveau car lorsque je fais un "ps aux | grep contener_quelqonc" l'utilisateur qui l'execute est root...

Taribam 

 

[.Shad.]

C'est vrai que ce n'est pas des plus évidents, je vais essayer de t'expliquer ça.

Les variables PUID et PGID sont un moyen de translater un utilisateur à l'intérieur du conteneur vers un utilisateur sur l'hôte.

Prenons Linuxserver, ils utilisent généralement un utilisateur "abc" à l'intérieur du conteneur. Dans le conteneur, cet utilisateur est propriétaire des fichiers propres à la config, ça ne représente qu'une toute petite part des fichiers, le reste étant majoritairement propriété de root:root.

S'il n'y avait pas ce système de translation, et si tu décidais de faire persister ces fichiers sur l'hôte, tu verrais un ID pour l'uid et le gid, ID qui correspond à celui de abc dans le conteneur, mais qui sur le NAS ne correspondrait très probablement à rien. D'où le fait de voir l'ID s'afficher sur un "ls" par exemple et non pas un utilisateur existant.

Donc pour éviter ces problèmes de droit, Linuxserver te propose de lui donner un utilisateur à faire correspondre à leur utilisateur abc. Et sur les dossiers sur l'hôte qui vont contenir ces données, il faudra que l'utilisateur dont tu renseignes l'uid et le gid respectivement dans PUID et PGID puisse lire, écrire et exécuter.

Sur un bête Linux, ça se traduit généralement par exemple par un chmod 744 ou 755. Ainsi abc a contrôle total sur le dossier.
Sur DSM, tu as une surcouche d'ACL, qui disparaît au passage lorsque tu chmod un fichier/dossier.

Si tu ne renseignes pas de valeur pour PUID et PGID, par défaut abc sera translaté vers l'utilisateur root de ton hôte (pour s'assurer que ça fonctionne dans tous les cas).

Tout ce qui est évoqué ci-avant n'a rien à voir avec QUI exécute le conteneur, car par défaut, ça reste root.
C'est ce que tu constates dans ton impression d'écran.
Pour changer cela, tu as la directive --user en ligne de commande ou user: via docker-compose :

user: 1026:100

Ici, je dis que c'est l'user 1026 appartenant au groupe 100 qui exécute le conteneur.

Attention que du coup, c'est cet utilisateur qui va exécuter les binaires à l'intérieur du conteneur. Ces ID correspondant à un utilisateur sur le NAS, il est très peu probable que ton application fonctionne comme il faille. C'est à utiliser sur les images qui le prévoient seulement généralement (ou alors ça veut dire qu'ils mettent du +x pour les autres utilisateurs à tout bout de champ, ce qui ne serait pas spécialement rassurant 😄).

Mais quid du démon Docker dans tout ça ? Dans tous les cas, il est exécuté par root. Sauf si tu utilises Docker-Rootless, sorti récemment (non implémenté sur DSM).
Ca a le gros avantage de ne pas nécessiter une élévation de privilèges. Mais apparemment c'est encore très loin de proposer tout ce que propose Docker classique.

J'espère que ça a répondu à tes interrogations?

Modifié le 20 décembre 2021 par .Shad.

[Taribam]

Oui t'es explications sont très claires ! Et merci de prendre du temps pour des explications détaillées et compréhensibles. Mais quel pédagogue !

Ma confusion venait de lectures sur le fait qu'il serait problématique au niveau sécurité que root exécute les conteneurs, et qu'on pouvait utiliser les "usernamespace" de mémoire. j'étais persuadé qu'il s'agissait de ça... mais rien à voir 😇 

Modifié le 21 décembre 2021 par Taribam