[Résolu] A quoi servent les droits d'accès?

Bonjour

Une petite question que je ne m'étais jamais posée: à quoi servent les droits d'accès?

Les droits d'accès aux répertories et aux fichiers UNIX, généralement représentés en octal (700) ou par des chaînes de caracteres de genre rwx------ ne m'ont jamais posé de problème depuis qu'UNIX existe, et même avant, car je les utilisais sur le prédécesseur d'Unix, connu sous le nom de Multics dans les années 1970.

Je viens cependant de découvrir un phénomène intéressant, qui me conduit à réexaminer la question: DANS UN CONTEXTE DE SITE WEB à quoi servent les droits d'accès?

Je participe entre autres activités bénévoles à la maintenance d'un site web hébergé au delà de nos frontières.
Pour aider à cette opération, j'ai écrit un programme PHP qui devait créer un fichier sur ce site. Au moment de l'écriture je constate une erreur PHP "vous n'avez pas les droits d'accès". Après une semaine d'échanges par courriel avec l'hébergeur la réponse est en gros
1) contrairement aux autres hébergeurs, nous n'exécutons pas le PHP en mode "propriétaire" mais en mode "autre"
2) mais c'est pas grave: mettez donc les droits à 777 par CHMOD ça va marcher
J'ai bien essayé de mettre les droits par programme, mais comme je m'y attendais je n'avais pas les droits de faire un CHMOD !
Réponse de l'hébergeur: il faut le faire à la main.

Outre qu'il y a plusieurs centaines de répertoires et éventuellement des milliers de fichiers dont il faudrait manuellement modifier les droits d'accès, cela signifierait que tous ces répertoires et fichiers seraient en fait sans protection.
Mais si on va plus loin, on se demande dans quels cas (sauf pour enquiquiner ces c... de clients) ces droits sont effectivement utilisés.
Bien entendu, si quelqu'un écrit un programme sur le serveur, il peut faire n'importe quoi, c'est déjà le cas quels que soient les droits d'accès. Ces droits n'ont jamais été conçus pour empêcher le piratage par un programme vicieux, mais comme un moyen de limiter les risques de sortir de son territoire par bug dans un programme.

Mais sur un serveur Web, les seuls programmes qui s'exécutent sont ceux de gestion du serveur, nos "programmes PHP" sont en réalité des fichiers de données interprétés par l'interpréter PHP du serveur. C'est lui qui va vérifier qu'on a les droits d'accès et qu'on n'essaie pas de perturber le site du voisin en cas d'hébergement mutualisé.

En gros, il me semble que
1) soit les droits d'accès ne servent à rien, on ne risque rien en mettant les droits à 777, mais alors pourquoi mettre des droits d'accès?
2) soit il est important de les mettre car ils sont utilisés par l'interpréter PHP pour détecter les tentatives -- volontaires ou non -- d'écrire sur les fichiers du voisin
Dans les deux cas l'hébergeur se f... de ses clients, mais avant de lui dire son fait, j'aimerais vos opinions sur cette question.

Les droits d'accès sont très importants, et très utiles, que ce soit sur des répertoires, ou des fichiers.
Dans le contexte d'un site web, cela permet de gérer les autorisations de créations de fichiers par des scripts, et leur interprétation ou non, pas différents services / utilisateurs / autres
Par exemple, tu peux avoir un fichier dont toi seul "propriétaire" peut avoir les droits d'execution, ce qui empêchera par exemple quelqu'un avec l'url de ce fichier php de l’exécuter depuis l'extérieur.
Idem lors de l'utilisation de CMS. Il ne faut pas oublier qu'il est possible d'empêcher l'accès à un CMS à des répertoires par exemple, ou à un utilisateur extérieur d'afficher certaines choses en disposant de l'url.
Dans tout les cas, il n'est jamais possible de foutre le bordel sur le site d'un voisin sur un hébergement mutualisé.
Tout les comptes sont ce qui s'appelle "chrooté" et bien distincts les uns des autres.
Pour modifier les droits d'accès de miliers de fichiers / dossiers de manière récursive, tu peux utiliser la commande en mode récursif :

