Version 1 — Mars 2007 — Fil
(article historique)
/ ! \ 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é.
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.
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) :
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.
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 ...
La fonction php tester_repertoire fait les calcul suivants :
l’utilisateur éxecutant le script php doit être en mesure d’écrire dans le répertoire courant.
Précision sur les permissions à établir sur les différents répertoires de son site
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 :
type | Légende | exemples |
---|---|---|
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 :
nom | type | role |
---|---|---|
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 :
config/
peut-être rétabli en lecture seule après installationRépertoires pouvant être supprimés
nom | type | role |
---|---|---|
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);
}
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
dist/vignettes
. Il sont surchargeables en créant un dossier squelettes/vignettes
, donc, le nomage *-dist.png
, n’est plus nécessaire.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.
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 Plan mutualisé
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é)
agora-system.net ???