He estado pasando unas horas en este asunto, y a pesar del alto número de puestos de trabajo relacionados con ella, no puedo resolverlo. Tengo un Fedora 20 cuadro con Nginx + PHP-FPM que funcionó bastante bien hasta el día de hoy (después de que me vuelve a cargar el php-fpm.servicio supongo). Nginx es servir archivos estáticos con ningún problema, pero cualquier archivo PHP desencadena un error 403.

Los permisos están bien, nginx y php-fpm se ejecuta bajo el usuario «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

El servido de los archivos se han establecido para nginx usuario así, incluso me terminó chmoding 777 a los archivos a intentar, pero aún así «Acceso denegado» para los ficheros PHP.

A continuación es un servidor de mi Nginx config:

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;
        }
}

El PHP-FPM piscina:

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

Para las versiones:

php-5.5.11 (así como php-fpm-5.5.11 de curso)

nginx-1.4.7

Estoy agregando el Nginx registro de error:

 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"

Y precisa que security.limit_extensions es correcta, establece: security.limit_extensions = .php.

Acerca de la ruta de los permisos, /var/www/html puede ser atravesado.
Lo que me estoy perdiendo?

  • Sé que suena raro, pero ¿usted compruebe si ha editado el derecho de php.archivo ini con respecto a limit_extensions? Hice este error el otro día..
  • limit_extensions está presente sólo en el DF piscina, para mí con Fedora 20 en /etc/php-fpm.d/www.conf.. Pero gracias Juan
  • ¿has probado la configuración de la fastcgi_pass a la dirección de socket en lugar de la serveraddress (por ejemplo, unix:/var/run/php-fpm/php-fpm.calcetín;)?
  • Sí he probado este, pero el resultado es el mismo. Me estoy quedando sin ideas con este problema..
  • Bueno.. podría establecer el fastcgi_param SCRIPT_FILENAME a $fastcgi_script_name, recarga de fpm y probar de nuevo? Sin $document_root
  • El mismo problema Juan, thx
  • Sí, es un poco vergonzoso, pero he tenido este problema hace dos semanas y no me escribe cómo lo resuelto, por supuesto.. de todos Modos, aquí está mi última idea y yo un poco creo que fue la cosa: Eliminar todo, desde la security.limit_extensions por lo que se ve como esto: security.limit_extensions = ..
  • He intentado demasiado ;] Pero sin éxito. Luego me da un error 404, incluso si el archivo existe. Registro de Error: 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" hilo sugiere establecer a FALSE demasiado, mismo resultado.
  • Eh.. creo que estamos yendo en la dirección correcta 😉 por favor, mantenga el limit_extensions vacío y se incluyen fastcgi_split_path_info ^(.+\.php)(/.+)$;en su bloque de ubicación e intentar de nuevo con y sin el $doc_root en SCRIPT_FILENAME
  • argh, mismo error 404
  • intente esto: 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;}
  • Juan, he encontrado una solución y me siento estúpido al respecto. En el php.ini, me cambié el cgi.fix_pathinfo de 0 a 1 y todo lo que está trabajando ahora. Gracias por su tiempo, apoyo ayudado! ;]
  • Genial!!! Voy a responder con todas las soluciones posibles para referencia en el futuro.. Usted no tiene que aceptar, por supuesto!

InformationsquelleAutor feub | 2014-04-30

6 Comentarios

  1. 38

    Aquí están algunas de las posibles soluciones:

    1. En su php-fpm http://www.conf conjunto de security.limit_extensions a .php o .php5 o lo que se adapte a su entorno. Para algunos usuarios, la eliminación total de todos los valores o ajuste a FALSE era la única manera de hacerlo funcionar.

    2. En su archivo de configuración de nginx conjunto fastcgi_pass a su dirección de socket (por ejemplo,unix:/var/run/php-fpm/php-fpm.sock;) en lugar de la dirección del servidor y el puerto.

    3. Comprobar su SCRIPT_FILENAME fastcgi param y establecer de acuerdo a la ubicación de sus archivos.

    4. En su archivo de configuración de nginx incluyen fastcgi_split_path_info ^(.+\.php)(/.+)$; en la ubicación de un bloque donde todos los demás fastcgi parámetros están definidos.

    5. En su php.ini conjunto cgi.fix_pathinfo a 1

    • Estás seguro de que es seguro para establecer fix_pathinfo a 1 ? Verificar serverfault.com/questions/627903/…
    • Si #1 y #4 se implementan, es perfectamente seguro para implementar #5. En realidad… #1 y #5 se propone para .php y 1 respectivamente en PHP 5.5.
    • Yo estaba tratando de hacer .los archivos html para ejecutar como .archivos php, por lo que #1 con «sudo systemctl restart php7.0-fpm» que hizo por mí. Saludos.
    • Chicos no es seguro. En NGINX página web oficial dice que se abre un agujero de seguridad que le permite subir algo.
  2. 8

    Por favor, tenga en cuenta que la solución anterior (conjunto de cgi.fix_pathinfo a 1) es un terrible idea. Ver https://nealpoole.com/blog/2011/04/setting-up-php-fastcgi-and-nginx-dont-trust-the-tutorials-check-your-configuration/ para una buena visión general.

    El problema es, probablemente, abajo a la aplicación de confiar en PATH_INFO. Habilitar el registro de acceso de php para obtener más información acerca de cómo su aplicación está llamada a ayudar a depurar este problema.

    Una vez más, sólo para estar seguro – la aceptación de la solución es un terrible idea, y es probable que obtener su sitio hackeado.

  3. 2

    No te olvides de reiniciar php5-fpm servicio después de cambiar de php.ini!!

    servicio php5-fpm reiniciar
    o
    servicio php5-fpm recargar

    fpm prestarts php5 por lo que no es suficiente para reiniciar nginx para que los cambios se apliquen.

  4. 0

    Para tener una referencia de los que vienen después:
    En la conf de tu sitio intente agregar:
    fastcgi_param PATH_INFO $fastcgi_path_info;
    También mira lo que SELinux está haciendo. Para desactivarlo: setenforce 0
    Pero, a continuación, la figura de lo que script es el problema y volver a poner a setenforce 1

  5. 0

    Esto también puede suceder si no hay index.php en tu vhost raíz del documento.

    Cuidadosamente una doble comprobación de la www_root parámetro en la configuración de nginx. A continuación, compruebe que el archivo php que está intentando conseguir que realmente está allí.

    En mi caso, que mal escrito el vhost doc ruta de acceso raíz y así apuntó a un directorio vacío, produciendo un 403.

  6. 0

    Puede estar relacionada con selinux. Si utiliza el carpeta compartida de Virtual Box, usted no puede cambiar los permisos de acceso en esta carpeta en Linux. Por lo tanto, se puede resolver después de cerrar selinux.

Dejar respuesta

Please enter your comment!
Please enter your name here