Acceso a la carpeta del grupo Linux

3

Esta es una pregunta simple, estoy seguro, pero parece que no encuentro ninguna razón por la que no pueda hacer que esto funcione.

Estoy intentando configurar carpetas de grupo dentro de la raíz web para un servidor PHP. Cada departamento debe tener un grupo como este: 

/srv/www/htdocs/dev/dept1
/srv/www/htdocs/dev/dept2

Todos los usuarios en el grupo dept1 deben tener acceso de lectura / escritura a la carpeta dept1, todos los usuarios en dept2 deben tener acceso de lectura / escritura a la carpeta dept2, etc. Al intentar implementar esto, creé un grupo como este: 

sudo groupadd dept1
sudo useradd -G dept1 -m user1
cd /srv/www/htdocs/dev
mkdir dept1
sudo chown -R wwwrun:dept1 dept1
sudo chmod -R g+rwxs dept1

wwwrun es el usuario que Apache está ejecutando como. La idea es que los usuarios puedan crear / leer / actualizar / eliminar lo que quieran dentro de la carpeta de su departamento. Sin embargo, al probarlo, la cuenta de usuario puede ver el contenido de la carpeta y leer archivos, pero no crear ni escribir archivos.

¿Qué estoy haciendo mal?

linux command-line permissions Brad Westness
fuente

Respuestas:

2

Con los permisos que le dan, los usuarios en el dept1 grupo puede crear y eliminar archivos en /srv/www/htdocs/dev/dept1. Sin embargo, bajo configuraciones típicas, los archivos y subdirectorios que crearán no serán de escritura de grupo.

Puede organizar que la mayoría de los archivos se puedan escribir en grupo cambiando los de todos. umask ajuste. La configuración de umask determina qué permisos son no dado a los nuevos archivos. Por lo general, se establece en 022, lo que significa que los archivos no serán de escritura grupal ni de escritura de otro tipo, a menos que se establezca explícitamente. Puede cambiar esto a 002 para que los archivos puedan escribirse en grupo de forma predeterminada. Sin embargo, esto solo es razonable si cada usuario tiene su propio grupo privado (de lo contrario, todos los usuarios de su grupo primario podrán escribir los archivos de las personas).

Una mejor solución es asegurarse listas de control de acceso están habilitados en el sistema de archivos donde /srv/www/htdocs/dev reside (asegúrese de que el fstab la entrada contiene acl en la cuarta columna). Luego crea una ACL en srv/www/htdocs/dev/dept1 dando el dept1 Agrupe el permiso de escritura en el directorio y haga que la concesión del permiso sea heredada por las entradas recién creadas en el directorio. Esto es similar a un cambio de umask, pero está vinculado a esta ubicación particular en el sistema de archivos. Después de ejecutar los dos comandos siguientes, los permisos serán correctos en todos los casos de uso típicos. 

setfacl -R -m group:dept1:rwx /srv/www/htdocs/dev/dept1
setfacl -R -d -m group:dept1:rwx /srv/www/htdocs/dev/dept1
Gilles
fuente
Bonita explicacion Estoy curioso por ACL ahora!
invert
Los usuarios en "dept1" no podría escribir en el directorio. Sin embargo, el ACL hizo el truco. ¡Gracias!
Brad Westness
0

¿Cómo están accediendo sus usuarios a los archivos? ¿Cómo están intentando actualizarlos / crearlos? Supongo que están iniciando sesión en el servidor, pídales que ejecuten el comando 'grupos' para asegurarse de que realmente están en el grupo correcto y que deberían aparecer primero.

dmah
fuente
Los usuarios van a acceder al sistema a través de SFTP. No fue el primer grupo, pero intenté eliminar el usuario y volver a agregar con el comando sudo useradd -g dept1 -m user1 y obtuvo el mismo resultado (el usuario no puede crear o escribir archivos).
Brad Westness
Con respecto a la otra respuesta, puede marcar o + x en los directorios. Las personas podrán acceder a los directorios pero no podrán leer el contenido a menos que conozcan los nombres de los archivos. Estoy confundido en cuanto a por qué deberían ser capaces de leer los archivos ya, si no pueden cd al directorio.
dmah
También revise su syslog o / var / log / messages para cualquier información de depuración.
dmah