Permissions et Services / Bug?????

[Tex-Mex]

Bonjour,

Environnement :

• DS916+
• DSM 6.1.2-15132
• Volume BtrFs
• Linux Debian / Win 7

 

En partageant un dossier avec 2 utilisateurs (1 Windows et 1 Linux via NFS) je me suis retrouvé confronté à un problème bizarre (oui j’ai dit bizarre).

Le serveur Apache du Linux sort une erreur "403, Forbidden" dans les cas ou les permissions sur les fichiers ne sont pas bonnes. Facile ! Un petit coup de « chmod -R 755 (ou 644) » règle le problème généralement.

Mais si les permissions sont conformes sur les fichiers, alors il reste le cas des pseudo répertoires "." et ".." qui sont à modifier. Apache y est sensible. Mais Windows aussi. Il y a quelques petites gènes ici ou là en attendant d’avoir remis d’équerre le pseudo répertoire « . ».

Je me suis donc retrouvé dans ce cas. Seulement voila cela vient apparemment du DSM.

Lorsque l'on modifie les droits sur les répertoires partagés, le DSM modifie aussi les pseudo répertoires "." et "..". En tout cas, il les place dans des permissions non conforme.

On se retrouve avec des permissions loufoques du type 777 sur « . » et « .. ». Cela pourri l’affichage dans le terminal. Enfin plutôt ; ça fait un effet sapin de Noël. Cela perturbe aussi les services qui ont besoin de remonter et évaluer toute l’arborescence comme Apache.

 

C’est aussi porteur de non-sens au niveau de la gestion des droits sur le DSM. Si on fait une modification du pseudo répertoire « . » ou « .. » avec un chmod, l’affichage dans le DSM des droits s’en ressent plus ou moins fortement (Surtout « .. »).

On obtient différentes choses en fonction de ce que l’on a fait dans :

• File Station / clic droit / propriété / permissions / utilisateur (application des permissions comme dans Windows). On peut voir la mention « personnalisé ».
• « Panneau de configuration / Dossier partagé / Permission » ainsi que « Panneau de configuration / Utilisateur (ou groupe) / Permission » : Affiche la perte des droits alors que cela fonctionne pour l’utilisateur NFS. C’est l’affichage qui est incorrecte. Ou pour un autre utilisateur Windows cela interdira une opération alors que d’après le DSM, l’utilisateur a les droits. Mention « personnalisé » présente aussi.

C’est une bonne chose que l’affichage du DSM se base sur la lecture du répertoire à la volé. Maintenant cela produit ce genre de gloubiboulga en fonction de l’état du répertoire.

 

Apparemment il faut que le pseudo répertoire « . » de la racine du partage (point de montage) soit en 777. Ce n’est pas impactant pour les services et les partages. Mais c’est visible sur le Linux et le DSM (ssh).

 

Le problème se règle avec un script shell du genre :

Citation

REPERTOIRE=`find /mnt/Espace_Developpement/Developpement_Web -type d`
for DIR in $REPERTOIRE
do
    cd $DIR
    chmod 755 .
done

Toutefois on ne devrait pas le faire.

 

NB :

En testant j’ai à chaque fois appliqué/vérifié les droits via :

• Panneau de configuration / Dossier partagé / Permission
• Panneau de configuration / Utilisateur (ou groupe) / Permission
• File Station / clic droit / propriété / permissions

Mon utilisateur Linux à le même numéro ID et GID que celui du DSM histoire de pas se compliquer la vie.

Qui peut tester pour voir (histoire de pas faire un ticket avec le support pour rien) ? Pour moi cela ressemble à un vilain bug. Est ce lié à BtrFs ?

En tout cas c’est un comportement non conforme puisqu’il mène à la problématique d’Apache mentionné plus haut. J’imagine que les personnes peu expérimentées vont bloquer dessus.

 

[Fenrir]

C'est surtout lié au fait que DSM fait une utilisation intensive (et parfois abusive) des ACL en plus des droits classiques.

Donc les droits classiques "visibles" (par un ls -l) ne sont pas les droits "effectifs" (visibles avec ls -le).

Il y a 10 heures, Tex-Mex a dit :

il reste le cas des pseudo répertoires "." et ".." qui sont à modifier. Apache y est sensible

. et .. ne sont pas des "pseudos" répertoires, c'est juste un affichage de la commande LS pour connaitre les droits du dossier courant (.) et du parent (..) et je ne vois pas en quoi ça gène apache (mais je n'ai pas testé) ?

[Tex-Mex]

Bonjour,

 

"pseudo": c'est pour être accessible au commun des mortels.

Pour Apache : il remonte toute l'arborescence pour vérifier les droits. Et si un truc lui plaît pas sur sa remonté (dont je comprend mal l'utilité) il sort cette erreur.
un peu de doc ici : https://wiki.apache.org/httpd/13PermissionDenied
(permission denied figure dans les log Apache quand il sort la 403 dans le navigateur)

 

Heu ls -le; ma Debian ne connaît pas.

 

[Fenrir]

J'avais compris que le serveur apache était celui de DSM (j'ai mal lu ton premier message).

La seule permission demandé par Apache c'est le droit de lire les dossiers et les fichiers et comme sous Linux on ne créé par de tunnel de droits, ça implique d'appliquer les droits depuis la racine. De plus Apache est lancé avec un utilisateur système (www-data sur Debian, avec un id de 33 par défaut), le fait que tu utilisateur ait le même id/gid sur ta Debian et ton Syno n'apporte rien pour Apache.

