[spip-dev] Droits par default et sécurité...

Dev
1

Bonjour,

Je me souviens avoir déjà posé la question, mais je la repose parce que je
crois que je la réponse n'était pas claire.

Je voudrai savoir pourquoi SPIP règle par défaut le umask à 0

(fichier ecrire/inc_version.php, lignes:
// Droits d'acces maximum par defaut
@umask(0)
)

Je crois me souvenir vaguement qu'on m'avait parlé de problèmes de droits chez
certains hébergeurs.

Je suis quand même super sceptique à ce sujet. De base, ce umask donne le
droit en exécution à tout ce que spip crée dans ces répertoires.

Les problèmes de sécurité dans les applis web sont deja suffisamment compliqués
pour l'on n'ajoute pas de faille béantes par défaut et présupposer que la
faute incombe à l'hébergeur pour ne pas avoir désactivé le chmod +x par
défaut...

D'autre part, si vous souhaitez maintenir une telle valeur par défaut, il
serait de bon ton de permettre de changer cela facilement, voire en parler à
l'installation...

Enfin, le code de décompression zip (fichier ecrire/inc/pclzip.php) ne fait pas
la différence entre fichier et répertoire quand il applique l'option
PCLZIP_OPT_SET_CHMOD, ce qui ici aussi créer des fichiers exécutables même avec
un umask sérieux...

Romain

2

Bonjour Romain

3

Salut !

Non, parce que la fonction ecrire_fichier dans flock.php fait en plus
un "& 0666" sur le fichier créé. Par ailleurs, l'etape
installe/etape_chmod compare l'Uid et le Gid des sources de SPIP et d'un
fichier qu'il créé pour déterminer si SPIP tourne sous l'identité du
serveur, ou au moins dans son groupe, ou encore ailleurs, et prend le
umask le plus restrictif (700, 770, ou 777). Jen vois pas ce qu'on
pourrait faire de mieux.

Merci de ta réponse. Le problème que je vois avec votre solution est qu'elle
demande d'être sur que toutes les créations de fichiers sont vérifiées ainsi.

Mon problème est dans la création de fichiers lors de l'installation
automatique de plugins. Les fichiers résultant se retrouvent tous avec 777 ce
qui n'est pas top top...

Le problème est double. D'un coté, le code dans ecrire/inc/charger_plugin.php
fais la chose suivante:
  PCLZIP_OPT_SET_CHMOD, _SPIP_CHMOD

Ce qui dit à PCLZIP de donner les droits SPIP_CHMOD (777 par defaut) aux
fichiers crées. D'autre part, il n'est pas possible de choisir un SPIP_CHMOD
raisonnable car le code de pclzip fais:
  @chmod($p_entry['filename'], $p_options[PCLZIP_OPT_SET_CHMOD]);
Et ne fais pas la distinction entre répertoire et fichiers...

J'ai réglé cela en désactivant le passage de cette option ce qui laisse le
système choisir les droits appropriés.

En définitive, ne serait-il pas plus sage, dans ecrire/inc_version.php, de
regarder le problème des droits de fichiers, qui du webserver ou de l'user ftp
possède les fichiers, qui est le groupe etc.. et de choisir un umask approprié
à ce moment là ?

En faisant ainsi, il n'y a plus besoin de se soucier de ce qui va se passer
par la suite, ce qui évite des situations oubliées comme celle de la
décompression zip expliquée ici...

Romain

4

D'autre part, il n'est pas possible de choisir un SPIP_CHMOD
raisonnable car le code de pclzip fais:
@chmod($p_entry['filename'], $p_options[PCLZIP_OPT_SET_CHMOD]);
Et ne fais pas la distinction entre répertoire et fichiers...

En effet, pas terrible. Il faudrait le signaler à l'auteur.

J'ai réglé cela en désactivant le passage de cette option ce qui laisse le
système choisir les droits appropriés.

En patchant le code ? Je n'ai pas vu comment empêcher ça autrement.

En définitive, ne serait-il pas plus sage, dans ecrire/inc_version.php, de
regarder le problème des droits de fichiers, qui du webserver ou de l'user ftp
possède les fichiers, qui est le groupe etc.. et de choisir un umask approprié
à ce moment là ?

Tu peux fournir un patch ?

Committo,Ergo:Sum