Bonjour,
je suis confronté à une situation que je n'ai jamais rencontrée à ce jour, avec spip 2.0.8 ou spip 2.0.9 j'ai en permanence des problèmes de droits sur les répertoires /IMG/ /local/ /tmp/ et ce message bien connu qui s'affiche :
vérifier les droits d'écriture
Le système a rencontré une erreur lors de l'écriture du fichier tmp/cache/f/for-htt---rec-krC-new-ar-678f4da1. Veuillez, en tant qu'administrateur du site, vérifier les droits d'écriture sur le répertoire tmp/cache/f.
les permissions sur ces répertoires et fichiers sont par défaut à 755 et apparemment spip à besoin de la permission 777 pour fonctionner normalement.
Ce qui m'étonne c'est sur d'autres hébergements, free par exemple tout fonctionne avec une permission 755 sur /IMG/ et 700 sur /local/ et /tmp/
à ce stade je ne sais plus quoi en penser. ce que je sais c'est que l'hébergeur à resserré les boulons sur la sécurité mais au point de rendre spip inopérant là je cale. Si vous avez une info elle serai bien venue.
cordialement
Bonjour,
je suis confronté à une situation que je n'ai jamais rencontrée à ce
jour, avec spip 2.0.8 ou spip 2.0.9 j'ai en permanence des problèmes de
droits sur les répertoires /IMG/ /local/ /tmp/ et ce message bien connu
[...]
Bonjour,
j'ai ce problème sur un hébergement OVH (90plan) lorsque j'ouvre
beaucoup de pages (publiques) dans des onglets pour faire calculer
les caches.
Je pense qu'il y a un mécanisme chez OVH pour limiter le nombre
d'accès en écriture sur les fichiers. Parfois ce sont même des
fichiers squelettes qui sont "introuvable". dans ce cas il me suffit
de recharger chaque page ayant une erreur.
Dans la partie "admin", j'ai plus rarement cette erreur, mais je
l'ai si j'utilise beaucoup les onglets (ce qui me permet de faire
plusieurs opérations le temps que les pages se chargent).
Y'a 2 solutions pour que SPIP puisse écrire :
- mettre en chmod 777 (la moins sécurisé)
- rendre l'utilisateur apache (en général www-data) propriétaire du dossier avec chown. Sur un serveur dédié, on peut donc faire chown -R www-data:utilisateurs_ftp /home/spip
Merci Grégoire,
le cas est bien plus simple, qui que se soit qui accède au site, dans une seule fenêtre ou onglet du navigateur voit ce message, et en ce qui concerne l'espace privé plus rien n'est accessible du fait que seul le bandeau de navigation s'affiche et pas les pages en dessous avec comme message d'erreur :
Warning: Cannot modify header information - headers already sent by (output started at /home/intran22/public_html/ecrire/exec/accueil.php:415) in /home/intran22/public_html/ecrire/inc/headers.php on line 147
et aussi :
Le système a rencontré une erreur lors de l'écriture du fichier ../tmp/sessions/ajax_fonctions.txt. Veuillez, en tant qu'administrateur du site, vérifier les droits d'écriture sur le répertoire tmp/sessions.
je pense que tous est lié à ce problème de permissions en écriture.
si je passe /IMG/ /local/ et /tmp/ sur 777 par ftp tous rentre dans l'ordre mais 15 ou 20min après rebelote les permissions se repositionnent en 755 donc rien n'est résolu.
cordialement
si je passe /IMG/ /local/ et /tmp/ sur 777 par ftp tous rentre dans
l'ordre mais 15 ou 20min après rebelote les permissions se
repositionnent en 755 donc rien n'est résolu.
cordialement
[...]
Bonjour,
placer les droits à 777 est une hérésie.
D'ailleurs, sur OVH, ça provoque une erreur 500 (dommage que ce ne
soit pas plus pédagogique).
Pour OVH, les droits sur les fichiers peuvent être à 604 ou 404.
Pour les répertoire, c'est 705. Le dossier www devant impérativement
être à 705.
Pour Lautre.net, il faut décaler le 0 : 640, 440 et 750. (Les
serveurs d'OVH et de Lautre.net ne sont pas configurés de la même
manière en terme de processus Apache.)
En tout cas, sur un 90plan, je fixe les droits de cette manière
depuis plusieurs années déjà et ça fonctionne très bien (et c'est
comme ça que c'est précisé dans leur pages d'aides).
Merci Grégoire,
le cas est bien plus simple, qui que se soit qui accède au site, dans
une seule fenêtre ou onglet du navigateur voit ce message,[...]
si je passe /IMG/ /local/ et /tmp/ sur 777 par ftp tous rentre dans
l'ordre mais 15 ou 20min après rebelote les permissions se
repositionnent en 755 donc rien n'est résolu.
cordialement[...]
Bonsoir,
quel est ton hébergeur?
Il y a probablement un masque qui ne te permet pas de placer les
droit à 777 (heureusement), donc cela expliquerait qu'une fois cela
fait tu retrouves les droit à 755 (qui est une sorte de maximum
acceptable).
Comment fixes-tu les droits? Par ftp? par commande ssh?
Je pense qu'il y a un mécanisme qui empêche les accès multiple aux
fichiers, et que tes fichiers de caches ne sont pas encore écrit, et
que Spip en cherche à en créer plus que ce qu'autorise ton hébergeur.
Donc, je ne pense pas que ce soit un problème de chmod.
El Friday 18 September 2009 06:04:56 Yohann Prigent va escriure:
Y'a 2 solutions pour que SPIP puisse écrire :
- mettre en chmod 777 (la moins sécurisé)
Vraiment pas. Regarder si l'utilisateur sous lequel est lancé le service
Apache est, pour les fichiers ou répertoires concernés :
- propriétaire,
- membre du groupe propriétaire,
- ou autre.
À partir de cette info, mettre le "7" sur le premier, deuxième ou
troisième chiffre du chmod, et le reste à 0 (ou 5 si on veut être moins
strict et permettre un accès en lecture).
Si c'est des fichiers au lieu de répertoires, c'est 6 et 4 respectivement
au lieu de 7 et 5 (car pas besoin de droits d'exécution).
Les droits appropriés se déterminent quand même assez vite, donc 777
*surtout* pas. Sinon, le premier clampin qui peut lancer un programme
sur la machine, que ce soit parce qu'on lui a donné un compte
utilisateur lambda, parce qu'il a utilisé une faille d'un autre service
pour gagner un accès local, etc., peut se mettre à modifier des choses du
site web.
Petit rappel pour la forme :
U G O (user, group, other)
rwx rwx rwx (read, write, execute)
421 421 421
et on additionne les chiffres qu'on veut pour chacun. Par exemple 640 si
on veut lecture/écriture pour l'utilisateur, lecture simple pour le
groupe, rien pour les autres.
On parle de local (qui se regénère) de tmp (qui par définition... est temporaire) et de IMG (qui lui est un peu plus sensible).
Je pense que plutôt que de se prendre la tête sur des droits pour des dossiers "sensibles en cas d'intrusion" il faut déjà penser à faire des sauvegardes régulières. Car le jour où il y a intrusion... En général avec ou sans les droits... C'est que plus en amont ya eu un soucis
