debian – Obligar al propietario a acceder a los archivos y carpetas creados

Pregunta:

Tengo un directorio que contiene datos compartidos entre varios usuarios. El acceso a este directorio y todo lo que se encuentre debajo será controlado por el grupo del directorio, que se agregará a los usuarios en cuestión. Como tal, creé la carpeta "sticky group" chmod g+s set. El directorio contendrá una estructura de árbol con directorios y archivos, y la cantidad total de archivos probablemente sea de unos pocos millones. Los archivos serán bastante pequeños, no anticipo nada más grande que 50 MB.

Mi problema es que el propietario del archivo o directorio sigue siendo el usuario que lo creó. Como tal, incluso si eliminara a ese usuario del grupo de acceso, no eliminaría su acceso por completo.

Entonces:

¿Hay otras opciones que me perdí para asegurarme de que todos los archivos y subdirectorios tengan el mismo propietario?

Espero poder navegar periódicamente a través de todo el directorio con un cron-job, pero eso me parece ineficiente para lo que es esencialmente un comando de un solo archivo.

Encontré un ejemplo usando INotify, pero me parece que requiere mucho mantenimiento, ya que requiere secuencias de comandos.

No he podido averiguar si ACL puede ayudarme con la propiedad forzada.

¿Existe una forma más inteligente de hacer esto?

Lo que quiero es tener un directorio que se pueda compartir agregando un grupo a un usuario. Todo lo creado en este directorio hereda el esquema de permisos de su padre. Si hay una forma mejor de la que estoy intentando, soy todo oídos.

Respuesta:

Establecer un propietario predeterminado "automáticamente" requeriría que un directorio setuid comporte como setgid . Sin embargo, aunque esto se puede configurar en FreeBSD, otros sistemas UNIX y Linux simplemente ignoran u+s . Sin embargo, en su caso, podría haber otra solución.

Lo que quiero es tener un directorio que se pueda compartir agregando un grupo a un usuario. Todo lo creado en este directorio hereda el esquema de permisos de su padre. Si hay una forma mejor de la que estoy intentando, soy todo oídos.

Entonces, básicamente, por lo que veo, desea controlar el acceso a un directorio usando el mecanismo de grupos. Sin embargo, esto no requiere que restrinja los permisos en toda la estructura del directorio. En realidad, el --x ejecución del directorio --x podría ser justo lo que necesita. Dejame darte un ejemplo. Asumiendo que…

  • El grupo que controla el acceso a la group_dir directorio es ourgroup .
  • Solo las personas del grupo ourgroup pueden acceder a group_dir .
  • user1 y user2 pertenecen a ourgroup .
  • La máscara de usuario predeterminada es 0022.

… considere la siguiente configuración:

drwxrws---    root:ourgroup   |- group_dir/
drwxr-sr-x    user1:ourgroup  |---- group_dir/user1_submission/
drwxr-sr-x    user2:ourgroup  |---- group_dir/user2_submission/
-rw-r--r--    user2:ourgroup  |-------- group_dir/user2_submission/README

Aquí, supongamos que cada elemento fue creado por su propietario.

Ahora, en esta configuración:

  • Todos los directorios pueden ser navegados libremente por todos en ourgroup . Cualquiera del grupo puede crear, mover o eliminar archivos en cualquier lugar dentro de group_dir (pero no más profundo).
  • Cualquiera que no ourgroup en ourgroup será bloqueado en group_dir y, por lo tanto, no podrá manipular nada debajo de él. Por ejemplo, user3 (que no es miembro de ourgroup ), no puede leer group_dir/user2_submission/README (aunque tiene r-- permiso en el archivo en sí).

Sin embargo, hay un pequeño problema en este caso: debido a la umask típica, los elementos creados por los usuarios no pueden ser manipulados por otros miembros del grupo. Aquí es donde entran las ACL. Al establecer los permisos predeterminados, se asegurará de que todo esté bien a pesar del valor de umask:

$ setfacl -dRm u::rwX,g::rwX,o::0 group_dir/

Esta llamada establece:

  • Permisos rw(x) predeterminados para el propietario.
  • Permisos rw(x) predeterminados para el grupo.
  • Sin permisos de forma predeterminada para los demás. Tenga en cuenta que, dado que los demás no pueden acceder a group_dir todos modos, realmente no importa cuáles sean sus permisos debajo de él.

Ahora, si creo un elemento como user2 :

$ touch group_dir/user2_submission/AUTHORS
$ ls -l group_dir/user2_submission/AUTHORS
rw-rw----    user2:ourgroup    group_dir/user2_submission/AUTHORS

Con esta ACL en su lugar, podemos intentar reconstruir nuestra estructura anterior:

drwxrws---+    root:ourgroup   |- group_dir/
drwxrws---+    user1:ourgroup  |---- group_dir/user1_submission/
drwxrws---+    user2:ourgroup  |---- group_dir/user2_submission/
-rw-rw----+    user2:ourgroup  |-------- group_dir/user2_submission/README

Aquí nuevamente, cada artículo es creado por su propietario.

Además, si desea dar un poco más de poder / seguridad a quienes usan el directorio, es posible que desee considerar un poco más pegajoso. Esto, por ejemplo, evitar que user1 de suprimir user2_submission (ya que tiene -w- permiso de group_dir ):

$ chmod +t group_dir/

Ahora, si user1 intenta eliminar el directorio de user2 , obtendrá una encantadora Operation not permitted . Sin embargo, group_dir en cuenta que, si bien esto evita modificaciones en la estructura de directorios en group_dir , los archivos y directorios que se encuentran debajo aún son accesibles:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ >     user2_submission/README
user1@host $ file  user2_submission/README
user2_submission/README: empty (uh-oh)

Otra cosa a tener en cuenta es que las ACL que usamos configuran permisos predeterminados . Por tanto, es posible que el propietario de un elemento cambie los permisos asociados a él. Por ejemplo, user2 puede ejecutar perfectamente …

$ chown g= user2_submission/ -R
or
$ chgrp nobody user2_submission -R

… por lo tanto, su directorio de envío completo no está disponible para nadie en el grupo.

Sin embargo, dado que originalmente está dispuesto a otorgar acceso completo a rws a cualquier persona del grupo, supongo que está confiando en estos usuarios y que no esperaría demasiadas operaciones maliciosas de ellos.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

web tasarım