Cómo otorgar permisos para leer, escribir y no eliminar el archivo


12

Quiero darles a los usuarios la capacidad de crear archivos de escritura y lectura en otro directorio de usuarios, pero no tener la opción de eliminar el archivo después de creado (un bit no funcionará aquí ...) por ejemplo:

Tengo un usuario manager con un directorio en el repository
que tengo un usuario worker1que necesita escribir archivos /manager/repositorypero no puedo eliminar los archivos.
Tengo un usuario en el worker2que necesito escribir archivos /manager/repository pero no puedo eliminar los archivos en los
que tengo un usuario worker3que necesita escribir archivos /manager/repository pero no puedo eliminar los archivos

pero worker 1-2-3no puede eliminar los archivos solo después de crearlos managery rootpuede eliminar los archivos worker 1-2-3creados.

Intenté algunos chowny chmodtrucos con la aplicación de la parte adhesiva sin éxito.


1
¿Los worker*usuarios escriben en el directorio de cierta manera? Usted mencionó en un comentario que los archivos de registro van aquí, entonces, ¿eso significa que se inicia un determinado ejecutable para crear archivos aquí? Si es así, puede dar permiso al workergrupo sudopara ejecutar el ejecutable como manager. Luego, el ejecutable crearía registros como el managerusuario que los trabajadores podrían leer.
Centimane

Si el usuario puede modificar el archivo, también puede borrar su contenido, "borrándolo" efectivamente. Parece que necesita algún tipo de interfaz de "envío", no sistemas de archivos. Los correos electrónicos serían los más simples.
ybungalobill

Respuestas:


8

A diferencia de Windows, no hay un permiso de eliminación distinto en Unix / Linux. El derecho a eliminar (o crear o renombrar) un archivo está vinculado al directorio que lo contiene. Elimine el permiso de escritura para los trabajadores /manager/repository/para negarles a los trabajadores la creación, eliminación y cambio de nombre de archivos.

Tenga en cuenta que no es posible permitir la creación de archivos sino negar su eliminación.


¿cómo se puede retirar el permiso de escritura que el archivo será writen todo el tiempo que es archivo de registro
user63898

. Mientras que solía ser cierto, muchos sistemas modernos soportan ACL extendidas (NFSv4 ACL como el apoyo de FreeBSD, Solaris o Linux (parche Richacl) que dan capacidades similares como Windows NT ACL es su stock distribución de Linux es probable que no tenga que aunque.
Stéphane Chazelas

@ user63898 elimina los permisos de escritura del directorio en el que se encuentra el archivo, no del archivo en sí.
GnP

6

En primer lugar, asegúrese de que ACL esté habilitado en su sistema, luego ejecute este comando

setfacl -d -R -m user::rwx,user:worker1:---,user:worker2:---,user:worker3:--- \
/manager/repository

Cómo funciona

  • Este comando le dará permisos de lectura, escritura y ejecución para el propietario en el directorio /manager/repository. Revocará todos los permisos para worker1, worker2y worker3.

  • Esto le dará a otros usuarios acceso de lectura y escritura, pero negará el acceso de eliminación.


De man setfacl:

-d, --default
       All  operations  apply to the Default ACL.

-R, --recursive
       Apply operations to all files and directories recursively.

-m, --modify
       Options to modify the ACL of a file or directory.

gracias, pero el problema es que los usuarios se crean todo el tiempo. y algunos son eliminados por el administrador. entonces eso significa que necesito actualizar cada vez el directorio con setfacl? ¿Hay alguna solución más genérica?
user63898

Sí, cuando trato de crear un archivo desde trabajador1, toque /manager/repository/x.txt obtengo: touch: no puedo tocar `/manager/repository/x.txt ': Permiso denegado
usuario63898

sigo obteniendo Permiso denegado cuando hago el repositorio ls -ld estoy obteniendo: drwxrwxr-t 2 usuarios administradores 4096 7 de septiembre 11:30 repositorio /
user63898

al hacer setfacl -d -R -m usuario :: rwx, usuario: trabajador1: --- repositorio / y luego intentar crear un archivo desde trabajador1 toque /manager/repository/x.txt estoy obteniendo: toque: no puede tocar `/ manager /repository/x.txt ': Permiso denegado
user63898

55
¿Esto no permitiría que alguien escriba un archivo vacío aquí? Me gusta echo " " > $filegolpearía el contenido del archivo con "", que técnicamente es una escritura, pero elimina efectivamente el contenido. Parece que un repositorio real como svn sería la mejor apuesta aquí.
Centimane

3

Para hacer eso con permisos, necesitaría un sistema con soporte para ACL similares a las ACL de NFSv4. Por ejemplo, en FreeBSD, si el sistema de archivos está montado con la nfsv4aclsbandera, puede hacer lo siguiente:

mkdir testdir
chown manager:worker-group testdir
chmod 775 testdir
setfacl -m group@:D::deny testdir

Para explícitamente negar el delete_childpermiso a los miembros del worker-groupgrupo.

Sin embargo, tenga en cuenta que, dado que los trabajadores serían propietarios de los archivos que crean, aún podrían modificar las ACL en ellos, y al concederse el deletepermiso, eso prevalecería sobre el delete_childpermiso del directorio principal y no estoy Seguro que hay una forma de evitarlo (al menos en los sistemas de archivos UFS en FreeBSD). Por ejemplo, podrían hacer:

$ touch file
$ rm -f file
rm: file: Operation not permitted
$ setfacl -m owner@:d::allow file
$ rm -f file
$

0

Para tomar permisos de escritura de la /manager/repositorycarpeta. Por lo tanto, todos los usuarios que no sean root podrán escribir o eliminar de los archivos internos /manager/repository, pero no eliminar ningún archivo de este directorio.

chmod 755 /manager/repository

0

podemos modificar los archivos y carpetas pero no podemos eliminarlos.

Para eliminar los atributos, ejecute los siguientes comandos:

Para archivos:

$ sudo chattr -R -a file.txt

Para directorios:

$ sudo chattr -R -a dir1/

(1) Según la documentación, el aatributo significa solo anexar. ¿Pueden los usuarios editar estos archivos? (2) ¿Cuál es el efecto de establecer el aatributo en un directorio?
Scott,
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.