Yokav Posté(e) le 23 novembre 2012 Partager Posté(e) le 23 novembre 2012 Bonjour, Cela fait un moment que j'utilise des NAS synology mais malgré tout, c'est un contexte que j'ai encore du mal à cerner. J'utilise plusieurs dossiers partagés, certains sur lesquels sont activés les règles ACL et d'autres non. Et j'accède à chaque dossier depuis Windows et Linux. Tant que l'on reste dans le cadre classique Windows <-> ACL tout va bien. Par contre lorsque l'on passe à Linux <-> ACL, voir même Linux <-> Permissions linux, ça devient plus compliqué. Prenons l'exemple de connexions au système de fichiers via samba, mais le problème est similaire avec d'autres services tel que le ftp. Sous linux, je me connecte via CIFS à un dossier partagé avec les permissions Linux. Là le problème se situe au niveau des permissions affectées par défaut, rien a été prévu pour spécifier un "directory mode" ou "file mode" sous DSM, faut donc rajouter ça manuellement dans le fichier de config de samba et le remettre à chaque lancement de samba. Sous linux, je me connecte via CIFS à un dossier partagé avec les permissions ACL. Là, faudrait que chaque dossier créé soit en chmod 777, malheureusement même avec le directory mode, j'arrive pas à dépasser le chmod 755. Résultat, même si on est dans un système ACL et qu'un utilisateur devrait pouvoir supprimer un dossier, si ce dernier est sous un chmod 755, ça ne passe pas. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 23 novembre 2012 Partager Posté(e) le 23 novembre 2012 Qu'on me corrige si je me trompe mais, quand les ACLs sont activées sur un dossier partagé, elles sont prioritaires sur les "modes" unix (en tous cas c'est ce que montrent les quelques tests que j'ai effectués). Et pas besoin de "directory mode" ou "file mode", suffit de placer des entrés d'acl par défaut (peut même se faire avec file station, pas besoin de Windows pour ça) Sous linux, je me connecte via CIFS à un dossier partagé avec les permissions ACL. PS: je suis toujours étonné du nombre de personnes qui choisissent l'option CIFS (protocole plutot orienté Windows) pour se connecter à partir d'un serveur Linux à un NAS Synology (Linux aussi) alors que NFS est disponible et est quand mème plus "natif" dans un mode unix<->unix 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 23 novembre 2012 Partager Posté(e) le 23 novembre 2012 (modifié) Voici le genre d'ACL sur un dossier qui permet de faire ce que tu demandes sur les dossiers/fichiers inclus créés par la suite: Modifié le 23 novembre 2012 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Yokav Posté(e) le 23 novembre 2012 Auteur Partager Posté(e) le 23 novembre 2012 Alors, le choix de CIFS s'explique par le fait que lors de diverses recherches, on mettait souvent ce protocole en avant car plus stable et permettant des vitesses de transfert plus importantes. J'ai néanmoins voulu remettre en place une connexion NFS récemment pour justement palier à ces problèmes de permissions mais ma connaissance de ce protocole s'avère bien limitée, j'ai été bloqué quand j'ai vu que l'on ne pouvait pas spécifier de login/mdp pour le montage d'un lecteur NFS. J'ai trouvé par la suite que les droits étaient visiblement donnés en fonction de l'adresse ip... Si tu peux m'en dire un peu plus à ce sujet, je suis preneur ! Et pour l'histoire du ACL, je suis persuadé de mon coup... bien que un peu tordu, il montre les limites de l'ACL. Voici la procédure à appliquer et qui prouve que l'ACL ne prend pas le dessus sur les permissions Linux. - On crée un dossier avec une règle ACL donnant les droits en lecture et écriture à tous les groupes pour ce dossier et ses sous-dossiers, fichiers, etc. - On se connecte en FTP avec un compte utilisateur A, on crée dans le dossier principal un sous-dossier nommé "Dossier A", on y ajoute quelques fichiers et ensuite on change le chmod de ce dossier en 755 (dans le but d'empêcher la suppression du contenu par tout autre utilisateur). - On se connecte en FTP avec un compte utilisateur B, même si selon la règle ACL on devrait pouvoir supprimer le contenu du sous-dossier "Dossier A" ça nous est impossible. Je rajouterais aussi que l'option "directory_mode" et "file_mode" est très importante ! Car elle va permettre de décider quel chmod sera appliqué lorsque l'on se connectera à un dossier partagé (avec des permissions Linux) depuis un ordi sous windows. Car par défaut un chmod 777 pour les dossiers et 700 pour les fichiers est appliqué de mémoire. Ce qui est un peu trop permissif à mon goût. Ça fait quand même ressortir le fait que c'est un joli méli-mélo à ce niveau là. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 23 novembre 2012 Partager Posté(e) le 23 novembre 2012 (modifié) Alors, le choix de CIFS s'explique par le fait que lors de diverses recherches, on mettait souvent ce protocole en avant car plus stable et permettant des vitesses de transfert plus importantes. J'ai néanmoins voulu remettre en place une connexion NFS récemment pour justement palier à ces problèmes de permissions mais ma connaissance de ce protocole s'avère bien limitée, j'ai été bloqué quand j'ai vu que l'on ne pouvait pas spécifier de login/mdp pour le montage d'un lecteur NFS. J'ai trouvé par la suite que les droits étaient visiblement donnés en fonction de l'adresse ip... Si tu peux m'en dire un peu plus à ce sujet, je suis preneur ! La restriction par IP est utilisée pour restreindre quel client (au sens "serveur" et pas "utilisateur") à le droit d'accéder au partage NFS Par contre, il n'est pas besoin de donner de login/mdp car les accès fichiers sont controlés en fonction des UIDs de comptes sur le client UNIX par rapport au serveur NAS Donc, chaque compte utilisateur de la machine UNIX accédera aux fichiers/répertoires du serveur NAS avec les droits du compte syno de *même* UID (numero de compte) En résumé on monte sous le Linux client le partage NFS de façon *globale* (system wide, au boot) et ensuite chaque utilisateur accède aux données en fonction des droits du compte NAS correspondant. Plusieurs utilisateurs connectés au linux simultanément pourront accéder au même moment aux contenu du partage NFS avec des droits différents. Et pour l'histoire du ACL, je suis persuadé de mon coup... bien que un peu tordu, il montre les limites de l'ACL. Voici la procédure à appliquer et qui prouve que l'ACL ne prend pas le dessus sur les permissions Linux. - On crée un dossier avec une règle ACL donnant les droits en lecture et écriture à tous les groupes pour ce dossier et ses sous-dossiers, fichiers, etc. - On se connecte en FTP avec un compte utilisateur A, on crée dans le dossier principal un sous-dossier nommé "Dossier A", on y ajoute quelques fichiers et ensuite on change le chmod de ce dossier en 755 (dans le but d'empêcher la suppression du contenu par tout autre utilisateur). - On se connecte en FTP avec un compte utilisateur B, même si selon la règle ACL on devrait pouvoir supprimer le contenu du sous-dossier "Dossier A" ça nous est impossible. Je rajouterais aussi que l'option "directory_mode" et "file_mode" est très importante ! Car elle va permettre de décider quel chmod sera appliqué lorsque l'on se connectera à un dossier partagé (avec des permissions Linux) depuis un ordi sous windows. Car par défaut un chmod 777 pour les dossiers et 700 pour les fichiers est appliqué de mémoire. Ce qui est un peu trop permissif à mon goût. Ça fait quand même ressortir le fait que c'est un joli méli-mélo à ce niveau là. Pas du tout: ce qui se passe en fait est que le serveur FTP du Syno interprète la commande "chmod" en modifiant les ACL afin que le résultat corresponde à ce qui est demandé (ce que je trouve même assez bien foutu). Extrait de la trace du dialogue FTP par FileZilla: Commande : SITE CHMOD 755 subsub Réponse : 200 CHMOD command successful. Tu peux aller vérifier le résultat final avec file station Modifié le 23 novembre 2012 par CoolRaoul 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Yokav Posté(e) le 26 novembre 2012 Auteur Partager Posté(e) le 26 novembre 2012 Merci pour cette réponse détaillée ! Pour l'histoire du ftp, mea-culpa, tu dois avoir raison. J'ai même de mal à reproduire l'exemple que j'ai décris. Pour le NFS par contre, ce n'est pas encore très clair, je vais faire quelques recherches sur google à ce propos. Les questions qui me viennent à l'esprit c'est comment faire pour "mapper" l'uid de l'utilisateur du pc sous linux et celui de l'utilisateur sur le syno. Et puis niveau sécurité, car une adresse ip et un uid, ça me semble un peu léger comme vérification. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
CoolRaoul Posté(e) le 27 novembre 2012 Partager Posté(e) le 27 novembre 2012 Pour le NFS par contre, ce n'est pas encore très clair, je vais faire quelques recherches sur google à ce propos. Les questions qui me viennent à l'esprit c'est comment faire pour "mapper" l'uid de l'utilisateur du pc sous linux et celui de l'utilisateur sur le syno. Sur DSM on n'a pas la maîtrise du choix de l'UID lorsque l'on créé un compte. DSM les alloue à partir de 1024. Par conséquent, pour que le meme compte utilisateur linux et DSM ait le meme uid, c'est sous le client Unix que tu dois modifier l'UID avec des commandes du genre usermod -u <nouveau uid> <username> find / -uid <ancien uid> | xargs chown <nouveau uid> Et puis niveau sécurité, car une adresse ip et un uid, ça me semble un peu léger comme vérification. Ca c'est un autre débat, mais en général lorsque le client et le serveur NFS sont situés à proximité (au sens topologie réseau donc sur le meme LAN, ce qui j'imagine doit être le cas pour toi entre ton NAS et ton Linux) on peux les considèrer comme une seule entité avec un modèle de sécurité unique (une sorte de "meta serveur" dont chaque élément fait confiance aux autres). Et pour ce qui concerne la sécurité basée sur l'IP, tu notera c'est ce modèle qu'utilisent les firewalls du Syno et des autres Linux en général (basés sur iptables) . Donc si tu n'y fais pas confiance tu dois te poser de la question de ne plus faire confiance au firewalls non plus. 0 Citer Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.