¿Cómo configurar los permisos de Linux para la carpeta WWW?

Solución 1:

Después de investigar más, parece que otra forma (posiblemente mejor) de responder a esto sería configurar la carpeta www de esta manera.

1. sudo usermod -a -G developer user1 (añadir cada usuario al grupo de desarrolladores)
2. sudo chgrp -R developer /var/www/site.com/ para que los desarrolladores puedan trabajar allí
3. sudo chmod -R 2774 /var/www/site.com/ para que solo los desarrolladores puedan crear/editar archivos (otros/mundo pueden leer)
4. sudo chgrp -R www-data /var/www/site.com/uploads para que www-data (apache/nginx) pueda crear cargas.

Desde git se ejecuta como lo llama el usuario, entonces, siempre que el usuario esté en el grupo de "desarrolladores", debería poder crear carpetas, editar archivos PHP y administrar el repositorio de git.

Nota:En el paso (3):'2' en 2774 significa 'establecer ID de grupo' para el directorio. Esto hace que los nuevos archivos y subdirectorios creados en él hereden el ID de grupo del directorio principal (en lugar del grupo principal del usuario) Referencia:http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

Solución 2:

No estoy seguro de si es "correcto", pero esto es lo que hago en mi servidor:

• /var/www contiene una carpeta para cada sitio web.
• Cada sitio web tiene un propietario designado, que se establece como el propietario de todos los archivos y carpetas en el directorio del sitio web.
• Todos los usuarios que mantienen el sitio web se colocan en un grupo para el sitio web.
• Este grupo se establece como el propietario del grupo de todos los archivos y carpetas en el directorio.
• Cualquier archivo o carpeta que deba ser escrito por el servidor web (es decir, PHP) tiene su propietario cambiado a www-data, el usuario con el que se ejecuta apache.

Tenga en cuenta que debe tener habilitado el bit de ejecución en los directorios para que pueda enumerar los contenidos.

Solución 3:

Después de investigar más, parece que git/svn HERRAMIENTAS NO son un problema ya que se ejecutan como cualquier usuario que los esté usando. (¡Sin embargo, los demonios git/svn son un asunto diferente!) Todo lo que creé/cloné con git tenía mis permisos y la herramienta git figuraba en /usr/bin que se ajusta a esta tesis.

Permisos de Git resueltos.

Los permisos de usuario parecen solucionarse agregando todos los usuarios que necesitan acceso al directorio www al www-data grupo en el que se ejecuta apache (y nginx).

Entonces parece que una respuesta a esta pregunta va así:

Por defecto /var/www es propiedad de root:root y nadie puede agregar o cambiar archivos allí.

1) Cambiar propietario del grupo

Primero necesitamos cambiar el grupo de directorio www para que sea propiedad de "www-data" en lugar del grupo "raíz"

sudo chgrp -R www-data /var/www

2) Agregar usuarios a www-data

Luego, debemos agregar el usuario actual (y cualquier otra persona) al grupo www-data

sudo usermod -a -G www-data demousername

3) Directorio CHMOD www

Cambie los permisos para que SOLO el propietario (raíz) y todos los usuarios del grupo "www-data" puedan rwx (leer/escribir/ejecutar) archivos y directorios (nadie más debería poder acceder a ellos ).

sudo chmod -R 2770 /var/www

Ahora todos los archivos y directorios creados por cualquier usuario que tenga acceso (es decir, en el grupo "www-data") serán legibles/escribibles por apache y, por lo tanto, php.

¿Es esto correcto? ¿Qué sucede con los archivos creados por PHP/Ruby? ¿Pueden acceder a ellos los usuarios de www-data?

Solución 4:

La adherencia no es herencia de permisos. La permanencia en un directorio significa que solo el propietario de un archivo, o el propietario del directorio, puede cambiar el nombre o eliminar ese archivo en el directorio, a pesar de que los permisos indiquen lo contrario. Así 1777 en /tmp/.

En Unix clásico, no hay herencia de permisos basada en el sistema de archivos, solo en el umask del proceso actual. En *BSD, o Linux con setgid en el directorio, el campo de grupo de los archivos recién creados se configurará igual que el del directorio principal. Para cualquier otra cosa, debe consultar las ACL, con la ACL 'predeterminada' en los directorios, que le permiten tener permisos heredados.

Debe comenzar definiendo:* qué usuarios tienen acceso al sistema* cuál es su modelo de amenaza

Por ejemplo, si está realizando alojamiento web con varios clientes y no desea que vean los archivos de los demás, entonces puede usar un grupo común de "webcusts" para todos esos usuarios y un modo de directorio de 0705. Luego, los archivos servidos por el proceso del servidor web (no en "webcusts") verá los Otros permisos y será permitido; los clientes no pueden ver los archivos de los demás y los usuarios pueden jugar con sus propios archivos. Sin embargo, esto significa que en el momento en que permite CGI o PHP tiene para asegurarse de que los procesos se ejecuten como el usuario específico (una buena práctica de todos modos, para múltiples usuarios en un host, por responsabilidad). De lo contrario, los clientes podrían meterse con los archivos de los demás haciendo que un CGI lo haga.

Sin embargo, si el usuario de tiempo de ejecución de un sitio web es el mismo que el propietario del sitio web, entonces tiene problemas para no poder proteger el contenido de los abusadores en el caso de un agujero de seguridad en el script. Ahí es donde ganan los hosts dedicados, para que pueda tener un usuario en tiempo de ejecución distinto del propietario del contenido estático y no tener que preocuparse tanto por la interacción con otros usuarios.

Solución 5:

Creo que la mejor manera de hacer esto es usando ACL de Posix. Es cómodo trabajar con ellas y ofrecen toda la funcionalidad que necesita.

http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs