Carnet Wiki

quels sont les differents Droits des Fichiers et dossiers

(article historique)

Les droits de fichiers dans spip

/ ! \ Attention ! : rien à voir avec les droits de publier, créer des rubriques et autres, il s’agit ici de voir quels fichiers et répertoires doivent avoir quel droits pour avoir un truc sympa, factorisable et à peu près securisé.

Le contexte

Quel que soit le mode d’hébergement, il faut :

  • que le serveur web puisse lire tous les fichiers dont il a besoin
  • que le webmestre puisse les lire et y écrire
  • que le serveur puisse écrire sur certains d’entre eux (cache, data, mais aussi le futur installeur de plugin)
  • que les voisins (autres hébergés) ne puissent pas lire/écrire là où ils n’ont pas à le faire

Pour ça, tout ce qu’on a, ce sont les droits unix (je ne cause pas de plateformes windows ou mac, qui ne sont utilisés que dans des contextes locaux, du moins je l’espère ...).

Le but de cette page est de faire un inventaire des différents cas qui se présentent chez les différents hébergeurs, et d’en déduire les tests et organisations qu’ils faudrait mettre en place dans spip pour assurer que ça marche dans un maximum de situations.

Les droits unix

Petit « cours d’unix » pour faire le tour de ce qu’on a à notre disposition
Chaque fichier possède un utilisateur et un groupe propriétaires, et des droits de lecture et écriture (je ne m’occupe pas des droits d’exécution) pour le propriétaire, le groupe, ou le reste du monde.
Chaque processus (le ftp de l’utilisateur, le serveur web) tourne sous le nom d’un utilisateur appartenant à un ou plusieurs groupes.
Certains serveurs peuvent faire semblant d’être un autre, ou controler plus finement les droits, ce qui ne facilite pas toujours les choses.
En plus, il y a des droits spéciaux sur les fichiers et les répertoires. Les principaux (pour notre cas) :

  • le droit setgid sur un répertoire force les fichjiers créés dedans à appartenir au même groupe, même s’il sont créés par un utilisateur d’un autre groupe. Donc, si j’ai un répertoire « drwxrwsrwx / moi : mongroupe » si apache y pose un fichier, il appartiendra à apache : mongroupe".
  • je ne sais pas si le droit setuid à un sens pour les répertoires

Le problème

Chez les hébergeurs mutualisés, on n’est pas root, donc on ne décide pas de l’utilisateur qui pose les fichiers, ou de celui qui fait tourner les serveurs web. On ne décide pas non plus du propriétaire des fichiers, mais on décide des droits généralement.
Enfin, s’il y a des trucs spéciaux (suphp, safe mode, suexec), on ne le sait pas forcément.

pistes

