Question sur les droits des fichiers
Fermé
Renaud63
-
2 oct. 2011 à 20:02
mamiemando Messages postés 33093 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 4 mai 2024 - 3 oct. 2011 à 20:36
mamiemando Messages postés 33093 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 4 mai 2024 - 3 oct. 2011 à 20:36
A voir également:
- Question sur les droits des fichiers
- Wetransfer gratuit fichiers lourd - Guide
- Renommer plusieurs fichiers - Guide
- Explorateur de fichiers - Guide
- Fichiers dat - Guide
- Fichiers bin - Guide
3 réponses
mamiemando
Messages postés
33093
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
4 mai 2024
7 751
Modifié par mamiemando le 3/10/2011 à 10:16
Modifié par mamiemando le 3/10/2011 à 10:16
En fait il faut bien comprendre que les droits se décomposent en plusieurs couches. En allant des couches les plus basses aux couches les plus hautes :
1) le système de fichiers (que tu peux ignorer, mais si tu es curieux cf lsattr, chattr)
2) les droits débloqués par les options de montage : voir mount et /etc/fstab (options rw, ro, exec, noexec, uid, gid, umask...)
3) les droits unix (et éventuellement acl) (voir les commandes chmod, chown, chgrp, setfacl et getfacl)
4) quand tu passes par un serveur qui met à disposition des fichiers, les droits "émulés" par ce serveur.
Pour qu'une opération se déclenche avec succès, il faut que toutes ses couches de droits soient traversées avec succès (sinon... permission denied ! :p)
Il faut bien comprendre qu'un serveur peut avoir sa propre gestion d'utilisateur mais finalement, ça reste un processus qui tourne avec des droits unix. Les possibilités de ce serveur sont conditionnés par cet utilisateur. Par exemple un serveur mysql tourne en tant qu'utilisateur mysql, donc il ne peut altérer que des fichiers sur lequel l'utilisateur mysql a des droits en écriture.
Tu peux retrouver avec quel utilisateur tourne un processus grâce à la commande ps. Par exemple pour voir avec quel utilisateur tourne un serveur ssh :
... dans le cas présent, il s'agit de root (ce qui est normal pour ssh, mais en général un serveur tourne avec un utilisateur spécifique (par exemple mysql pour un serveur mysql)).
Ensuite il faut bien comprendre qu'en général quand tu fais un chmod, c'est généralement qu'on s'est planté quelque part (ou qu'on a copié des fichiers avec des mauvais droits). Relâcher des droits sous linux revient souvent à ouvrir des trous de sécurité. Sinon on ferait un chmod -R 777 / et là ce serait la catastrophe puisque tout le monde pourrait faire tout et n'importe quoi (je caricature bien entendu mais le but est de te faire sentir à quoi correspond relâcher des droits à l'extrême).
Prenons un exemple pour voir comment régler le problème proprement : j'ai une arborescence de fichier qui doit être modifiable par apache+web_dav (qui permet d'utiliser svn via http) (utilisateur www-data) et par un utilisateur toto qui se connecte en svn. Dans ce cas, je devrais faire appartenir cette arborescence à un groupe svn et donner des droits aux groupes svn, puis faire appartenir www-data et toto au groupe svn.
Rapidement on peut se dire que la gestion de groupes et d'utilisateur peut engendrer une politique de droits assez compliquée à modéliser avec les simples droits unix. Dans ce cas on a recours aux acl et c'est à mon avis ce qui sera le plus souple dans ton cas.
Plus de détails sur les droits et les acl :
http://www.mistra.fr/tutoriel-linux-profils-et-droits.html
http://doc.ubuntu-fr.org/acl
De manière générale tu dois faire en sorte de débloquer le moins de droits possibles pour limiter les risques d'intrusion ou de mauvaise utilisation. Typiquement si un utilisateur n'est pas sensé modifier un fichier, il ne devrait pas avoir de droits en écriture sur ce fichier.
Bonne chance
1) le système de fichiers (que tu peux ignorer, mais si tu es curieux cf lsattr, chattr)
2) les droits débloqués par les options de montage : voir mount et /etc/fstab (options rw, ro, exec, noexec, uid, gid, umask...)
3) les droits unix (et éventuellement acl) (voir les commandes chmod, chown, chgrp, setfacl et getfacl)
4) quand tu passes par un serveur qui met à disposition des fichiers, les droits "émulés" par ce serveur.
Pour qu'une opération se déclenche avec succès, il faut que toutes ses couches de droits soient traversées avec succès (sinon... permission denied ! :p)
Il faut bien comprendre qu'un serveur peut avoir sa propre gestion d'utilisateur mais finalement, ça reste un processus qui tourne avec des droits unix. Les possibilités de ce serveur sont conditionnés par cet utilisateur. Par exemple un serveur mysql tourne en tant qu'utilisateur mysql, donc il ne peut altérer que des fichiers sur lequel l'utilisateur mysql a des droits en écriture.
Tu peux retrouver avec quel utilisateur tourne un processus grâce à la commande ps. Par exemple pour voir avec quel utilisateur tourne un serveur ssh :
(mando@aldur) (~) $ ps aux | grep ssh root 1341 0.0 0.0 49636 1152 ? Ss 09:45 0:00 /usr/sbin/sshd mando 1899 0.0 0.0 12236 300 ? Ss 09:46 0:00 /usr/bin/ssh-agent /usr/bin/gpg-agent --daemon --sh --write-env-file=/home/mando/.gnupg/gpg-agent-info-aldur /usr/bin/dbus-launch --exit-with-session /usr/bin/startkde mando 2747 0.0 0.0 9856 888 pts/1 S+ 10:07 0:00 grep ssh
... dans le cas présent, il s'agit de root (ce qui est normal pour ssh, mais en général un serveur tourne avec un utilisateur spécifique (par exemple mysql pour un serveur mysql)).
Ensuite il faut bien comprendre qu'en général quand tu fais un chmod, c'est généralement qu'on s'est planté quelque part (ou qu'on a copié des fichiers avec des mauvais droits). Relâcher des droits sous linux revient souvent à ouvrir des trous de sécurité. Sinon on ferait un chmod -R 777 / et là ce serait la catastrophe puisque tout le monde pourrait faire tout et n'importe quoi (je caricature bien entendu mais le but est de te faire sentir à quoi correspond relâcher des droits à l'extrême).
Prenons un exemple pour voir comment régler le problème proprement : j'ai une arborescence de fichier qui doit être modifiable par apache+web_dav (qui permet d'utiliser svn via http) (utilisateur www-data) et par un utilisateur toto qui se connecte en svn. Dans ce cas, je devrais faire appartenir cette arborescence à un groupe svn et donner des droits aux groupes svn, puis faire appartenir www-data et toto au groupe svn.
Rapidement on peut se dire que la gestion de groupes et d'utilisateur peut engendrer une politique de droits assez compliquée à modéliser avec les simples droits unix. Dans ce cas on a recours aux acl et c'est à mon avis ce qui sera le plus souple dans ton cas.
Plus de détails sur les droits et les acl :
http://www.mistra.fr/tutoriel-linux-profils-et-droits.html
http://doc.ubuntu-fr.org/acl
De manière générale tu dois faire en sorte de débloquer le moins de droits possibles pour limiter les risques d'intrusion ou de mauvaise utilisation. Typiquement si un utilisateur n'est pas sensé modifier un fichier, il ne devrait pas avoir de droits en écriture sur ce fichier.
Bonne chance
Bonjour et merci beaucoup pour ta réponse très complète...et euh...complexe aussi, un peu, cette question de droits.
Je ne comprends pas trop cette notion de ACL, même si je capte la notion de ne pas ouvrir tout aux quatre vents.
Dans mon cas précis, je suis le seul utilisateur ayant accès à tout.
Les autres n'ont que des accès web, une interface, et appuient sur des boutons de formulaires très bridés et contrôlés.
Mais les scripts PHP qui font tourner tout ça ont besoin de créer des fichiers, d'écrire dedans, de les supprimer...
Et je voulais éviter la fastidieuse tâche d'accorder des 666 par-ci et des 777 par-là sur tout ce qui peut être concerné par les scripts PHP (multiplié par le nombre de sites...).
- Lorsque je transfère un fichier via FTP, le proprio est "login-ftp".
- Dès qu'un script PHP crée ou modifie un fichier, le proprio devient Apache
Et à partir de là, les ennuis commencent.
Ayant fait des recherches, j'ai vu qu'on pouvait passer le umask du serveur à 000 au lieu de 022 dans etc/proftpd.conf mais je ne vois pas trop bien la portée de cette action (donc je m'abstiens)...mais bref, je suis paumé.
EDIT : j'ai le même type de site qui tourne sur un mutualisé ordinaire et tout fonctionne sans se préoccuper des droits. Quel est donc le réglage qui permet ça ? Pourquoi n'est il pas possible sur mon dédié ?
Je ne comprends pas trop cette notion de ACL, même si je capte la notion de ne pas ouvrir tout aux quatre vents.
Dans mon cas précis, je suis le seul utilisateur ayant accès à tout.
Les autres n'ont que des accès web, une interface, et appuient sur des boutons de formulaires très bridés et contrôlés.
Mais les scripts PHP qui font tourner tout ça ont besoin de créer des fichiers, d'écrire dedans, de les supprimer...
Et je voulais éviter la fastidieuse tâche d'accorder des 666 par-ci et des 777 par-là sur tout ce qui peut être concerné par les scripts PHP (multiplié par le nombre de sites...).
- Lorsque je transfère un fichier via FTP, le proprio est "login-ftp".
- Dès qu'un script PHP crée ou modifie un fichier, le proprio devient Apache
Et à partir de là, les ennuis commencent.
Ayant fait des recherches, j'ai vu qu'on pouvait passer le umask du serveur à 000 au lieu de 022 dans etc/proftpd.conf mais je ne vois pas trop bien la portée de cette action (donc je m'abstiens)...mais bref, je suis paumé.
EDIT : j'ai le même type de site qui tourne sur un mutualisé ordinaire et tout fonctionne sans se préoccuper des droits. Quel est donc le réglage qui permet ça ? Pourquoi n'est il pas possible sur mon dédié ?
mamiemando
Messages postés
33093
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
4 mai 2024
7 751
Modifié par mamiemando le 3/10/2011 à 20:36
Modifié par mamiemando le 3/10/2011 à 20:36
Pour faire simple les droits unix (qui se déclinent sous la forme de trois triplets rwx) ne sont pas toujours suffisans pour définir une politique de droits complexe. C'est là que les ACL interviennent.
Dans ton cas login-ftp (l'utilisateur associé au processus ftp) et www-data (l'utilisateur apache) doivent appartenir à un même groupe (que tu crées par exemple avec groupadd) et dans lequel tu mets ces deux utilisateurs (en corrigeant /etc/group).
Ensuite il suffit d'attribuer ces fichiers à ce groupe et de donner les droits que tu veux à ce groupe (deuxième triplet rwx). En particulier, il faut que ce groupe ait les droits en écriture dans le répertoire dans lesquels apache et ftp sont susceptible de créer des fichiers. En tout cas il n'y a a priori aucune raison de donner des droits à tout le monde (troisième triplet). Les chmod seraient donc plutôt du genre 770 ou 660.
En résumé ;
On ajoute dans mongroupe login-ftp et wwww-data :
Puis on corrige les droits
Bonne chance
Dans ton cas login-ftp (l'utilisateur associé au processus ftp) et www-data (l'utilisateur apache) doivent appartenir à un même groupe (que tu crées par exemple avec groupadd) et dans lequel tu mets ces deux utilisateurs (en corrigeant /etc/group).
Ensuite il suffit d'attribuer ces fichiers à ce groupe et de donner les droits que tu veux à ce groupe (deuxième triplet rwx). En particulier, il faut que ce groupe ait les droits en écriture dans le répertoire dans lesquels apache et ftp sont susceptible de créer des fichiers. En tout cas il n'y a a priori aucune raison de donner des droits à tout le monde (troisième triplet). Les chmod seraient donc plutôt du genre 770 ou 660.
En résumé ;
addgroup mongroupe
On ajoute dans mongroupe login-ftp et wwww-data :
nano /etc/group
Puis on corrige les droits
chgrp mongroupe -R /repertoire/pour/lequel/il/faut/donner/des/droits
find /repertoire/pour/lequel/il/faut/donner/des/droits -type f -exec chmod 660 {} \;
find /repertoire/pour/lequel/il/faut/donner/des/droits -type d -exec chmod 770 {} \;
Bonne chance
3 oct. 2011 à 10:21