AntiStatic Posté 21 Septembre 2005 Posté 21 Septembre 2005 Salut à tous, voila j'ai un hébergement mutualisé PHP pour lequel j'ai mis un dossier avec des droits en écriture : rw- rw- rw- pour pouvoir uploader et modifier les photos de mon site via un script PHP dont je suis certain du bon fonctionnement. Lorsque j'upload une nouvelle photo, tout va bien aucun probleme. Par contre quand j'essaie de modifier / écraser une photo qui se trouve dans ce dossier cela ne fonctionne pas. Un message d'erreur me dit que je n'est pas les droits en écriture Voici le message pour info : Warning: imagejpeg(): Unable to open '../../images/fleurs/thumbs/206.jpg' for writing in /home/httpd/vhosts/aaz-fleurs.com/httpdocs/admaster/process/do_images.php on line 58 Le plus bizarre est que lorsque j'upload une nouvelle photo, je peux la modifier / écraser pendant quelques jours, puis apres je perd les droits en écriture dessus. J'ai donc contacté mon hébergeur pour lui signaler ce qui est pour moi un bug de leur part étant donné que cela fonctionnait parfaitement avant chez un autre hébergeur. Celui-ci me répond : vous ne pouvez ecraser ou modifier un fichier que vous avez uploader via ftp via un script. Sinon pour que cela fonctionne, il faut que vos images soient en rw rw rw. La QUESTION est donc : est possible de faire en sorte sous Apache qu'un dossier et son contenu reste à jamais avec des droits en écriture ? Merci pour votre aide
AvenueDuWeb Posté 21 Septembre 2005 Posté 21 Septembre 2005 Salut, Tu passes par un script en php pour uploader ? Tu es sûr que ça marche pendant quelques jours avant de ne plus marcher du tout ? A mon avis le problème c'est que tu n'as pas les droits sur ces images, si php est compilé en CLI sur cet hébergeur, les fichiers sont uploadés avec l'UID d'apache, si par contre php est compilé en CGI avec suphp ou phpsuexec d'installer, tu dois logiquement avoir les droits sur ces fichiers. Mais ça me parait bizarre que cela fonctionne pendant quelques jours puis que ça disparaisse soudainement, à moins que ce soit volontaire de la part de l'hébergeur, mais j'ai du mal à voir l'utilité de cela. @+
AntiStatic Posté 21 Septembre 2005 Auteur Posté 21 Septembre 2005 Oui je passe par un script en PHP pour l'upload. Et je suis certains que cela marche pendant quelques jours vu que je fais des modif régulierement et du jour au lendemain cela ne fonctionne plus. Pour les droits, oui je n'ai pas les droits en écriture sur les images mais juste sur le dossiers qui le contient. Mais encore une fois, cela marche parfaitement sans avoir les doits rw rw rw sur les images pendant quelques jours. Voir meme des semaines ! J'ai l'impression que le probleme survient après le reboot de leur serveur, est possible ? Un truc qui pourra peut être etre révélateur du probleme et savoir si c'est compilé en CLI ou compilé en CGI avec suphp ou phpsuexec : lorsque je viens d'uplaodé un fichier, l'utilisateur et le groupe de ce fichier sont "Apache", dans ce cas tout fonctionne bien. Par contre lorsque cela ne fonctionne pas l'utilisateur du fichier est mon nom d'utilisateur du compte mutualisé et le groupe "psacln" ... j'avou ne pas savoir ce que c'est. Dernier point je n'est pas rencontré ce pb chez un autre hébergeur PHP, et encore moins lorsque je travail avec des hébergements mutualisé ASP sur d'autres sites que je gère. A ton avis est ce que mon hébergeur PHP peut faire en sorte que cela fonctionne correctement ?
TheRec Posté 21 Septembre 2005 Posté 21 Septembre 2005 Bonsoir, tu as défini les droits en écriture/lecture sur le dossier, mais as-tu changer les attributs des fichiers une fois qu'ils ont été uploadés ? Si ce n'est pas le cas, jette un coup d'oeuil à la fonction chmod
Dan Posté 22 Septembre 2005 Posté 22 Septembre 2005 Salut A à Z Fleurs, Pour un répertoire il faut mettre les permissions en 777 drwxrwxrwx ... parce que le droit d'exécution est en fait le droit qui permet de faire un "search" sur le répertoire. Sans celui-là tu auras des problèmes. Quant aux permissions qui s'effacent "dans le temps", je n'y crois pas. Tu as vraisemblablement modifié quelque chose, et tu ne t'en souviens plus. Possible que tu sois passé de mode 755 en mode 666 pour ce répertoire, non ? Dan
AntiStatic Posté 22 Septembre 2005 Auteur Posté 22 Septembre 2005 Ha voila Merci Dan ! Car moi non plus je ne vois comment des permissions d'écriture peuvent disparaitre juste comme ca ! Pourtant c'est bel et bien le cas. Et encore une fois au bout d'un certain temps ... Pour les droits du dossier dont je parle, ils sont bien en 777. Je les ai passer via mon client FTP : FileZilla. Par contre ca me donne : rwx rwx rwx et non pas : drwxrwxrwx avec le "d" devant ... peut-etre le probleme vient-il de la ? Mais bon a la base dès que je passe mon dossier en 777 je devrais pouvoir ecraser les fichiers qui sont dedans, et ce n'est pas le cas. La j'ai encore refais un test : j'ai supprimer une image de ce dossier, pour la ré-uploader. Comme l'image n'existé pas j'ai pu la créer via mon script PHP et du coup je peux également l'écraser je vais voir combien de temps ca tiens ... Pour info, mon compte mutualisé est géré via plesk, peut-etre est-ce également une source de probleme ?
Dan Posté 22 Septembre 2005 Posté 22 Septembre 2005 Non, le d n'est visible que lorsque tu lances une commande "ls" sous Linux. Il signifie seulement "directory" ... Pour que tu puisses écraser une image, il faut que tu aies le droit d'écriture sur celle-ci ainsi que pour le répertoire qui la contient. Ces images ont quel propriétaire ? Parce qu'il y a deux possibilités: - php tourne "normalement" en module Apache, c'est donc le user sous lequel tourne apache qui est le propriétaire (c'est souvent Apache,www ou nobody) - php tourne en suexec (avec suphp ou autre) c'est donc l'utilisateur du site web qui est propriétaire des fichiers.
AntiStatic Posté 22 Septembre 2005 Auteur Posté 22 Septembre 2005 Justement pour le propriétaire c'est bizarre, il y a deux possibilités : 1/ Lorsque je viens d'uploader une image elle a pour propriétaire / utilisateur "apache" et comme groupe "apache". Dans ce cas je peux sans aucun probleme ecraser l'image via mon script PHP. 2/ Au bout d'un certain temps qui peut varier de quelques jours à plusieurs semaines le propriétaire / utilisateur devient le nom de mon compte mutualisé chez mon hébergeur soit "aazfleurs" et le groupe "psacln". Dans ce cas je ne peux plus écraser l'image. Je pense donc qu'il doit y avoir une sorte de routine ou je ne sais pas quoi qui repasse les fichiers que je viens d'uploader de l'utilisateur "apache" vers "aazfleurs", à mon avis au reboot du serveur. Mais bon encore une fois c'est la premiere fois que je rencontre ce probleme chez un hébergeur ... d'habitude un dossier avec des droits en écriture le reste, avec son contenu, que se soit sous Apache ou IIS ...
AvenueDuWeb Posté 22 Septembre 2005 Posté 22 Septembre 2005 A mon avis ton hébergeur utilise une tâche cron pour chaque soir (ou tous les x temps) changer le propriétaire et mettre l'utilisateur. C'est une solution quand php est compilé en module apache. Mais logiquement ça devrait être l'inverse, tu ne devrais pas pouvoir écraser quand le fichier a pour propriétaire apache, mais dès qu'il le remet à ton nom tu devrais pouvoir, or là toi c'est tout l'inverse donc je n'y comprends rien. Là je donne ma langue au chat, mais quand tu auras la réponse je suis curieux de savoir. @+
destroyedlolo Posté 22 Septembre 2005 Posté 22 Septembre 2005 Tu pourrais peut etre aussi voir s'il n'utilise pas un serveur ProFTP car il permet d'ajouter des limitations plus strict que les droits Unix ... Lolo
AntiStatic Posté 23 Septembre 2005 Auteur Posté 23 Septembre 2005 Bon pour ceux qui sont curieux de savoir d'ou viens ce pb voila ce que m'a répondu mon hébergeur : En effet lors de votre publication en ftp vos fichiers prennent les droits de votre login et du groupe psacln. Mais si vous uploadez ces images via un script elles prennent le droit d'apache, ce qui est logique vu que vous passez par le serveur web pour faire votre publication.La solution pour vous serait de publier toutes vos donnees via upload et non par ftp. Toutes celles qui auront besoin d'etre ecrasee par la suite. Donc en gros, j'ai plus qu'à revoir mon script ... merci pour votre aide à tous en tout cas
AvenueDuWeb Posté 23 Septembre 2005 Posté 23 Septembre 2005 Oui donc c'est plus ou moi ce qu'on disait. Et donc tes fichiers ne sont pas pendant quelques jours modifiables et puis du jour au lendemain plus rien, cela dépent simplement de ta méthode de transfert. @+
AntiStatic Posté 23 Septembre 2005 Auteur Posté 23 Septembre 2005 C'est tout de même pour lemoins bizarre, mais bon je vais gérer ca autrement du coup
AvenueDuWeb Posté 23 Septembre 2005 Posté 23 Septembre 2005 Non non c'est tout à fait normal, j'avais le même problème avec mes clients... En FTP les fichiers prennent les droits de l'utilisateur car on ne passe pas par PHP (et c'est seulement PHP qui pose problème pas apache), et si on passe par un script et que php est en module apache (CLI) et bien les droits des fichiers uploadés par script prennent automatiquement le nom du propriétaire apache (apache, nobody...). Les seules solutions à ce problème sont de passer par suPHP (ce que personnellement j'ai fais après avoir longuement hésité), soit par phpSuexec, ou alors moins directes, l'hébergeur fait une tâche cron tous les x temps pour redonner les droits à chaque utilisateur sur ses fichiers. Le problème de phpSuexec et Suphp sont une perte de performance, une sécurité à revoir, et quelques problèmes avec les droits sur les fichiers (suPHP n'accepte pas le 777 par exemple). Avec l'ASP il n'y a visiblement pas ce type de problèmes... @+
AntiStatic Posté 23 Septembre 2005 Auteur Posté 23 Septembre 2005 Effectivement j'ai longtemps travaillé en ASP, donc serveur IIS avant de me mettre au PHP, et ce probleme n'existe pas. J'entend par "pour le moins bizarre", que pour moi un dossier avec des droits en ecriture doit le rester quelque soit la méthode d'upload du fichier ... mais bon la comparaison IIS / Apache tourne des fois au ridicule quant je contaste ce genre de pb, ou les url sensibles au case sensitive qui m'ont bien fait rigoler lors de mes premiers dev en PHP
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant