¿Por qué la necesidad de 755 permisos para / var / www /? ¿Por qué no 700 después de chown? - Linux, apache, web, permisos.

Mi directorio de Apache para almacenar archivos es / var / www.

Si corro

sudo chown -R www-data:www-data /var/www

Esto hace que www-data sea el propietario de wwwcarpeta. Dado que todos los archivos estáticos / dinámicos serán atendidos por el usuario de Apache, ¿por qué ahora necesito otorgar permisos a esta carpeta 755? Debería funcionar dando 700 permisos, ¿verdad? Dado que con 700 permisos, el propietario (www-data) tiene permisos completos para la carpeta.

Por lo tanto, mi pregunta, ¿por qué debo ejecutar:

sudo chmod -R 755 /var/www

en lugar de

sudo chmod -R 700 /var/www

EDITAR: No estoy enfrentando ningún error. Solo estoy haciendo esta pregunta por conocimiento. Mucha gente me ha sugerido que ponga permiso 755 en la carpeta / var / www /. Solo quería saber por qué no podía usar 700.

Respuestas

El mejor diseño depende de algunos factores. Principalmente se trata de una cuestión de seguridad. Aquí hay algunas cosas para considerar:

1) ¿Desea que su servidor web puedaescribir archivos en su DocumentRoot? La mayoría de las veces la respuesta es no ... la excepción son cosas como cargar directorios. En este caso, desea algo como 755, donde el propietario / grupo es no el usuario con el que se ejecuta Apache.

2) ¿Tiene cuentas de usuario locales (comodesarrolladores) que deberían poder acceder al contenido? En caso afirmativo, es posible que desee algo como 755, root: desarrolladores para permisos, con Apache ejecutándose como "www-data" o "apache", y no en el grupo (sujeto al # 1 anterior).

3) ¿Es necesario que esos desarrolladores puedan editar el contenido (presionar un código)? En ese caso, quizás la raíz 775: los desarrolladores es mejor.

El principal problema con 700 es que requiereel propietario es el usuario con el que se está ejecutando Apache, y eso le otorga permisos completos para modificar cualquier archivo en DocumentRoot. Esto generalmente se considera una debilidad de seguridad porque, en general, el servidor web no debería modificar archivos en DocumentRoot, aparte de excepciones bastante específicas.

Una explotación común es que un atacanteengañe a su aplicación web para que cargue algo así como un script PHP malicioso en algún lugar de DocumentRoot, y luego visite esa página. Una de las contramedidas es impedir que Apache escriba en DocumentRoot a través de este tipo de permisos del sistema de archivos.