Bonsoir,
Déjà , j'espère que le titre est correct.
Sur certains sites , les serveurs (http, ftp, ssh ...) tournent tous sous l'identité du user.
Je voudrais obtenir 700 ou 600 dans ce cas pour tout le spip, mais le code force 777 ou 666.
N'est-ce pas un peu abusif ?
Ne pourrions nous pas détecter le cas à l'installation et blinder ces perms dans une constante ?
Sans troller,
bertrand Gugger a écrit :
Bonsoir,
Déjà , j'espère que le titre est correct.Sur certains sites , les serveurs (http, ftp, ssh ...) tournent tous sous l'identité du user.
Je voudrais obtenir 700 ou 600 dans ce cas pour tout le spip, mais le code force 777 ou 666.
N'est-ce pas un peu abusif ?
Ne pourrions nous pas détecter le cas à l'installation et blinder ces perms dans une constante ?Sans troller,
non, on y pense. mais il y a plein de cas selon l'hébergeur et deux méthodes qui peuvent initier des permissions contradictoires : à la main via ftp et par spip_loader (client http)
le premier truc que je te conseille de regarder c'est spip_loader qui possède une fonction de test des permissions, j'ai pas vu dans spip, si c'était le cas...
James wrote:
bertrand Gugger a écrit :
Bonsoir,
Déjà , j'espère que le titre est correct.Sur certains sites , les serveurs (http, ftp, ssh ...) tournent tous sous l'identité du user.
Je voudrais obtenir 700 ou 600 dans ce cas pour tout le spip, mais le code force 777 ou 666.
N'est-ce pas un peu abusif ?
Ne pourrions nous pas détecter le cas à l'installation et blinder ces perms dans une constante ?Sans troller,
non, on y pense. mais il y a plein de cas selon l'hébergeur et deux méthodes qui peuvent initier des permissions contradictoires : à la main via ftp et par spip_loader (client http)
le premier truc que je te conseille de regarder c'est spip_loader qui possède une fonction de test des permissions, j'ai pas vu dans spip, si c'était le cas...
dans spip , c'est 666 ou 777 , peu importe l'install
bertrand Gugger a écrit :
dans spip , c'est 666 ou 777 , peu importe l'install
que penses-tu de ça ?
James wrote:
bertrand Gugger a écrit :
dans spip , c'est 666 ou 777 , peu importe l'install
que penses-tu de ça ?
et toi de ça :
$ find . -name '*.php' ! -path '*/CACHE/*' -exec grep -iEH 'chmod.*(666|777)' {} \;
./ecrire/action/test_dirs.php: @chmod($my_dir, 0777);
./ecrire/inc/utils.php: if (!$exists) @chmod($fichier, 0666);
./ecrire/inc/flock.php: @chmod($path, 0777);
./ecrire/inc/getdocument.php: @chmod($dest, 0666);
?
James wrote:
bertrand Gugger a écrit :
James wrote:
bertrand Gugger a écrit :
dans spip , c'est 666 ou 777 , peu importe l'install
que penses-tu de ça ?
et toi de ça :
$ find . -name '*.php' ! -path '*/CACHE/*' -exec grep -iEH 'chmod.*(666|777)' {} \;
./ecrire/action/test_dirs.php: @chmod($my_dir, 0777);
./ecrire/inc/utils.php: if (!$exists) @chmod($fichier, 0666);
./ecrire/inc/flock.php: @chmod($path, 0777);
./ecrire/inc/getdocument.php: @chmod($dest, 0666);
?mmh...
dans test_dirs, il fait des tests plus larges. 775 puis 755
alors, si on commence par _SPIP_CHMOD = 0777; mais qu'on pourrait tester à l'init,
on aurait @chmod($path, _SPIP_CHMOD); et @chmod($fichier, _SPIP_CHMOD & ~0111);
ça suffirait ?
Je sais pas , mais c'est la direction ...
En fait j'imaginais l'install qui *blinde*
define(_SPIP_CHMOD, 0700) si possible , 0777 sinon
Mais vraiement *blindé* comme la connection db , un truc fixe
D'ailleurs peut-être dans ecrire/inc_connect.php , non ?
Une option suffirait peut-être.
Je n'en démords pas que c'est déterminable à l'installation (comme me suggère ton spip_loader) et blindable ôur toute la vie du spip en question.
bertrand Gugger a écrit :
Une option suffirait peut-être.
le chantier commence là :
http://trac.rezo.net/trac/spip/changeset/7538
Je n'en démords pas que c'est déterminable à l'installation (comme me suggère ton spip_loader) et blindable ôur toute la vie du spip en question.
à voir pour la suite...
James wrote:
bertrand Gugger a écrit :
Une option suffirait peut-être.
le chantier commence là :
http://trac.rezo.net/trac/spip/changeset/7538Je n'en démords pas que c'est déterminable à l'installation (comme me suggère ton spip_loader) et blindable ôur toute la vie du spip en question.
à voir pour la suite...
C'est bizarre, j'imaginais plus un :
@chmod($path, 0777 & _DIR_CHMOD);
ou
@chmod($path, 0666 & _DIR_CHMOD);
que _DIR_CHMOD soit plutôt un masque,
ça doit être la différence entre les gens optimistes et les pessimistes, mais je crois que c'est pareil 
cool, c'est dans le trunk ? le _DIR_CHMOD est blindé dans inc_connect ?
bertrand Gugger a écrit :
C'est bizarre, j'imaginais plus un :
@chmod($path, 0777 & _DIR_CHMOD);
ou
@chmod($path, 0666 & _DIR_CHMOD);que _DIR_CHMOD soit plutôt un masque,
point de vue de l'utilisateur qui définit lui-même la valeur qu'il veut (ou que spip lui calculera). umask() m'énerve tellement...
ça doit être la différence entre les gens optimistes et les pessimistes, mais je crois que c'est pareil
cool, c'est dans le trunk ? le _DIR_CHMOD est blindé dans inc_connect ?
non pas encore.
l'action test_dirs est à modifier en conséquence et les étapes d'installation doivent embarquer l'info jusqu'à la création du fichier.
bertrand Gugger wrote:
James wrote:
bertrand Gugger a écrit :
Une option suffirait peut-être.
le chantier commence là :
http://trac.rezo.net/trac/spip/changeset/7538Je n'en démords pas que c'est déterminable à l'installation (comme me suggère ton spip_loader) et blindable ôur toute la vie du spip en question.
à voir pour la suite...
C'est bizarre, j'imaginais plus un :
@chmod($path, 0777 & _DIR_CHMOD);
ou
@chmod($path, 0666 & _DIR_CHMOD);que _DIR_CHMOD soit plutôt un masque,
ça doit être la différence entre les gens optimistes et les pessimistes, mais je crois que c'est pareil
cool, c'est dans le trunk ? le _DIR_CHMOD est blindé dans inc_connect ?
Rhhaaa.... j'avais pas scrollé, inc_version.php , c'est un bon début.
Tu m'attends pas pour des tests , hein ?
James wrote:
bertrand Gugger a écrit :
C'est bizarre, j'imaginais plus un :
@chmod($path, 0777 & _DIR_CHMOD);
ou
@chmod($path, 0666 & _DIR_CHMOD);que _DIR_CHMOD soit plutôt un masque,
point de vue de l'utilisateur qui définit lui-même la valeur qu'il veut (ou que spip lui calculera). umask() m'énerve tellement...
oki, on définit positivement ce qu'on autorise.
define('_DIR_CHMOD', 0777); // laisse comme à présent
ça doit être la différence entre les gens optimistes et les pessimistes, mais je crois que c'est pareil
cool, c'est dans le trunk ? le _DIR_CHMOD est blindé dans inc_connect ?
non pas encore.
l'action test_dirs est à modifier en conséquence et les étapes d'installation doivent embarquer l'info jusqu'à la création du fichier.
Tu veux dire pas encore dans l'install ou spip_loader , mais on peut tester comme ça avec inc_version.php, c'est super !