au 13/10/2006, spip_loader est modifié en conséquence et la version de developpement actuelle à été mise à jour : (<http://listes.rezo.net/archives/spi...>)

Il est donc possible de tester à nouveau en « grandeur nature », téléchargez spip_loader ici

Tests réalisés et réussis : free, ouvaton, ovh, rekcah, africa-web, 1and1, haisoft ...

comment fonctionne spip_loader actuellement

La fonction php tester_repertoire fait les calcul suivants :

voir en ligne

  • On vérifie l’identité des propiétaires/groupes du répertoire où se trouve le script et le script lui-même ainsi que ses permissions.
    (Pour mémoire, il a été déposé par ftp.),
  • on tente de créer un fichier ’test’ dans le répertoire courant, on compare,
  • on tente de créer un répertoire ’test’ dans le répertoire courant, on compare,
  • on en déduit les permissions nécessaires ($chmod) à attribuer à tous les fichiers qui seront extraits de l’archive.

l’utilisateur éxecutant le script php doit être en mesure d’écrire dans le répertoire courant.

Ce qui manque à spip_loader

  • détection de safe_mode (qui disparaîtra en PHP6) et d’une directive open_basedir qui ne conviendrait pas. Le cas échéant, arrêter le script, fournir un message invitant à se retourner vers l’herbergeur et lui demander de désactiver la directive ou safe_mode.
  • meilleure prise en compte d’un nom de paquet autre que SPIP
  • afficher la valeur correcte du chmod calculé dans le message d’erreur indiquant qu’il faut ajuster les droits via ftp.
  • le message d’intro est faux : on a déjà testé les permissions quand on arrive à la première page...

comment fonctionne spip actuellement

Précision sur les permissions à établir sur les différents répertoires de son site


Etape suivante : transmettre définitivement les permissions correctes à spip après l’installation

L’idée est de calculer les permissions les plus justes, ou de bénéficier du calcul de spip_loader, dans spip.

Dans la version de développement, il existe une constante _DIR_CHMOD. Elle est utilisée dans le cadre de création de fichiers temporaires (session, verrous, cache)

a priori, on pourrait considérer que SPIP peut utiliser des fichiers en lecture seule partout sauf là où il a besoin d’écrire (hé hé ! :D) or spip_loader implique la lecture/écriture partout.

La reflexion suivante s’appuie sur les besoins en écriture de SPIP que le tableau ci-dessous tente de résumer :

typeLégendeexemples
PI fichiers permanents et inaccessibles ecrire/
PA fichiers permanents et accessibles IMG/
TI fichiers temporaires et inaccessibles CACHE/, ecrire/data/
TA fichiers temporaires et accessibles IMG/cache*

Les termes accessibles et inaccessibles sont liés à leur accessibilité par le web via un navigateur, et symbolisent l’usage d’une directive « deny from all » dans un fichier .htaccess ou par une authentification (cas de ecrire/ pour l’instant).

Les termes permanents et temporaires sont liés au fait que les fichiers peuvent être, ou pas, déstinés à être supprimer, par l’utilisateur ou le système.

ecrire/ doit être en écriture au moment de l’installation pour créer inc_connect.php. Mais tous les autres fichiers de ce répertoire pourraient être en lecture seule. Piste : déplacement dans un répertoire config/ de la création du fichier inc_connect.php.

ecrire/data/ doit être en ecriture alors que les autres fichiers de ecrire/ pourrait être en lecture. Piste : déplacement dans un répertoire tmp/ ou tmp/data/de la gestion des fichiers de sessions, locks etc...

Un oublié : ecrire/upload/ représenté par _DIR_TRANSFERT. Il n’est pas nécessaire qu’il soit accessible en écriture, (pour http, s’entend) mais peut-être faut-il le protéger. On peut aussi envisager de le sortir du répertoire ecrire/.

IMG/cache-xx/ doit être en écriture, constitue un ensemble de fichiers devant être accessibles via http. Techniquement, ils sont bien placé dans IMG/, mais fonctionnellement, c’est du cache. Piste : déplacement dans le répertoire tmp/ (et dans ce cas, tmp/ ne serait plus inaccessibles...grumpf)

Les statistiques exploitent _DIR_TMP, on se retouve donc avec un tmp/visites/ qu’il faut protéger, j’imagine.

Etendre le système pour créer les répertoires et les chmoder à la volée. On fournirait ainsi un simple tmp/ et SPIP se débrouille pour faire le reste. Si on efface le contenu entier de tmp/ SPIP doit pourvoir reconstituer l’arborescence quand même, c’est le rôle d’un tmp/ d’être vidé entièrement ! :)

Arborescence cible :

nomtyperole
config/ PI* abriter les infos de connexions, les options
dist/ - squelettes et ressources par défaut
ecrire/ - espace privé
IMG/ PA ranger les images, logos et documents joints
oo/ - sommaire du site en mode texte
plugins/ - ranger les plugins
squelettes/ - ranger les squelettes personnalisés et leurs ressources
local/ TA cache des vignettes et autres données calculées et accessibles via http
tmp/ TI repertoire de base pour les données temporaires
tmp/CACHE/ TI cache principal du site
tmp/sessions/ TI fichiers de sessions
tmp/dump/ TI répertoire de dépot des sauvegardes
tmp/upload/ TI répertoireS de dépot des documents de grande taille
tmp/visites/ TI fichiers temporaires des stats

Légende :

  • le signe - indique que le répertoire peut-être en lecture seule
  • * : config/ peut-être rétabli en lecture seule après installation

Répertoires pouvant être supprimés

nomtyperole
CACHE/ TI cache principal du site
formulaires/(*) - squelettes html des formulaires de la distribution
ecrire/data/(**) TI repertoire de base pour les données temporaires
ecrire/img_pack/ - images de l’espace privé, vignettes par défaut des documents, images de la barre typo
ecrire/upload/(**) TI répertoireS de dépot des documents de grande taille
  • (*) : ce répertoire DOIT être supprimé
  • (**) : le contenu de ces répertoires est deplacé lors de la mise à jour

