Dev Faq
9
votes

CHMOD 640 pour le fichier téléchargé après le patch SESTE 7405

Après avoir installé le patch SESTE 7405, nous avons remarqué un problème de téléchargement d'images de l'administrateur. Toutes les autorisations de fichier sont définies sur CHMOD 640 qui les rend inaccessibles à tous les utilisateurs.

existe une solution qui n'implique pas de réécrire le fichier /lib/varien/file/uploader.php?

3 commentaires

Les questions sur l'administration des infrastructures liées au serveur professionnel ou au réseau sont hors tension pour le débordement de la pile, à moins qu'elles impliquent directement des outils de programmation ou de programmation. Vous pourrez peut-être obtenir de l'aide sur défaut de serveur .

Petite note: Vous pouvez modifier le chmod avec PHP (tant que PHP a les autorisations) chmod ($ filepath, $ new_chmod); si les fichiers doivent être téléchargés par l'utilisateur / le groupe du serveur Web.

La solution ci-dessous prouve qu'il s'agit d'un problème lié au serveur, partiellement. La solution ne résout pas complètement toutes les problèmes avec le changement CHMOD 640 du patch SESSE 7405, mais cela en résout quelques-uns.

5 Réponses :

-1
votes

Regardez sur ceci: https://community.magento.com/t5/security-patches/adifient-installing-supee-7405-Can-no-longer-add-or- Change-images / TD-P / 26785 / Page / 3

Changer le code upload.php a fonctionné pour toutes mes installations. xxx

4 commentaires

Veuillez lire la question. Modification de la lib / varien / fichier / upploader.php n'est pas une bonne solution car elle va briser les futurs correctifs. C'est mieux comme une aide temporaire jusqu'à ce qu'une vraie solution soit rendue publique.

Il n'est pas nécessaire d'éditer des fichiers principaux, cela peut être fait sous forme de remplacement. Copier /lib/varien/file/uploader.php to /app/code/local/varien/file/uploader.php et modifiez le fichier copié avec les modifications de l'autorisation suggérée ci-dessus. Cela devrait être la solution préférée car la réponse de @mtsley ci-dessus ne répond pas à certains problèmes courants avec la configuration du serveur.

J'essaie de changer uploader.php mais ne travaille pas pour moi. J'essaie aussi d'ajouter le même fichier à / app / code / local / varien / fichier /. Mais aucun changement, il télécharge à nouveau l'image avec 0640. Y a-t-il plus de fichiers à réparer?

Veuillez noter que ce n'est pas une bonne solution. Il sape le but du correctif de sécurité qui protège vos images d'avoir des informations de carte de crédit stockées dans elles.

6
votes

Une nouvelle version de Supee-7405 a été publiée qui résout ce problème:

HTTP : //magento.com/security/patches/supee-7405

mis à jour le 23 février 2016

Les versions mises à jour de cette version sont maintenant disponibles. Les mises à jour ajoutent une assistance pour PHP 5.3 et des problèmes d'adresse avec les autorisations de téléchargement de fichiers, les charrettes de fusion et les API de savon expérimentées avec la version originale.

Notez que même sans le correctif révisé, vous pouvez corriger le problème à l'aide des autorisations de fichier recommandées (voir ci-dessous).

Magento s'attend à ce que le serveur Web possède le serveur de site :

http: // devdocs.magento.com/guides/m1x/install/installer-privilsges_after.html#privs-adifter

Vous pouvez résoudre ce problème en faisant le serveur Web du propriétaire des fichiers. xxx

Le nom d'utilisateur du serveur Web est communément www-data ou apache .

Si vous suivez les instructions Dans le lien ci-dessus, le serveur Web aura accès à tous les fichiers et d'écriture d'accès aux fichiers multimédia et aux fichiers var. Cela devrait être tout ce dont vous avez besoin pour un fonctionnement typique du site. Si vous devez utiliser Magento Connect, vous devez donner temporairement accès à l'accès à tous les fichiers.

Toutes les autorisations de fichier sont définies sur CHMOD 640 qui les rend inaccessibles à tous les utilisateurs.

Seul seul l'utilisateur du serveur Web a besoin d'accéder aux fichiers. Il n'est pas nécessaire d'accorder des autorisations à tous les utilisateurs.

