Obligar al propietario a crear archivos y carpetas

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é el conjunto de carpetas "grupo adhesivo" chmod g+s. 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 preveo 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.

Asi que:

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

Espero que pueda navegar periódicamente por todo el directorio con un trabajo cron, pero eso me parece ineficaz para lo que es esencialmente un comando una vez pr-file.

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

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

¿Hay una manera 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 mejor manera de lo que estoy intentando, soy todo oídos.

Establecer un propietario predeterminado "automáticamente" requeriría un directorio que se setuidcomportara como setgid. Sin embargo, si bien esto se puede configurar en FreeBSD, otros sistemas UNIX y Linux simplemente ignoran u+s. Sin embargo, en su caso, puede 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 mejor manera de lo que estoy intentando, soy todo oídos.

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

• El grupo que controla el acceso al group_dirdirectorio es ourgroup.
• Solo las personas del ourgroupgrupo pueden acceder group_dir.
• user1y user2pertenecen a ourgroup.
• La umask 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. Cualquier persona del grupo puede crear, mover, eliminar archivos en cualquier lugar dentro group_dir(pero no más profundo).
• Cualquier persona que no esté adentro ourgroupserá bloqueada group_diry, por lo tanto, no podrá manipular nada debajo de ella. Por ejemplo, user3(que no es miembro de ourgroup), no puede leer group_dir/user2_submission/README(a pesar de que tiene r--permiso en el archivo).

Sin embargo, hay un pequeño problema en este caso: debido a la típica umask, los elementos creados por los usuarios no pueden ser manipulados por otros miembros del grupo. Aquí es donde entran las ACL. Al establecer 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:

• rw(x)Permisos predeterminados para el propietario.
• rw(x)Permisos predeterminados para el grupo.
• Sin permisos por defecto para los demás. Tenga en cuenta que, dado que los demás no pueden acceder de group_dirtodos modos, en realidad no importa cuáles son sus permisos debajo.

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 elemento es creado por su propietario.}

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

$ chmod +t group_dir/

Ahora, si user1intenta eliminar user2el directorio, obtendrá un encantador Operation not permitted. Sin embargo, tenga en cuenta que si bien esto evita modificaciones en la estructura del directorio group_dir, los archivos y directorios que se encuentran debajo todavía son accesibles:

user1@host $ rm -r user2_submission
Operation not permitted

user1@host $ cat /dev/null > 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 utilizamos configuran permisos predeterminados . Por lo tanto, es posible que el propietario de un elemento cambie los permisos asociados a él. Por ejemplo, user2puede funcionar 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 estaba dispuesto a dar rwsacceso completo a cualquier persona del grupo, supongo que confía en estos usuarios y que no esperaría demasiadas operaciones maliciosas de ellos.

Hay una forma más inteligente de hacer esto. Utiliza una combinación de set-gid y acls predeterminados . Obviamente, necesitará un sistema de archivos habilitado para acl. Supongamos que el directorio que desea compartir se encuentra /var/grpdiry que los miembros del grupo sharingdeberían poder acceder a él.

chown root:sharing /var/grpdir
chmod 2770 /var/grpdir #other can't read or traverse into the directory, set-gid is set
setfacl -d -m u::rwX,g::rwX,o::0 /var/grpdir

Las ACL predeterminadas son heredadas por subdirectorios creados en un directorio con ACL predeterminadas. Esto significa que cualquier archivo creado en /var/grpdirtendrá su grupo establecido sharingpor el bit setgid del directorio. Además, heredará las acls predeterminadas, que anularán las premisiones predeterminadas de estilo Linux, porque no especificamos ACL con usuarios o grupos específicos. Esto significa que todos los archivos se crearán con propiedad <user>:sharingy permisos rw-rw----. Los directorios serán los mismos, excepto que también tendrán sus propias ACL predeterminadas configuradas de la misma manera que sus padres ( /var/grpdir) y, por supuesto, tendrán los bits ejecutables establecidos para el usuario y el grupo. Si elimina a un usuario del sharinggrupo, no podrá acceder al directorio (ni a ningún archivo que contenga, incluso si lo posee).

A diferencia de la corrección periódica de permisos con un cronjob, los permisos siempre están sincronizados, ya que se actualizan atómicamente con los archivos y directorios recién creados. Esta solución es ligera; no se necesitan demonios, y no hay un pico para IO mientras se corrigen los permisos de una sola vez.

No conozco ninguna buena manera de hacer esto. La forma técnicamente más limpia sería un sistema de archivos FUSE que lo haga. Por supuesto, mucho trabajo si nadie lo ha hecho todavía.

Alternativas:

1. Usa samba. samba tiene el force userparámetro Puede exportar un directorio localmente y montarlo localmente. No hace que los accesos sean más rápidos, pero puede ser aceptable ya que solo se trata de redes de bucle invertido.

2. Use un sistema de archivos que no sea Linux como FAT32. Esto debe configurarse para que un determinado usuario lo monte. Los permisos de acceso deben ser manejados por el directorio padre.

No he oído hablar de ninguna forma de cambiar automáticamente la propiedad de un archivo, de modo que el propietario del archivo cambie cuando el archivo se mueva a un determinado directorio. Lo más parecido es lo pegajoso, pero parece que has indicado que la propiedad del grupo no es suficiente, la propiedad real del usuario tiene que cambiar.

En ese caso, creo que su mejor opción es el trabajo cron con el indicador chown -R, como mencionó Pandya. Póngalo en un cron para que se ejecute cada minuto o cada cinco minutos.

Si puede explicar cómo sus usuarios están usando esto, puede haber una mejor solución.

ACL puede ayudarlo a obtener un control de grano más fino sobre quién tiene permitido hacer qué, no cambiará automáticamente la propiedad real del archivo por usted. Creo que necesita obtener una vista más elevada y evaluar / rediseñar su solución sobre esa base.

Puede usar inotify-tools y escribir un script bash simple como el siguiente. Inotify mantendrá su ojo en el directorio web y hará algo cada vez que ocurra un evento como la creación de directorios dentro del directorio web. Hay muchos eventos existentes. Puede buscarlo en Google o puede haber buscado en este sitio

while inotifywait -m -e CREATE web; do echo "A new directory has been created"; done