Accès refusé (403) pour les fichiers PHP avec Nginx + PHP-FPM

J'ai passé quelques heures sur ce problème et, malgré le nombre élevé de postes liés à elle, je ne peut pas le résoudre. J'ai une Fedora 20 boîte avec Nginx + PHP-FPM qui marchait très bien jusqu'à aujourd'hui (après j'ai rechargé php-fpm.service je suppose). Nginx est de servir les fichiers statiques avec pas de problème, mais n'importe quel fichier PHP déclenche une erreur 403.

Les autorisations sont ok, nginx et php-fpm sont en cours d'exécution en vertu de l'utilisateur "nginx":

root     13763  0.0  0.6 490428 24924 ?        Ss   15:47   0:00 php-fpm: master process (/etc/php-fpm.conf)
nginx    13764  0.0  0.1 490428  7296 ?        S    15:47   0:00 php-fpm: pool www
nginx    13765  0.0  0.1 490428  7296 ?        S    15:47   0:00 php-fpm: pool www
nginx    13766  0.0  0.1 490428  7296 ?        S    15:47   0:00 php-fpm: pool www
nginx    13767  0.0  0.1 490428  7296 ?        S    15:47   0:00 php-fpm: pool www
nginx    13768  0.0  0.1 490428  6848 ?        S    15:47   0:00 php-fpm: pool www

Les fichiers ont été mis à nginx de l'utilisateur en tant que bien, j'ai même fini chmoding 777 de ces fichiers pour essayer, mais toujours "Accès refusé" pour tous les fichiers PHP.

Ci-dessous est un serveur de ma config Nginx:

server {
        listen          80;
        server_name     localhost;

        root            /var/www/html;

         location ~ \.php$ {
            fastcgi_intercept_errors on;
            try_files $uri =404;
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
            include        fastcgi_params;
        }
}

Le PHP-FPM piscine:

[www]
...
listen = 127.0.0.1:9000
user = nginx
group = nginx
...

Pour les versions:

php-5.5.11 (ainsi que php-fpm-5.5.11 bien sûr)

nginx-1.4.7

Je suis l'ajout de la Nginx journal des erreurs:

 FastCGI sent in stderr: "Access to the script '/var/www/html' has been denied (see security.limit_extensions)" while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: localhost, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "xxx.xxx.xxx.xxx"

Et précise que security.limit_extensions est correct, mis à: security.limit_extensions = .php.

Sur le chemin des autorisations, /var/www/html peut être parcouru.
Ce qui me manque?

  • Je sais que ça paraît bizarre, mais avez-vous vérifiez si vous avez édité le droit de php.fichier ini qui concerne limit_extensions? J'ai fait cette erreur l'autre jour..
  • limit_extensions est présent uniquement dans le FPM de la piscine, pour moi avec Fedora 20 dans /etc/php-fpm.d/www.conf.. Mais merci John
  • avez-vous essayé le réglage de la fastcgi_pass à l'adresse de socket au lieu de la serveraddress (par exemple unix:/var/run/php-fpm/php-fpm.chaussette;)?
  • Oui j'ai essayé ça aussi, mais le résultat est le même. Je suis à cours d'idées avec ce problème..
  • Eh bien.. pourriez-vous définir la fastcgi_param SCRIPT_FILENAME à $fastcgi_script_name, recharger fpm et essayer de nouveau? Sans $document_root...
  • Le même problème Jean, thx
  • Ouais c'est un peu gênant, mais j'ai eu ce problème il y a deux semaines et je n'ai pas d'écrire comment je l'ai résolu, bien sûr.. de toute façon, voici ma dernière idée et je pense que c'était la chose: tout Supprimer de la security.limit_extensions de sorte qu'il ressemble à ceci: security.limit_extensions = ..
  • J'ai essayé aussi ;] Mais sans succès. Ensuite, j'obtiens une erreur 404, même si le fichier existe. Journal des erreurs: FastCGI sent in stderr: "Unable to open primary script: /var/www/html (Success)" while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: localhost, request: "GET /info.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "xxx.xxx.xxx.xxx" du fil a suggéré de le mettre à FALSE trop, même résultat.
  • Hein.. je pense que nous nous dirigeons dans la bonne direction 😉 s'il vous plaît garder le limit_extensions vide et comprennent fastcgi_split_path_info ^(.+\.php)(/.+)$;dans votre emplacement de bloc et essayez de nouveau avec et sans le $doc_root dans SCRIPT_FILENAME
  • argh, même erreur 404
  • essayez ceci: location ~ \.php$ { include /etc/nginx/fastcgi_params; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;}
  • John, j'ai trouvé une solution et je me sens stupide à ce sujet. Dans le php.ini, je suis passé de la cgi.fix_pathinfo de 0 à 1 et tout fonctionne maintenant. Je vous remercie pour votre temps, vous soutenez aidé! ;]
  • Super! Je vais répondre à toutes les solutions possibles pour référence future.. Vous n'avez pas à accepter, bien sûr!

InformationsquelleAutor feub | 2014-04-30
  1. 38

    Voici quelques solutions possibles:

    1. Dans votre php-fpm http://www.conf ensemble security.limit_extensions à .php ou .php5 ou tout ce qui convient à votre environnement. Pour certains utilisateurs, le fait d'enlever complètement toutes les valeurs ou la mise au FALSE était le seul moyen de le faire fonctionner.

    2. Dans votre fichier de configuration de nginx fastcgi_pass à votre adresse de socket (par exemple unix:/var/run/php-fpm/php-fpm.sock;) au lieu de l'adresse de votre serveur et le port.

    3. Vérifier votre SCRIPT_FILENAME fastcgi param et de le définir en fonction de l'emplacement de vos fichiers.

    4. Dans votre fichier de configuration de nginx inclure fastcgi_split_path_info ^(.+\.php)(/.+)$; dans l'emplacement du bloc où tous les autres fastcgi paramètres sont définis.

    5. Dans votre php.ini ensemble cgi.fix_pathinfo à 1

    • Êtes-vous sûr est sûr pour définir fix_pathinfo à 1 ? Vérifier serverfault.com/questions/627903/...
    • Si #1 et #4 sont mis en œuvre, il est parfaitement sûr pour mettre en œuvre le n ° 5. En fait... #1 et #5 sont, par défaut, .php et 1 respectivement en PHP 5.5.
    • J'ai essayé d'obtenir .html fichiers à exécuter en tant que .php les fichiers, n ° 1 ci-dessus avec "sudo systemctl restart php7.0-fpm" il l'a fait pour moi. Des acclamations.
    • Les gars c'est pas sûr. Dans NGINX consultez le site web officiel il est dit qu'il s'ouvre un trou de sécurité qui permet de télécharger quelque chose.
    InformationsquelleAutor VF_
  2. 8

    Veuillez noter que la solution ci-dessus (set cgi.fix_pathinfo à 1) est un terrible idée. Voir https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-and-nginx-dont-trust-the-tutorials-check-your-configuration/ pour une bonne vue d'ensemble.

    Le problème est probablement vers le bas à votre demande en s'appuyant sur PATH_INFO. Activer la journalisation des accès de php pour obtenir plus d'informations sur la façon dont votre application est appelé pour vous aider à déboguer ce problème.

    Encore une fois, juste pour être sûr que la solution retenue est un terrible idée, et il va probablement obtenir votre site piraté.

    InformationsquelleAutor mdekkers
  3. 2

    Ne pas oublier de redémarrer php5-fpm service après un changement de php.ini!!

    service php5-fpm redémarrer
    ou
    service php5-fpm recharger

    fpm prestarts php5, donc il n'est pas suffisant pour redémarrer nginx pour que les modifications soient appliquées.

    InformationsquelleAutor Eduard Pertíñez
  4. 0

    Pour la référence de ceux à venir plus tard:
    Dans la conf de votre site, essayez d'ajouter:
    fastcgi_param PATH_INFO $fastcgi_path_info;
    Regardez aussi ce que SELinux est en train de faire. Pour la désactiver: setenforce 0
    Mais alors la figure de ce script est de la question et de remettre la setenforce 1

    InformationsquelleAutor Cong IT
  5. 0

    Cela pourrait également se produire si il n'y a pas de index.php dans votre vhost racine du document.

    Soigneusement double-vérifier la www_root paramètre dans votre nginx configuration. Ensuite, vérifiez que le fichier php que vous essayez de frapper est réellement là.

    Dans mon cas, j'ai mal tapé le vhost doc chemin de la racine et donc de le signaler à un répertoire vide, ce qui donne une 403.

    InformationsquelleAutor joe_flash
  6. 0

    Elle peut être liée à selinux. Si vous utilisez le dossier partagé de Virtual Box, vous ne pouvez pas modifier les autorisations d'accès à ce dossier dans Linux. Par conséquent, vous pouvez le résoudre après la fermeture de selinux.

    InformationsquelleAutor 筱枫泠