Vous pouvez accorder l'accès à un utilisateur spécifique si, par exemple, vous devez modifier ou télécharger des fichiers via FTP. Dans ce cas, ce que je fais est défini un utilisateur qui possède le système de fichiers et définit le groupe des fichiers sur le serveur Web: xxx

Les commandes ci-dessus donneront à votre propriétaire de votre système de fichiers Lecture / écriture Accès à tout et au serveur Web Lire l'accès à tout. Le serveur Web pourra également écrire sur les répertoires multimédia et var.

13 commentaires

Je n'ai jamais pensé regarder dans cette direction. Je vais donner cela un essai et voir si cela fonctionne.

Remarque: J'ai marqué cela comme une solution, cependant, j'ai toujours rencontré des problèmes lors de l'utilisation de cette méthode. Par exemple, nous utilisons un curseur d'image JavaScript sur notre page d'accueil. Après avoir ajouté CHOWN -R au serveur, l'image apparaît dans la vue miniature de l'administrateur, mais à l'extrémité frontale (visiteur / invité), l'utilisateur sale présente une erreur 403 (interdite) lors de la tentative de visualisation de fichier.

@Jared qui sonne comme il y a toujours un problème d'autorisations. Le serveur Web a-t-il lu accès à l'image? Notez que Magento peut redimensionner des images, l'image affichée sur le frontage n'est pas nécessairement la même image affichée sur le backend.

Il se peut que vous ayez raison. J'ai testé la solution sur trois modules: l'ajout d'une nouvelle image à un produit existant n'a pas été affiché dans l'administrateur, mais est apparu à l'avant. Mon module personnalisé où l'image / fichier est mis à disposition au téléchargement fonctionnant parfaitement dans la fin de l'avant et du dos. Enfin, le curseur frontal de la troisième page a échoué à la fois les tests d'image frontale et arrière. J'ai mis notre serveur de dev en mode de maintenance pour effectuer quelques tests supplémentaires et confirmer quelques éléments. Cela sonne cependant comme une question d'autorisations. J'ai peut-être manqué un autre changement de patch.

J'ai une solution, mais elle est spécifique à l'environnement de mon serveur et peut ne pas aider les autres personnes à sortir. Ceci est dans la bonne direction, donc je quitte cela comme la réponse correcte et postera ma réponse aussi bien ci-dessous.

Si votre site Web fonctionne comme personne, sont-ils une implication de sécurité dans la modification du groupe de tous vos fichiers magento en no-groupe? Cela invalidera-t-il tout le point du patch?

@Dom si seul le serveur Web est en marche comme personne, alors je ne pense pas qu'il y ait une différence. Ma compréhension est que personne: nogroup est utilisé pour un accès général non privilégié. Si vous avez d'autres processus en cours d'exécution comme personne, ils auront accès à tous les fichiers de site, y compris le fichier local.xml. Cela n'a rien vraiment à voir avec le patch. Voir: Appsec-1306 magento.com/security/patches/supee-7405

@mtsley Je suppose que j'essaie de comprendre quelle amélioration de la sécurité le patch fait en veillant à ce que la permission pour les autres est nulle. Je peux comprendre nier l'exécution des fichiers pouvant être téléchargés. Si vous avez fini par avoir les fichiers en tant que phpuser: NogRoup, vous n'êtes pas de vous détendre, les autres ne peuvent pas voir le fichier - restriction que le patch impose-t-il?

@Dom Avant le correctif, les autorisations ont été définies sur 777 chmod ($ destinationfile, 0777); . En faire 640 aborde le problème. Détente de la détente à 644 œuvres également, mais est incompatible avec le Principe du moindre privilège . Le patch est principalement destiné à résoudre le problème avec le fichier exécutable.

@mtsley qui a du sens maintenant, merci. J'aime votre solution d'utilisation de GID et de modifier le groupe de tous les fichiers sur le serveur Web, mais je crains que les scripts CPanel ne s'attendent pas à cela, alors pour l'instant, j'ai remplacé le variateur / fichier / uploader.php avec 644 autorisations. Compte tenu du tollé des forums de Magento, prévoyez-vous que Magento changera le fichier principal à 644?

