Suponiendo que una 'aplicación web' se ejecuta en un servidor (como apache, nginx, etc.) y está escrita en algún lenguaje de secuencias de comandos dinámico (como PHP, Ruby, etc.), tiene un malentendido sobre quién es el 'usuario'.
El usuario no es la persona que ha iniciado sesión en su aplicación; eso, y su papel en la aplicación (administrador, etc.) es completamente irrelevante para el escenario. El usuario es el usuario del sistema Linux con el que se ejecuta el proceso. El código de su sitio web se ejecuta como un solo usuario: puede ser el usuario de su servidor web (lo cual no es realmente bueno), o puede ser un usuario específico de su sitio (que es mucho mejor).
En Linux, los usuarios pertenecen a grupos: podemos agregar un usuario a otro grupo y asignar privilegios a ese grupo.
Una buena configuración hará que su servidor se ejecute como un solo usuario (llamemos a este usuario 'servidor web') y que su lenguaje de script dinámico se ejecute (por ejemplo, a través de FastCGI) como su propio usuario (un usuario por sitio; llamemos a nuestro primer usuario 'sitio1') .
Para servir sus archivos, el servidor web necesita acceso a ellos, y el lenguaje de secuencias de comandos necesita acceso a ellos. Eso significa que 'sitio1' y 'servidor web' deben poder leer sus archivos. Sin embargo, solo uno de ellos puede 'poseer' los archivos. El propietario es el 'usuario' (en usuario, grupo, otro). También necesitamos nuestro lenguaje de secuencias de comandos para poder escribir en el directorio (y leer los archivos que ha escrito). Por lo tanto, el usuario 'sitio1' necesita permisos de lectura y escritura. Dado que queremos que los permisos grupales y de otro tipo sean lo más restrictivos posible, nuestro 'propietario' será 'sitio1', y los permisos de usuario correspondientes serán de lectura y escritura.
Como no podemos especificar los permisos para nuestro servidor web como otro 'usuario', agregaremos 'servidor web' al grupo 'sitio1' (por supuesto, podría crear un grupo diferente con 'sitio1' y 'servidor web' en él. Todos los miembros de este grupo tendrán los mismos permisos. Los permisos más laxos (del usuario, grupo u otro conjunto) se aplicarán a cualquier usuario para determinar sus permisos.
Vale la pena señalar que una buena configuración no debería requerir que los archivos tengan permisos de ejecución para un lenguaje dinámico. Los archivos no se ejecutan directamente, sino que se leen en un intérprete; solo se necesitan permisos de lectura para ejecutar un script típico (uno que no escriba nada).
El permiso 'ejecutar' en los directorios tiene un significado diferente: permite el recorrido sin poder leer el contenido. Para poder leer un archivo en un directorio, un usuario debe tener permisos de 'ejecución' en CADA directorio arriba de él.
Para una aplicación web, cada archivo debe tener permisos de lectura de su propietario; de lo contrario, es un archivo bastante inútil. Ya sea que un usuario o un administrador cargue archivos (a través de su aplicación web), el 'propietario' (es decir, el lenguaje dinámico) necesita permisos de escritura. Una configuración eficiente intentará servir archivos estáticos directamente a través del servidor web, ya que los lenguajes dinámicos tienden a ser lentos para leer en archivos grandes y reproducir los contenidos. Por lo tanto, el servidor web necesita acceso de lectura a sus archivos estáticos.
Por lo tanto, los permisos mínimos de archivo pueden ser:
- Un archivo en un directorio donde residirá el usuario archivos estáticos cargados (imágenes / archivos swf / js): 640
- Un archivo en un directorio donde residirán los archivos estáticos cargados por el administrador (archivos images / swf / js): 640
- Un archivo en un directorio donde residen las bibliotecas utilizadas en la aplicación: 400 (o 440)
- Un archivo en un directorio donde residirán los scripts del lado del servidor ejecutable / navegable: 400 (o 440)
- Un archivo en un directorio donde los archivos ya existentes (txt o xml) serán editados por código en el lado del servidor: 640 o 600
- (depende de si el servidor web mostrará estos, sin modificar a veces)
Mientras, los permisos mínimos de directorio pueden ser:
- Un directorio donde residirá el usuario que cargó archivos estáticos (imágenes / archivos swf / js): 750
- Un directorio donde residirán los archivos estáticos cargados por el administrador (archivos images / swf / js): 750
- Un directorio donde residen las bibliotecas utilizadas en la aplicación: 500 (o 550) [debería ser 510 al menos]
- Un directorio donde residirán los scripts del lado del servidor ejecutable / navegable: 500 (o 550) [debería ser 510 al menos]
- Un directorio donde los archivos ya existentes (txt o xml) serán editados por código en el lado del servidor: 750 o 700
- (depende de si el servidor web servirá archivos desde aquí, a veces sin modificar)
Una vez más, su servidor web debe tener permisos de 'ejecución' en cada directorio por encima del que necesita acceso, por lo que incluso si el servidor web no sirve archivos de un directorio determinado, deberíamos otorgarle permisos de ejecución.
Es bastante común otorgarle al servidor web acceso de lectura a la mayoría de los archivos (así que cambie esos 500 a 550). Los permisos predeterminados 'algo seguros' son comúnmente 755 para directorios y 644 para archivos (sin permisos de ejecución, todos pueden leer y solo el usuario puede escribir), notará que la gran mayoría de los archivos en un sistema Linux tienen estos permisos.
Tenga en cuenta que los "otros" permisos se refieren a cualquier usuario del sistema que no sea el propietario o el grupo (es decir, todos los usuarios restantes del sistema). Mantener sus 'otros' permisos restrictivos es bueno, porque estos usuarios son desconocidos, no les ha dado permiso explícitamente. Los otros permisos son a menudo los más fáciles de aprovechar en un sistema comprometido (por ejemplo, una de las razones por las que / tmp es un objetivo común).
En el contexto de lo anterior, no creo que sus dos últimas preguntas sean tan relevantes. Establezca sus permisos de directorio en 550 (y los permisos de archivo en 440), y luego otorgue al usuario permisos de escritura para los directorios en los que su aplicación escribirá (es decir, directorio: 750; archivo: 640).
(Obviamente, necesitará permisos de escritura para cargar los archivos, pero si lo desea, puede eliminarlos después, sin embargo, posiblemente, si alguien está escribiendo en un directorio en el que solo el propietario puede escribir, su cuenta se ha visto comprometida, lo cual es uno de las razones para mantener permisos restrictivos).