Bonjour,

• Synology DS918+
• DSM 7.1.1-42962 Update 3
• Utilisateurs : mongodb, portainer-ce, vaultwarden
• Groupe : docker
• Images : mongo:4.4.9 https://registry.hub.docker.com/_/mongo/, portainer/portainer-ce https://registry.hub.docker.com/r/portainer/portainer-ce/, vaultwarden/server:latest https://registry.hub.docker.com/r/vaultwarden/server/, 
• Dossier partagé : docker dans /volume1

Lorsque je suis connecté à DSM sur File Station avec mon compte administrateur (différent du compte utilisateur admin par défaut), je vois tous les sous-dossiers de /volume1/docker, à savoir : /volume1/docker/vaultwarden, /volume1/docker/portainer-ce et /volume1/docker/mongodb. Comme suit :

Lorsque je suis connecté à DSM sur File Station avec, mettons l'utilisateur mongodb, je vois exactement la même chose. D'un point de vue sécurité, ne serait-il pas plus sage de n'afficher que le sous-dossier /volume1/docker/mongodb (et pas les autres sous-dossiers) à l'utilisateur mongodb ? Si oui, comment faire puisque tous ces utilisateurs font partie du groupe docker ? Chacun voit actuellement les sous-dossiers des autres, ça me semble pas très safe. Idéalement, j'aimerais que l'utilisateur mongodb ne puisse même pas avoir d'accès en lecture aux dossiers des utilisateurs portainer-ce et vaultwarden. Masquer l'affichage de ces dossiers dans le File Station de l'utilisateur mongodb. Possible ?

L'option "Masquer les sous-dossiers et les fichiers des utilisateurs sans autorisations" est déjà cochée dans les paramètres du dossier partagé docker. Alors, étrange, non ?

Merci pour votre aide.

Cordialement,

 

Modifié le 12 janvier 20232 a par molinadiaz

Est-ce que tu as appliqué la propriété des dossiers via File Station ou via chmod en SSH ?

Il y a 2 heures, .Shad. a dit :

Est-ce que tu as appliqué la propriété des dossiers via File Station ou via chmod en SSH ?

Hello @.Shad.,

Via File Station. Cela dit, je pense que le comportement était normal, en fait. Certes, j'avais bien coché la case "Masquer les sous-dossiers et les fichiers des utilisateurs sans autorisations" dans les options du dossier partagé docker ... MAIS j'avais omis via File Station depuis mon compte administrateur de créer des permissions de type "Refuser / Contrôle Total" dans les propriétés de chaque sous-dossier de /volume1/docker/.

Par exemple, pour le dossier /volume1/docker/portainer-ce (dont l'utilisateur portainer-ce est le propriétaire), et avec des permissions "Refuser / Contrôle Total" pour les utilisateurs mongodb et vaultwarden :

De cette manière, et uniquement de cette manière, le dossier /volume1/docker/portainer-ce n'apparaît plus dans File Station lorsque connecté à DSM avec les utilisateurs mongodb et vaultwarden. Je crois qu'on ne peut pas isoler autrement, en fait.

J'avais éventuellement songé à arrêter d'utiliser /volume1/docker/dossier_par_container_propre_à_un_utilisateur pour faire tourner chaque container dans son home directory respectif, par exemple le container portainer-ce dans /volume/homes/portainer-ce, le container vaultwarden dans /volume1/homes/vaultwarden pour m'éviter d'enregistrer les permissions à la main comme sur le screenshot juste au-dessus, mais pour tout un tas de raison cette solution me semblait pas folle. Je crois que ça aurait justement poser problème si un jour un container devait partager plusieurs dossiers, non ?

Modifié le 13 janvier 20232 a par molinadiaz

DSM est régi par des ACL, les seules façons de t'assurer que des sous-dossiers d'un dossier partagé ne puissent être parcourus indifféremment sont :

- ce que tu as fait, càd mettre des règles des refus, elles sont prioritaires dans la résolution des permissions MAIS c'est fastidieux à gérer.
- chmod le dossier partagé docker, ça enlève la couche d'ACL, MAIS je ne pense pas que ce soit une bonne solution, car ça contrevient à la philosophie de DSM.

Si tu veux vraiment compartimenter, alors je te conseillerais de créer une VM minimale dans laquelle tu installes Docker et là ce sont des permissions UNIX, tu as les mains libres. Ca aurait l'avantage aussi de limiter les failles potentielles lié à l'utilisateur root, pour discuter de l'autre sujet que tu as ouvert concernant les utilisateurs exécutant les conteneurs. A toi de monter un maximum de volumes en lecture seule quand la finalité le permet.
Et ça ne change rien pour Portainer.

Souvent les écritures se font dans un dossier config ou data, les données elles-mêmes (musique, videos, documents, etc...) peuvent l'être en lecture seule.

Merci pour vos réponses @.Shad. @bliz !

Je crois que je vais rester comme ça. C'est un peu fastidieux à gérer la première fois (c'est le seul inconvénient, en soi) mais une fois que c'est paramétré, on est tranquille. Comme dit @.Shad., je ne veux pas chmod le dossier partagé docker pour les raisons évoquées.

Le coup de la VM minimale, ça ferait peut-être un peu trop de surcouche. Si je comprends bien, il y aurait DSM qui fait tourner Virtual Machine Manager (qui n'est pas installé chez moi, d'ailleurs), lui-même faisant tourner une VM légère comme Alpine Linux qui à son tour ferait tourner Docker, ce dernier exécutant mes containers ? 😅

À ce moment-là, je crois que je préférais encore faire tourner chaque container dans le home directory de son utilisateur. L'idée étant aussi de ne pas gonfler la RAM si une alternative plus légère est possible. Après tout, j'ai pas encore upgrade les barrettes du DS918+ 😂

@molinadiaz Oui c'est effectivement plus lourd, moi j'ai réglé le problème en déportant mes services sur une Debian, seules les données "dures" sont sur le NAS, et tout est monté par Samba.