@ Donnez-vous concernant CPanel, vous n'avez toujours pas besoin d'accorder des autorisations à tous les utilisateurs. Avec SUPHP, les fichiers PHP sont accessibles lorsque le propriétaire du système de fichiers et les fichiers non PHP sont accessibles en tant que serveur Web. En ce qui concerne la modification des autorisations à 644, je ne sais pas si elles le feront ou non. Je ne pense pas qu'il y ait une affaire d'utilisation qui ne peut pas être traitée en corrigeant les autorisations de fichier.

@mTinsley sur mes environnements d'hébergement, Apache exécute comme personne. Pour que Apache soit capable de servir des images téléchargées, ces images doivent soit avoir une permission O + R ou avoir un groupe sans groupe. Mon inquiétude est que cPanel / WHM génère des comptes dans lesquels le Webroot est propriétaire et regroupé avec l'utilisateur de compte, et je me demandais si les différents scripts CPPanel / WHML fonctionnaient, exigent ou attendent ce propriétaire: groupe

@ Domaine d'être honnête, je ne suis pas trop familier avec Whm et j'ai tendance à l'éviter complètement quand il s'agit de Magento. Vous voudrez peut-être essayer de demander une erreur de serveur.

1
votes

Nous avons résolu le problème de nos environnements, cependant, je ne suis pas sûr de combien d'aide cela sera pour tous les autres. Même si je ne suis pas un ingénieur en réseau, je vais essayer de l'expliquer. Si suffisamment de gens trouvent ce post utile, je vais le marquer comme correct. De plus, veuillez noter que même si le problème est apparu de Magento's Suppee 7405 Patch, la solution est basée sur le réseau, non basée sur le code.

Je pense que le but de la modification de Chmod dans le patch consistait à empêcher les pirates de détournement de vos images et de stocker des données sensibles au sein d'eux (le piratage de l'en-tête de paiement, par exemple). Pour éviter ce piratage, ils limitent tous les accès aux fichiers / images téléchargés via CHMOD 640.

avec cela dit ...

Le dernier patch à Magento 1.x semble nécessiter une modification de la configuration de l'environnement . Comme l'a dit l'un de nos ingénieurs de réseau, ils supposent que nous utilisons Apache avec mod_php, qui lit et écrit tous les fichiers en tant qu'utilisateur Apache. Toutefois, si vous utilisez FCGI ou SUPHP, les fichiers seraient écrits comme l'utilisateur de domaine. Selon votre environnement, vous devrez peut-être ajouter Apache à vos groupes et lui permettre de lire les fichiers.

Essayez d'abord la solution de Chown -R, et si cela ne fonctionne pas, vous devrez peut-être contacter votre hôte ou ajouter Apache à vos "groupes" afin qu'il ait accès au propriétaire.

1 commentaires

Avec SUPHP, je pense que vous pouvez simplement CHAPEL -R utilisateur: utilisateur où "utilisateur" est tout ce que le serveur Web est en cours d'exécution. Je pense que ce sera la solution pour cPanel aussi.

0
votes

La réponse acceptée est une bonne solution.

Si vous ne pouvez pas modifier la propriété (peut-être parce que vous êtes sur un serveur partagé), vous pouvez exécuter des travaux de cron pour modifier la permission de fichiers sur les fichiers nouvellement téléchargés. P> 

*/3 * * * * find /path/to/magento/ -type f -perm 640 -exec chmod 644 {} \;

*/3 * * * * find /path/to/magento/ -type d -perm 750 -exec chmod 2755 {} \;

0 commentaires
1
votes

S'il vous plaît aller sur ce fichier xxx

et simplement modifier la ligne n ° 220 et modifier chmod ($ destinationfile, 0640) to chmod ($ destinationfile, 0644)

Ça fonctionne.

1 commentaires

Honte sur Magento! Cela devrait certainement être une option de configuration comme la configuration de chaque réseau n'est pas la même. Tant que ce n'est pas le cas, je vais appliquer à contrecœur le hack de base: /

Articles qui pourrait vous intéresser :

Pourquoi est-ce que j'obtiens une erreur laravel lors de la création d'un nouveau projet?
Select2 ne s'affiche pas correctement dans le mode bootstrap
Laravel Echo n'écoute pas
La validation de la demande de formulaire ne fonctionne pas. Il charge juste la page d'accueil dans Postman