Aller au contenu

Droits D'acc


Yokav

Messages recommandés

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. :(

Lien vers le commentaire
Partager sur d’autres sites

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

Lien vers le commentaire
Partager sur d’autres sites

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à.

Lien vers le commentaire
Partager sur d’autres sites

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é par CoolRaoul
Lien vers le commentaire
Partager sur d’autres sites

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. :blink:

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.

Lien vers le commentaire
Partager sur d’autres sites

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.

Lien vers le commentaire
Partager sur d’autres sites

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.