[spip-dev] Re: [CLX] Et encore une

Mouais... c'est dommage qu'il y a ce truc là... Cela dit, il est vrai
que chez Nordnet ils ont raison. Ce n'est vraiment pas sécurisé
d'afficher des pages d'un repertoire accessible en écriture à nobody. Le
moindre trou dans apache (ou dans ton PHP), et ton site est hacké.

[Copie à spip-dev pour info http://www.nordnet.fr]

@ Gaetan Ryckeboer <gryckeboer@virtual-net.fr> :

Mouais... c'est dommage qu'il y a ce truc là... Cela dit, il est vrai
que chez Nordnet ils ont raison. Ce n'est vraiment pas sécurisé
d'afficher des pages d'un repertoire accessible en écriture à nobody. Le
moindre trou dans apache (ou dans ton PHP), et ton site est hacké.

Il n'est pas interdit de jouer avec les permissions : si le serveur et les
répertoires ont le même user ou group, on n'est pas obligé d'ouvrir
l'écriture du cache aux autres. Rien n'interdit d'aller modifier dans le
code tous les chmod et umask, une fois que spip est installé il ne vérifie
plus les permissions des répertoires que s'il rencontre un problème
(interdiction d'écrire).

Sinon, que faire ? On pourrait éventuellement sécuriser la chose en
enregistrant dans la BDD la liste des fichiers cache, avec leur date de
création et/ou une signature quelconque, et en stockant cette liste dans un
autre fichier. Et avant chaque appel du cache on vérifie sur ce fichier (pas
de connexion à la base) que le fichier qu'on s'apprête à inclure est connu.

L'impact en temps de calcul serait à analyser ; si c'est pas trop lourd,
cela permettrait aussi de mieux gérer le cache en cas de contraintes
d'espace disque.

Je dis peut-être des bêtises ? Maintenant, c'est encore pas mal d'ennuis
pour peut-être pas grand chose... je ne sais pas. On en discute post-1.4 ?

-- Fil

Bien sûr !

Spip a des contraintes que certains hébergeurs ne sont pas en mesure
d'accepter - aujourd'hui - , mes SPIP rend de très grands services à
l'immense majorité des clients sur les autres hébergeurs :wink:

Salut,

Le probl}me est le m^eme ! Apache aurat les droit www, donc www
(l'utilisateur apache) aura le droit d'{crire dans le r{pertoire, donc
un trou dans le code, dans apache, ou dans php permettra d'aller taper
dans le cache...

- Un trou dans Apache ou dans PHP : la seule chose à faire est de mettre
la version qui corrige le trou. Tu ne peux pas demander à un programme
(SPIP) de contourner les trous éventuels d'autres programmes.

- Un trou dans un script PHP (SPIP par exemple) : avec un open_basedir
bien réglé, et le safe_mode itou, il ne peut faire des dégâts que dans
sa propre arborescence (celle du propriétaire du compte, en général)
et pas celle du voisin. C'est donc une question de configuration.

a+

Antoine.

La sécurité dépend du setup de ton serveur. De toute façon SPIP a
besoin du cache, donc je ne vois pas comment on pourrait contourner
de notre côté. Pouvoir écrire dans des fichiers a toujours été un
problème avec les CGI et assimilés. N'empêche qu'avec le safe-mode
PHP et/ou un open_basedir bien réglé, il ne devrait pas y avoir
de gros soucis.

D'autre part Apache n'est pas obligé d'être en nobody : tu peux
créer un groupe www, t'arranger pour que tous les répertoires
http imposent le groupe www aux fichiers créées (je me souviens
plus de l'option chmod : g+s peut-être), et mettre les répertoires
SPIP en 770. Apache/PHP tournant en www, il aura accès à tous
répertoires http, mais les utilisateurs individuels n'auront
accès qu'au leur propre (ils ne sont pas membres du groupe www).
Pour le safe-mode, il y a une option safe_mode_gid qui devrait
convenir exactement.

Certes tu as entièrement raison. Cependant, tu le reconnais, ces
modifications ne peuvent être effectuées que par l'administrateur du
serveur. Or dans le cas d'un hébergement chez un fournisseur d'accès, tu
as rarement la possibilité d'administrer ce serveur. Et ce n'est
probablement pas en leur conseillant des modifs (même utiles) que l'on
fera avancer les choses . Même si j'apprécie SPIP, je trouve dommage que
cette contrainte oblige des manipulation côté serveur en plus de toute
la partie DocRoot .

Et, franchement, s'il y a un trou dans PHP ou Apache, le cache SPIP
sera le cadet de tes soucis non ?

Mouai. Et si un jour un vers façon Slapper parvenait à passer à travers
le cache SPIP pour ensuite s'injecter, se compiler, etc .... que
pourrait-on faire contre cela ?