Usando setfacl para permitir que los miembros del grupo escriban en cualquier archivo en un directorio

Me gustaría usar setfacl para que cualquier persona en el grupo 'aplicación' pueda editar cualquier archivo contenido en / usr / local / users / app independientemente de lo que digan los permisos tradicionales de UNIX. Tengo dos usuarios, John y Ben. Traté de seguir las instrucciones de otra pregunta , pero John no puede escribir en algunos archivos. Parece que esto se debe a la máscara acl. Sin embargo, he configurado la máscara predeterminada en el directorio de rwx, entonces ¿no deberían los archivos dentro de ella heredar eso cuando se crean?

Por ejemplo, John no puede escribir en el archivo a continuación, pero es miembro de la 'aplicación' del grupo que ha escrito acls en el archivo, así que me sorprende que no pueda editar el archivo.

ben@app1:/usr/local/users$ ls -la app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar 
-rw-r--r--+ 1 ben users 38326 Apr  2 10:21 app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar

ben@app1:/usr/local/users/app$ getfacl app-1.0-SNAPSHOT/lib/
# file: app-1.0-SNAPSHOT/lib/
# owner: ben
# group: users
user::rwx
group::rwx          #effective:r-x
group:app:rwx       #effective:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::rwx
default:group:app:rwx
default:mask::rwx
default:other::r-x

ben@app1:/usr/local/users$ getfacl app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar 
# file: app/app-1.0-SNAPSHOT/lib/play.templates_2.10-2.1.1.jar
# owner: ben
# group: users
user::rw-
group::rwx          #effective:r--
group:app:rwx       #effective:r--
mask::r--
other::r--

permissions acl

— Ben McCann
fuente

Respuestas:

Notarás el comentario "efectivo" que getfacl te está lanzando. El problema es que los permisos se calculan para que la "aplicación" no obtenga el conjunto de bits de escritura. Eso sucede porque la máscara en el archivo está configurada en solo lectura. La máscara se usa para limitar la cantidad de permisos que podrían otorgarse a un archivo o directorio en particular.

Un ejemplo de por qué querría este comportamiento sería como si supiera que el archivo podría legítimamente necesitar que diferentes usuarios / grupos tengan acceso a él, pero por alguna razón las cosas se complicaron con los permisos y deseaba una forma de decir "Lo que sea el otro los permisos predeterminados se establecen en, sean cuales sean los miembros de su grupo, o cualquier conjunto recursivo que se ejecute más tarde, ¡ DEFINITIVAMENTE NO DARÁ ESTO ! " El usuario propietario tiene un estado especial en el mundo POSIX, tiene derechos que otros usuarios no tienen, como la capacidad de no ser root y cambiar los permisos en un archivo y que sus derechos no estén limitados por la máscara (que sería de todos modos no tiene sentido debido al primer privilegio que el sistema les da). Es por eso que todavía obtienen rwx a pesar de que la máscara está restringida.

Sin embargo, para responder a su pregunta específica : agregue el bit de escritura a la máscara en el archivo e intente nuevamente como johnusuario.

Aquí hay una versión de línea de comandos de la explicación anterior, tome nota de cómo cambian los derechos "efectivos" cuando todo lo que modifico es la máscara.

— Bratchley
fuente

Gracias. Realmente aprecio la respuesta. ¿Es posible que se creen nuevos archivos con una máscara predeterminada de rwx? He editado mi pregunta con algunos detalles más.

— Ben McCann

Sí, la máscara es una de las categorías (como usuarios y grupos) en la que puede establecer una ACL predeterminada. La máscara predeterminada debe heredar a los subdirectorios y aplicarse a los archivos. EJEMPLO: setfacl -md: m :: rwx / path / to / Dir

— Bratchley

La ACL predeterminada hereda los subdirectorios, pero no los archivos, lo que hace que las ACL sean completamente inútiles :-(

— Ben McCann

Solo para asegurarnos de que estamos hablando de lo mismo, ¿estás hablando de la acl predeterminada para la entrada de máscara? Esto es lo que obtengo en las pruebas.

— Bratchley

También repetí la prueba anterior para archivos nuevos en / testBed después de cambiar la máscara efectiva en el directorio principal y obtuve el mismo resultado (la entrada de máscara predeterminada se aplica al archivo y no a la máscara efectiva principal).

— Bratchley

Es imposible. cp, rsync, etc. crea archivos ignorando las ACL predeterminadas

¿Por qué cp no respeta las ACL?

— Ben McCann
fuente

incorrecto El usuario se estaba encontrando con la misma máscara con la que se encontraba anteriormente y recibió una respuesta incorrecta de otra persona. No depende de "cp" ni de ninguna otra utilidad ignorar las entradas de ACL predeterminadas, eso ocurre en el nivel del sistema de archivos cuando cp va a crear el archivo. La herramienta tiene la opción de emitir las llamadas del sistema para eliminar / agregar las ACL necesarias, pero tendría que hacer un esfuerzo para hacerlo.

— Bratchley

Lo peor de todo es que puedes ver la entrada de ACL de la que hablan, solo que los permisos efectivos que esperan ver no están allí. Esa fue una oportunidad perfecta para decir "hola amigo, revisa tu máscara".

— Bratchley

En realidad, lo retiro, parece que EvilRyry publicó sobre la máscara y el OP simplemente respondió con "no funcionó" y luego publicó una salida getfacl que parece mostrar que "felles" consiguió rwx en el archivo. A este ritmo, la respuesta más votada no coincide con mi experiencia personal y lo que he ilustrado aquí con ejemplos de comandos.

— Bratchley