Author: cedric@yterium.com
Date: 2010-01-25 22:18:47 +0100 (lun, 25 jan 2010)
New Revision: 15010
Log:
ne nous privons pas de creer le repertoire auto/ quand c'est possible !
Modified:
branches/spip-2.1/ecrire/exec/charger_plugin.php
Ah ben non car ne pas créer auto/ permet de ne pas autoriser à charger
des plugins. Ou alors il faut un autre mécanisme de sécu.
On Mon, Jan 25, 2010 at 10:18 PM, <cedric@yterium.com> wrote:
ne nous privons pas de creer le repertoire auto/ quand c'est possible !
-- Fil
plugins/auto/ n'est pas créé si php n'a pas le droit d'ecrire dans
plugins/, donc si tu as le bon chmod tu n'as pas de trou.
Mais peut être que ça ne suffit pas à couvrir tout les cas car tu as
des cas ou plugins/ est autorisé en ecriture pour faire des svn update
par le plugin homonyme, mais tu ne veux pas de auto/ ?
On peut aussi mettre un define qui desactive le chargement de plugins.
Mais l'idée est de simplifier la vie des webmestres débutants.
Par ailleurs, et en toute rigueur, telecharger un plugin devrait être
lié aux droits de webmestre, car c'est équivalent à ftp.
Cédric
Le 26 janvier 2010 01:12, Fil <fil@rezo.net> a écrit :
Ah ben non car ne pas créer auto/ permet de ne pas autoriser à charger
des plugins. Ou alors il faut un autre mécanisme de sécu.On Mon, Jan 25, 2010 at 10:18 PM, <cedric@yterium.com> wrote:
ne nous privons pas de creer le repertoire auto/ quand c'est possible !
-- Fil
plugins/auto/ n'est pas créé si php n'a pas le droit d'ecrire dans
plugins/, donc si tu as le bon chmod tu n'as pas de trou.
jusqu'ici SPIP assurait ce bout de sécurité, maintenant il va falloir
la gérer au niveau système, c'est moins bien je trouve
Mais peut être que ça ne suffit pas à couvrir tout les cas car tu as
des cas ou plugins/ est autorisé en ecriture pour faire des svn update
par le plugin homonyme, mais tu ne veux pas de auto/ ?
par exemple ; tu as aussi le cas alternc, où tous les fichiers
appartiennent à www-data ; c'est un modèle qui se discute, sans doute,
mais qui existe et est utilisé.
On peut aussi mettre un define qui desactive le chargement de plugins.
Mais l'idée est de simplifier la vie des webmestres débutants.
j'ai bien compris
Par ailleurs, et en toute rigueur, telecharger un plugin devrait être
lié aux droits de webmestre, car c'est équivalent à ftp.
absolument ; d'où le reproche que je fais au fait que ces droits sont
désormais réglables en base et non plus "par ftp" comme avant
-- Fil
Le 26 janvier 2010 10:07, Fil <fil@rezo.net> a écrit :
plugins/auto/ n'est pas créé si php n'a pas le droit d'ecrire dans
plugins/, donc si tu as le bon chmod tu n'as pas de trou.jusqu'ici SPIP assurait ce bout de sécurité, maintenant il va falloir
la gérer au niveau système, c'est moins bien je trouveMais peut être que ça ne suffit pas à couvrir tout les cas car tu as
des cas ou plugins/ est autorisé en ecriture pour faire des svn update
par le plugin homonyme, mais tu ne veux pas de auto/ ?par exemple ; tu as aussi le cas alternc, où tous les fichiers
appartiennent à www-data ; c'est un modèle qui se discute, sans doute,
mais qui existe et est utilisé.On peut aussi mettre un define qui desactive le chargement de plugins.
Mais l'idée est de simplifier la vie des webmestres débutants.j'ai bien compris
Par ailleurs, et en toute rigueur, telecharger un plugin devrait être
lié aux droits de webmestre, car c'est équivalent à ftp.absolument ; d'où le reproche que je fais au fait que ces droits sont
désormais réglables en base et non plus "par ftp" comme avant
Tu veux dire que tu as des cas où des admins avaient accès à la base
sql (phpmyadmin) mais pas au FTP ?
On peut rajouter un define spécifique pour les parcs de site comme
ceux que tu gères, et qui inhibe la gestion simplifiée des webmestres
et se réfèrent à l'existant _ID_WEBMESTRES pour les opérations
concernées.
Je pense que ce type d'usage est tout de même plus dérogatoire, et
qu'il est dommage de compliquer la vie de plein d'utilisateurs qui
n'ont pas ton problème. A ce titre il me parait logique que la
solution par défaut soit simple d'emploi, et que pour les cas un peu
pointus on permettre de revenir à la solution root mais liée au ftp.
Cédric
Tu veux dire que tu as des cas où des admins avaient accès à la base
sql (phpmyadmin) mais pas au FTP ?
non, je ne suis pas dans ce cas-là ; je dis juste que ce n'est pas le
même type de contrôle : dans un cas, ftp, dans l'autre sql ou chmod.
Ce n'est pas équivalent, et pas anodin ; le cas typique est en effet
celui de la mutu, où je veux être le seul (mouhhahahhahhaha) à pouvoir
modifier des fichiers
On peut rajouter un define spécifique pour les parcs de site comme
ceux que tu gères, et qui inhibe la gestion simplifiée des webmestres
et se réfèrent à l'existant _ID_WEBMESTRES pour les opérations
concernées.
ou simplement remettre if(defined(_ID_WEBMESTRES)) => alors traiter
cette constante et pas la valeur en BDD
Je pense que ce type d'usage est tout de même plus dérogatoire, et
qu'il est dommage de compliquer la vie de plein d'utilisateurs qui
n'ont pas ton problème.
oui je suis d'accord
A ce titre il me parait logique que la
solution par défaut soit simple d'emploi, et que pour les cas un peu
pointus on permettre de revenir à la solution root mais liée au ftp.
la seule difficulté c'est qu'on finit par avoir un modèle de sécurité
complexe, et donc intrinsèquement pas sécure.
-- Fil