Carnet Documentation SPIP

Droits et Permissions
des Répertoires et Fichiers

Droits et Permissions
des Répertoires et Fichiers

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

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

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

Ce qui manque à spip_loader

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/upoad/ TI répertoireS de dépot des documents de grande taille
tmp/visites/ TI fichiers temporaires des stats

Légende :

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/upoad/(**) TI répertoireS de dépot des documents de grande taille

TODO :

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

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

OVH mutualisé

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)

Il est conseiller, 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

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

free

ouvaton

1and1

Nuxit (www.nuxit.com)

Haisoft (www.haisoft.fr)

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

africa-web.org

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

oxito (mutualisé)

apinc (mutualisé)

gandi.net ???

agora-system.net ???

2010-09-24 22:46:51