TODO :

  • l’initialisation des constantes doit se faire sur la base de 4 répertoires et non un seul.
  • les sous-répertoires de tmp doivent être créer à la volée accessible en ecriture et globalement protéger par un « deny from all ». Piste : remanier sous_repertoire() qui doit calculer le sous répertoire à partir du paramètre fourni et non à partir d’un second paramètre. Autre piste : insérer le code ci-dessous partout où c’est nécessaire :
if(!@file_exists(_DIR_CHOSE)) {
    @mkdir(_DIR_CHOSE, _SPIP_CHMOD);
    @chmod(_DIR_CHOSE, _SPIP_CHMOD);
}

Calcul des bonnes permissions à l’installation

Il serait bien que test_dirs utilise la constante _DIR_CHMOD (qui devrait peut-être s’appeler _SPIP_CHMOD) et applique les bons droits dans les profondeurs du répoertoire testé, et _SPIP_CHMOD pourrait alors être calculé à l’installation et être stockée dans _FILE_CONNECT

pour la 1.9.2

une constante _SPIP_CHMOD est calculée et conservée à l’installation ou à la réinstallation de SPIP. elle est stockée dans le fichier config/chmod.php. Lors d’une mise à jour, ce fichier n’est pas généré et la constante vaut 0777


vignettes auto

  • aujourd’hui (octobre 2006), les vignettes sont stockées dans dist/vignettes. Il sont surchargeables en créant un dossier squelettes/vignettes, donc, le nomage *-dist.png, n’est plus nécessaire.
  • repenser la gestion via les constantes (_DIR_IMG_ICONES)

Mise à jour

le message Trop de redirections sont survenues à propos d’un lien du type spip.php?action=test_dirs&test_dir=tmp/ peut survenir lors d’un mise à jour manuelle. Penser à affecter les permissions correctes.


Inventaire

L’idée est d’indiquer, pour quelques hébergeurs « classiques » : les droits du docroot, les combinaisons user/group du docroot, des fichiers déposés par l’utilisateur, de ceux créés par le web, et de noter des particularités.

Là, à vous ...

  • dedibox ?
  • berlios.de ?

OVH mutualisé

  • PHP 4.4.9 ((CGI) safe_mode=off, register_globals=on)
  • PHP 5.2.17 ((CGI) safe_mode=off, register_globals=on)
  • PHP 5.3.10 ((CGI/FastCGI) safe_mode=off, register_globals=on)
  • PHP 5.4.0 (CGI/FastCGI)

Par défaut, c’est PHP 4.4.9 qui est utilisé !
Pour utiliser une autre version, vous devez mettre dans un fichier .htaccess à la racine de votre site (dans le dossier WWW)

  • Pour avoir la version PHP 5.2.X
    SetEnv PHP_VER 5
  • Pour avoir la version PHP 5.3.X
    SetEnv PHP_VER 5_3
  • Pour avoir la version PHP 5.4.X
    SetEnv PHP_VER 5_4

Il est conseillé, mais non obligatoire pour l’utilisation des versions antérieurs à spip 3 de mettre la variable register_globals sur off !
Pour ce faire, il faut mettre dans un fichiers .htaccess

SetEnv REGISTER_GLOBALS 0

A savoir que pour l’utilisation de Spip 3, cette variable devra OBLIGATOIREMENT être mise sur OFF !

Il est également conseillé, mais non obligatoire pour pouvoir lire certains types de fichiers via votre navigateur, de mettre dans un fichier .htaccess

AddType video/ogg  .ogv
AddType video/mp4  .mp4
AddType video/webm .webm
  • spip_loader installation spip 1.9.1 (7502) le 2 octobre 2007
  • aucun soucis.
    chez ovh un chmod supérieur à 755 provoque une erreur 500 (paramétrage volontaire de OVH) ... spip_loader n’était pas fonctionnel il y a un « certain temps » (me rappelle plus quand), mais en septembre 2006 spip_loader est fonctionnel Nicolas R

free

  • PHP5.1.3, CGI/ FastCGI , safe_mode=on
  • si je créé un répertoire via ftp, il est en 0700 (j’ai vérifié deux fois...)
  • si je créé un fichier via ftp, il est en 644
  • spip_loader applique les droits suivants : 755 sur les repertoire, 644 sur les fichiers : et ça marche.