Comme tu es en NFS, ton point de montage doit bien être en 777. Les permissions des dossiers enfants doivent au moins permettre à www-data de lire les dossiers (+rX) et les fichiers (+r) =>chmod -R a-x,u+rwX,g+rX,o+rX /mnt/Espace_Developpement/Developpement_Web

Le hic, comme tu l'as remarqué, c'est que le Syno change ces permissions avec des ACL, les droits Unix de base sont donc surchargés, mais si tu autorises le groupe "others" du syno à lire le dossier, ça devrait fonctionner. Ça dépend aussi de tes options d'export sur le Syno (paramètres du montage NFS dans DSM).

Pour compliquer le tout, tu utilises ce même dossier depuis Windows (qui lui ne connait pas les droits Unix)

=>En résumé, il y a tellement de combinaisons de droits en parallèle qu'il n'est pas surprenant que tu rencontres quelques désagréments. Dans ce genre de configuration (windows + linux qui utilisent un même partage), je recommande de passer en SMB à la place de NFS car Linux sait très bien utiliser SMB alors que Windows ne sait pas travailler correctement avec NFS.

Pour vérifier l'arborescence des droits tu peux utiliser la commande namei sur ta Debian : namei -lm /mnt/Espace_Developpement/Developpement_Web

Exemple sur un serveur dont le dossier www est un point de montage NFS :

namei -lm /var/www/exemple.com/
f: /var/www/exemple.com/
drwxr-xr-x root     root     /
drwxr-xr-x root     root     var
drwxrwxrwx root     root     www
drwxr-xr-x www-data www-data exemple.com

--

Il y a 3 heures, Tex-Mex a dit :

Heu ls -le; ma Debian ne connaît pas.

C'est parce que tu n'utilises pas d'ACL sur ta Debian, la commande est pour le Syno

[Tex-Mex]

Hmmm...

Les droits étaient bons pour www-datas. Il fait partie du groupe Linux possédant le dossier. Il aurait du pouvoir au moins le lire. Surtout en 777. Mais c'est ce "." qui est la clé de tout. En 775 ça passe.

 

NB: Coté Synology les deux utilisateurs Win et Linux sont dans le même groupe. L'un accédant via NFS bien entendu. Donc pas gênant. Et sur le Linux www-data fait partie du même groupe que l'utilisateur propriétaire.

 

Ca voudrait dire que le Linux se référerait le Synology lors de appels. C'est aussi ce qui me semble bizarre. Un fois monté les droits auraient du fonctionner.

On peut imaginer de créer un utilisateur sur le Synololgy quoique que je trouve cela un peu tiré par les cheveux.
 

[Fenrir]

J'avais commencé à faire une réponse détaillées, mais j'ai l'impression qu'on ne se comprends pas (c'est peut être moi qui interprète mal tes réponses).

Tu peux faire tout ce que tu veux comme chmod/chown avec ta Debian sur les dossiers montés via NFS, le nas et en particulier les ACL auront toujours le dernier mot, si tu fais un changement de droits via le Syno (avec filestation par exemple, ou en déposant un fichier en SMB), il est probable que ton chmod saute => c'est normal

Selon que tu fais du NFSv3 ou v4, les ACL sont affichées et interprétées différemment (tu peux tester nfs4_getfacl sur ton dossier) : http://wiki.linux-nfs.org/wiki/index.php/ACLs

Un point important que j'ai oublié de mentionner, tes options de montage (sec=XXX par exemple, ou encore nfsver=XXX) ont aussi un impact.

Si tu tiens à avoir des droits cohérents entre le Syno, ton windows et ta Debian, tu dois passer par Kerberos. Tu peux aussi essayer avec noacl (NFSv3 ou moins).

Et encore une fois, ton fameux ".", c'est simplement le dossier courant.

[Tex-Mex]

L O

Je sais que "." c'est le dossier courant. Seulement Apache (sur le Linux) il aime pas quand il voit 777 dessus (au point de montage ou plus bas). En 775 ça marche. "Va comprendre Charles".

Pour la cohérence des droits ça passe à partir du moment ou les utilisateurs sont dans les bons groupes (que les IDs correspondent aussi). C'est l'avantage que j'ai de pouvoir tout contrôler sur le NAS et les deux clients. Ca se comporte même plutôt bien au niveau cohérence. Tout le monde est dans la même famille. Seulement il y a cette bizarrerie avec Apache sur le Linux.

 

Ce qui me chiffonne c'est :

Citation

" Lorsque l'on modifie les droits sur les répertoires partagés, le DSM modifie aussi les pseudo répertoires "." et "..". En tout cas, il les place dans des permissions non conforme. "

NB : en tout cas cela se voit comme cela sur le Linux.

 

Si je change des droits en mode "dossier et ses sous éléments", je retrouverai des droits foireux sur "." et "..". D’ailleurs cela donne un sapin de Noêl dans le terminal couleur.

C'est pas que je ne m'en tirerais pas. Mais cela oblige à faire du script ou de le modifier à la main. "." et ".." devraient en règle générale être en 775 grand max et pas 777. Cela rime à rien 777, surtout si ça fait offusque Apache.

 

PS: c'est NFS4 monté en rw, defaults