chmod -R 755 ./*

par exemple modifiera les droits d'accès de tout les fichiers du dossiers et des dossiers inférieurs en 755

Merci de ta réponse.

J'ai cru longtemps (je dirais jusqu’à ce matin) la même chose que ce que tu dis, mais maintenant j'en doute.

Si je fais

chmod -R 777 ./*

conformément à ce que dit l'hébergeur, je supprime toute protection sur tout le site, donc si tu as raison j'ouvre la porte à tous les piratages possibles. (Si je mets 755, compte tenu que les scripts de cet hébergeur sont exécutés avec les droits "other", je ne pourrai pas non plus écrire les fichiers, donc c'est bien 777 ou rien.)

- ou bien mettre les droits à 777 ne présente aucun danger, et on se demande pourquoi on met des droits d'accès dans ces fichiers et répertoires
- ou bien c'est dangereux, et j'en déduis que l'hébergeur me propose des solutions scandaleusement dangereuses pour compenser une option stupide consistant à faire exécuter les scripts en mode "other".

SI j'étais le propriétaire de ce site, je déménagerais en toute urgence...

Salut,

Je peux dire/faire des bêtises avec mes pratiques sachant que je ne suis pas du tout expert en sécurité. Pour ce genre de questions, ce que je fais :
- tous les repertoires sont en 755 sauf le cache et public en 777.
- Ensuite je redirige la requetes là où je veux (répertoire public) avec 2 htaccess :
//racine du projet

<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteRule    ^$    public/    [L]
    RewriteRule    (.*) public/$1    [L]
</IfModule>

//dans le rep public

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

Ce qui veut dire que le répertoire cache n'est pas accessible via une url et dans le public, il n'y a pas de données sensibles.

<<<EDIT
Je n'avais pas tout lu.

edenpulse a écrit :

Tout les comptes sont ce qui s'appelle "chrooté" et bien distincts les uns des autres.
Pour modifier les droits d'accès de miliers de fichiers / dossiers de manière récursive, tu peux utiliser la commande en mode récursif :

chmod -R 755 ./*

par exemple modifiera les droits d'accès de tout les fichiers du dossiers et des dossiers inférieurs en 755

+1 et d'ailleurs ça doit être fait comme ceci normalement.

/home/nom-du-compte/www

Si le serveur est de type UNIX (bsd family par exemple), tu peux créer un JAIL pour augmenter la sécurité. D'ailleurs, je me demande si avec GNU/Linux (Debian/Debian like ex), tu peux faire de même. Je pense que oui, mais comment dans ce cas ?

Pour les services tel qu'un SGBDR, là encore tu peux implémanter des restrictions :
Madame Michu (utilisateur lambda) n'est qu'un simple "user" avec comme privilèges select.
EDIT;
Modifié par niuxe (28 Jun 2015 - 18:28)

Bonjour,
Je ne veux pas bouleverser ce gros site dont tu parles, mais il parait utile de rappeler certaines règles
Avoir sur un site besoins d'écrire dans un fichier est incroyable, alors que tout les sites ont MySql ou autre.

Si tu dois réellement modifier un php (ou un html) ce doit être exceptionnel et cela se fait chez sois puis envoyé par FTP non ? ,

autre point pour écrire dans un fichier non protégé,( il est en 777) oui mais pas forcément accessible depuis l'extérieur !

j'aimerais (et tu peux y gagner) avoir en MP l'URL de ce site je te dirais ce que j'en penses

Donnes moi du détail !

Bonsoir à tous

Avoir besoin d'écrire dans un fichier est une chose normale pour un informaticien, je veux dire quelqu'un qui a l'habitude de faire exécuter des opérations par un ordinateur, pas seulement s'en servir pour afficher des choses toutes faites, ce qui s'appelle un serveur de données. Un ordinateur peut faire bien d'autres choses, et une fois qu'on a l'habitude de le faire on peut difficilement s'en passer.

Par ailleurs une base de données n'est rien d'autre qu'un ensemble de fichiers ne contenant que quelques unes des informations dont on a besoin et utilisant des moyens lourds et compliqués pour faire des choses élémentaires avec un langage de programmation orienté objets. Il faut toujours lui faire des extensions sous la forme de fichiers. Sur les sites que je gère,-- et bien que j'aie été pendant 10 ans employé d'une entreprise leader dans le domaine des bases de données -- je n'ai jamais éprouvé le besoin de faire une base de données. Par contre j'ai toujours utilisé des outils pour gérer et modifier des fichiers.
Pourquoi faire sur un PC puis transférer à la main, par exemple, des miniatures d'images plutôt que se contenter de mettre les images sur le site et laisser un programme les générer?

Je n'ai toujours pas compris si mettre les protections à 777 sur un site web présentait un risque, si oui quel risque, sinon pourquoi on s'enquiquinerait à mettre des droits différents si 777 ne présente pas de risque. (j'insiste sur le contexte de site Web, car pour une machine UNIX faisant autre chose, je n'ai aucun doute sur leur utilité)

Ce que vous faites est exactement ce que je fais, mais depuis hier je me demande si nous le faisons par habitude ou s'il y a une véritable raison de le faire.

Faudrait être complètement con pour appliquer un mode 0777 récursivement sur tous les fichiers d'un espace web. Ça donnerait les droits en écritures/lectures et exécutions de n'importe quel fichier par n'importe quel utilisateur du système (en gros le truc réservé uniquement à l'utilisateur root).

Si l'administrateur de ton serveur t'as dis de faire un chmod 0777 c'est forcément sur un dossier et pas sur l'ensemble des fichiers et dossiers.

lamext a écrit :
Faudrait être complètement con pour appliquer un mode 0777 récursivement sur tous les fichiers d'un espace web. Ça donnerait les droits en écritures/lectures et exécutions de n'importe quel fichier par n'importe quel utilisateur du système (en gros le truc réservé uniquement à l'utilisateur root).

Si l'administrateur de ton serveur t'as dis de faire un chmod 0777 c'est forcément sur un dossier et pas sur l'ensemble des fichiers et dossiers.

+1

C'est la même chose que si tu faisais ça (ci-dessous) sur GNU/Linux. C'est du grand n'importe quoi. C'est open bar pour tout le monde....

#chmod -Rf 777 /*

a écrit :

autre point pour écrire dans un fichier non protégé,( il est en 777) oui mais pas forcément accessible depuis l'extérieur !

+1
D'où mon exemple précédent à propos du rep cache avec les 2 htaccess.

/src
/src/models/...
/src/controllers/...
/src/views/...
/src/tmp/...
/public/....
Modifié par niuxe (29 Jun 2015 - 02:44)

Bon!

J'ai reçu ce matin un message de l'hébergeur disant que tout compte fait il n'était pas possible d'écrire le moindre fichier dans quelque répertoire que soit de ce site autrement que par FTP.

Cela signifie à mon sens
1) qu'ils reconnaissent que leur "solution" de passer les répertoires à 777 était une c...
2) que l'on ne peut pas faire autre chose sur ce site que de l'affichage de fichiers, même pas une entrée "file" dans un formulaire ou autre fonction couramment utilisée sur la plupart des sites

Ils ont proposé de "migrer l'offre d'hébergement vers une nouvelle offre", sans préciser le coût de l'opération (plusieurs milliers de fichiers image, plus de 1000 fichiers HTML, et j'en oublie sans doute) et s'ils le feraient ou s'il fallait se palucher le chargement de ces milliers de fichiers nous mêmes, si l'opération se ferait sans interruption du service pour les milliers d'utilisateurs habituels...

Je laisse au propriétaire du site le soin de leur répondre et de choisir l'action appropriée.

En ce qui concerne ma question, je n'ai toujours pas l'assurance que les droits d'accès servent à quelque chose, mais effectivement le risque est trop grand.
En gros le sens de ma question était: "ou bien ils me proposent une c... ou bien les droits d'accès ne servent à rien". Je constate que le premier terme de l'alternative est le bon, sans pour autant exclure le deuxième, mais il ne me reste pas assez de temps à vivre pour que je le gaspille à ce genre de subtilités.
Je vais donc faire comme cet incroyant qui se confessait sur son lit de mort ... au cas où

C'est vraiment incroyable que tu n'utilises pas MySql ou autre, saches que sur mes 50 site beaucoup sont TOUT MySql, ce qui veut dire pas une ligne dans les php (juste l'ouverture SQL et lecture de chaque page)

Bien sur je gères beaucoup de paramétrages,ainsi ceux pour qui j'ais créé ces sites,
sont autonomes , pourtant tout va dans la base SQL ,lorsqu'ils sont sur leur outil d'administration !

Bien sur j'ais des tables pour les blogs,t'chat,livre d'or etc...
Certains gèrent leur chèques et autres documents par MySql comment crois-tu que font les banques ?

Puisque tu as insisté sur ce point , saches que j'étai patron du service informatique d'une holding de bâtiment avec 40 informaticiens , alors oui la programmation j'adores comme toi, alors apprends vite MySql (surtout PDO) et bien sur Ajax.

@Christele
Merci de ta réponse.
Je connais MySQL, qui du reste appartient maintenant à mon ancien employeur.
Il se trouve que pour le type de sites que je gère je n'en ai pas besoin. J'ai même fait un essai pour voir ce que ça donnerait pour mon site principal, pas concluant, plutôt concluant dans le sens négatif.

Dans les années 1990 il y avait eu quelques BDD objets, mais le rouleau compresseur SQL, qui doit être la dernière survivance du COBOL, a tout écrasé.

Moyennant quoi ma remarque n'était pas anti BDD mais simplement mon étonnement de te voir t'étonner que l'on puisse vouloir écrire des fichiers sur un site.

Oui je m'en étonnes même fortement, car tu as fini par faire un site web qui est une vrais passoire,
Il y aurait tant à dire ...
Ton sitemap.xml est mal généré,
On se balade dans ton site comme on veut http://www.bonieux.com/php/
Il n'est pas responsive aux tablettes et portables si tu veux je peux t'aider sur ce point
bref tu devrais reprendre la main sur ton site

Christele a écrit :
Oui je m'en étonnes même fortement, car tu as fini par faire un site web qui est une vrais passoire,
Il y aurait tant à dire ...
Ton sitemap.xml est mal généré,
On se balade dans ton site comme on veut http://www.bonieux.com/php/
Il n'est pas responsive aux tablettes et portables si tu veux je peux t'aider sur ce point
bref tu devrais reprendre la main sur ton site

Merci de ta proposition.
Je suis bien conscient qu'il y a des choses à reprendre sur ce site, je te recontacterai après la pause de l'été.