Piwigo.org

dcaillibaud · 2011-10-15 16:15:33

Bonjour,

Sur une config avec apache + cgi suexec (php est éxécuté sous un user différent d'apache), les fichiers créés dans local/combined/ sont tous en 600 et donc illisibles par apache.

J'ai remplacé partout les chmod 777 par du 755 (sinon c'est suhosin qui râle), remplacé les umask(0000) par du umask(0022) et viré tous les @ devant les fonctions de création de fichiers/dossiers.

J'ai pas d'erreur php mais les fichiers restent en 600, j'ai oublié quoi ?

Dernière modification par dcaillibaud (2011-10-15 16:16:04)

dcaillibaud · 2012-06-11 16:14:05

Avec la 2.3.4 c'est toujours le cas :-(

J'ai changé tous les umask 0 (./admin/include/functions_upload.inc.php,./include/ws_functions.inc.php, ./include/functions.inc.php) en umask(0111) mais rien n'y fait, il me créé toujours des css en 600 dans local/combined/ !

Et le site sans ses css est nettement moins joli :-S

flop25 · 2012-06-11 18:07:30

vous pouvez désactiver la combinaison js/css mais bon ce n'est pas vraiment une solution
http://fr.piwigo.org/doc/doku.php?id=pw … onf_locale

dcaillibaud · 2012-06-12 15:15:50

Désactiver la combinaison js/css ne serait effectivement pas une bonne solution, d'autant que les vignettes générées sont aussi en chmod 600, donc illisibles par le serveur web.

J'ai refais des tests avec nginx + php-fpm, ou chaque site a également un php qui tourne sous son propre user, différent de celui du serveur web (comme ma conf apache), et là une netinstall de piwigo 2.3.4 fonctionne très bien !

Piwigo n'est donc pas en cause, les réglages système des utilisateurs non plus (c'est pas le umask au niveau du user unix local qui coince), c'est la conf php.

Après avoir creusé un peu, c'est pas suexec-umask, parce que sur cette machine c'est suphp et pas suexec, donc c'était un umask=0077 dans /etc/suphp/suphp.conf !

Bref, désolé pour le bruit, ça m'apprendra à traîner de vieilles conf en ayant oublié leur contenu, ça aura au moins permis de passer enfin cette machine en nginx/php-fpm (que j'ai déjà partout ailleurs, c'est très performant, tenue à la charge x4 chez moi, mais à surveiller car j'ai de temps en temps des sockets fpm qui ne répondent plus et demandent un redémarrage de php-fpm, donc pas forcément à conseiller à tout le monde).

flop25 · 2012-06-12 15:41:09

je n'ai rien compris mais je suis bien content que vous ayez résolu le problème ;)

dcaillibaud · 2012-06-12 15:42:30

Pour info :

dcaillibaud a écrit:
J'ai changé tous les umask 0

C'était évidemment stupide car un umask 0 veut dire des créations de fichiers en 666 et des dossiers en 777, ce qui ne serait pas judicieux (très laxiste, ce n'est pas ce que fait piwigo).

Avec suhosin par exemple (une extension php pour renforcer la sécurité de php), les fichiers php contenus dans un dossier en 777 ne sont pas exécutés (ça donne une erreur 500).

Je viens de retester une install piwigo (2.3) avec suhosin et tous les fichiers/fichiers sont bien en 644/755 (sur une debian squeeze avec la conf par défaut).

olliwa · 2012-06-19 16:15:39

Cher dcaillibaud

j'ai un problème du même genre depuis plusieurs années sur une installation piwigo.

l’hébergeur est orange business

j'ai installe un dokuwiki et un spip mais impossible de faire fonctionner correctement piwigo

les éléments du dossier local/combined se créent en mode 640 et donc ne sont pas lisibles tant que je ne les change pas par ftp en mode 644!!

personne sur le forum n'a pu me donner d'explication.
voir http://fr.piwigo.org/forum/viewtopic.php?id=21070

je veux bien que ce soit un problème de configuration d'Orange Business, mais de ce cote peu d'aide a espérer "as usual":
- mais pourquoi Spip n'a pas le même problème?
il utilise pourtant aussi un cache de css et de js
ou est le fonctionnement particulier de piwigo dans sa gestion de cache?
- comment forcer la main a piwigo en modifiant le php avec un chmod?

si vous avez une idée, je suis preneur
cordialement

Dernière modification par olliwa (2012-06-19 16:17:02)

dcaillibaud · 2012-06-20 00:01:10

Il faudrait poser la question à l'hébergeur.

Sinon, il faut regarder les user/droits des fichiers générés par piwigo et dokuwiki. Dans mon cas c'était php qui créait des fichiers illisibles par le serveur web, mais lisibles par php. Pour dokuwuki je crois que tous les fichiers générés sont lus par php, mais il faudrait vérifier (regarder les header http pour les différents fichiers d'une page peut aussi aider à comprendre, par ex dans l'onglet réseau de firebug).

olliwa · 2012-06-23 19:42:53

merci pour le retour

entre temps
PLG vient de confirmer que c'est le mécanisme suExec de mon hébergeur Orange Business qui pose probleme.
en version 2.4, cela concerne aussi la gestion des images et imagettes.

[a suivre]

dcaillibaud · 2012-06-24 20:59:06

C'est pas suexec le pb, c'est la façon dont on le configure.

S'il est configuré pour que tous les fichiers écrits par php soient illisible par le serveur web, il fait ce qu'on lui dit.

Piwigo.org

Annonce

#1 2011-10-15 16:15:33

[Résolu] pb umask 2.3.0, fichiers illisibles par le serveur

#2 2012-06-11 16:14:05

Re: [Résolu] pb umask 2.3.0, fichiers illisibles par le serveur

#3 2012-06-11 18:07:30

Re: [Résolu] pb umask 2.3.0, fichiers illisibles par le serveur

#4 2012-06-12 15:15:50

Re: [Résolu] pb umask 2.3.0, fichiers illisibles par le serveur

#5 2012-06-12 15:41:09

Re: [Résolu] pb umask 2.3.0, fichiers illisibles par le serveur

#6 2012-06-12 15:42:30

Re: [Résolu] pb umask 2.3.0, fichiers illisibles par le serveur

dcaillibaud a écrit:

#7 2012-06-19 16:15:39

Re: [Résolu] pb umask 2.3.0, fichiers illisibles par le serveur

#8 2012-06-20 00:01:10

Re: [Résolu] pb umask 2.3.0, fichiers illisibles par le serveur

#9 2012-06-23 19:42:53

Re: [Résolu] pb umask 2.3.0, fichiers illisibles par le serveur

#10 2012-06-24 20:59:06

Re: [Résolu] pb umask 2.3.0, fichiers illisibles par le serveur

Pied de page des forums