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_dirdirectorio esourgroup. - Solo las personas del grupo
ourgrouppueden acceder agroup_dir. -
user1yuser2pertenecen aourgroup. - 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 degroup_dir(pero no más profundo). - Cualquiera que no
ourgroupenourgroupserá bloqueado engroup_diry, por lo tanto, no podrá manipular nada debajo de él. Por ejemplo,user3(que no es miembro deourgroup), no puede leergroup_dir/user2_submission/README(aunque tiener--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_dirtodos 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.