ouvaton

  • PHP 4.4.0, Apache 2.0 Handler, safe_mode=on
  • si je créé un répertoire via ftp, il est en 0775
  • si je créé un fichier via ftp, il est en 664
  • spip_loader applique les droits suivants : 775 sur les repertoire, 664 sur les fichiers : et ça marche.

1and1

  • PHP 4.4.4, CGI, safe_mode=off
  • si je créé un répertoire via ftp, il est en 0755
  • si je créé un fichier via ftp, il est en 664
  • spip_loader applique les droits suivants : 755 sur les repertoire, 644 sur les fichiers : et ça marche.
  • tous les fichiers appartiennent à l’utilisateur. (qu’ils soient créés par ftp, http ou ssh)
  • il y a aussi php5 disponible : PHP 5.2.17 (cgi) safe_mode=off

Nuxit (www.nuxit.com)

  • aucun soucis.
  • tous les fichiers appartiennent à l’utilisateur.

Haisoft (www.haisoft.fr)

  • les fichiers créés par spip_loader appartiennent à l’utilisateur apache.apache, droits en 755
  • les fichiers créés par ftp sont en 644
  • l’utilisateur ftp n’a aucun droit sur les fichiers créés par spip_loader ce qui pose des problèmes pour, par exemple, « s’authentifier » par ftp. Il faut donc modifier dans ce cas spip_loader pour qu’il mette les droits en 777 ce qui n’est pas acceptable mais c’est la seule façon de s’en sortir pour le moment.
  • au 16/10/2006 : la directive safe_mode open_basedir définie avec la valeur du répertoire de base httpdocs, empêche spip_loader de fonctionner (fopen est arrêté par la contrainte de sécurité <directive open_basedir non nulle>)

Rekcah (ingurgité par http://www.account.fr récemment apparemment)

  • si je créé un répertoire via ftp, il est en 755. On peut le modifier en 775 et c’est suffisant pour faire tourner le denrier spip_loader dedans.
  • si je créé un fichier via ftp, il est en 664
  • spip_loader pour 1.9.1
  • Sur hébergement mutualisé les dossiers et fichiers créés par spip_loader sont en droits restreints (775 pour les dossiers). Impossible de les supprimer, de les écraser ou de créér un dossier d’authentification à l’intérieur de ecrire/data/ par exemple. c’est corrigé.

africa-web.org

  • PHP 4.3.10, Apache 2, php lancé en cgi via suphp, safe_mode=on (apache tourne avec l’utilisateur www-data mais les scripts php sont lancés en cgi avec l’uid/gid du propriétaire du fichier)
  • paramétrage de suphp : allow_file_group_writeable=true / allow_file_others_writeable=false / allow_directory_group_writeable=true /allow_directory_others_writeable=false
  • les fichiers crées par ftp sont en 644, les répertoires en 755
  • spip_loader applique les droits suivants : 644 sur les fichiers mais 700 sur les répertoires ce qui rend impossible la lecture du répertoire ecrire/ et donc l’installation (l’utilisateur apache www-data n’a pas les droits en lecture des répertoires crée par spip_loader).

Plateformes [ [->AlternC ] ->www.alternc.org] dont l’hébergeur www.lautre.net et quelques autres (configurés légèrement différemment).

  • Apache / PHP 4 - safe_mode = on
  • répertoire créé via ftp, le Gestionnaire de fichiers ou spip_loader.php : 750
  • fichier créé via ftp, le Gestionnaire de fichiers ou spip_loader.php : 640
  • Tout fonctionne comme souhaité : SPIP semble un bon citoyen [->AlternC ] et vice-versa.

oxito (mutualisé)

  • PHP 4.4.0, safe_mode = off
  • création d’un répertoire par ftp donne 755
  • spip_loader OK : répertoires en 755 et fichiers en 644

apinc (mutualisé)

  • PHP 4.4.4 - safe_mode = off
    -  création d’un répertoire par ftp donne 755
    -  les droits des répertoires doivent être au maximum : rwx...r.x soit 705 (sinon plantage)
    (ce qui semble etre en contradiction avec la ligne précédente...)
    -  les droits des fichiers doivent être au maximum : rw....r.. soit 604 (sinon plantage)

gandi.net ???

agora-system.net ???

Fil - Mise à jour :19 décembre 2018 à 20h48min