Un archivo quiere pertenecer a dos usuarios. ¿Cómo? El enlace duro falla

Dos programas setuid /usr/bin/bary /usr/bin/bazcomparten un solo archivo de configuración foo. El modo del archivo de configuración es 0640, ya que contiene información confidencial. El único programa se ejecuta como bar:bar(es decir, como barra de usuario , barra de grupo ); el otro como baz:baz. Cambiar usuarios no es una opción, e incluso cambiar grupos no sería preferible.

Deseo vincular el archivo de configuración individual como /etc/bar/fooy /etc/baz/foo. Sin embargo, esto falla porque el archivo debe, hasta donde yo sé, pertenecer ao root:bara root:baz.

Posible solución: crear un nuevo grupo barbazcuyos miembros sean bary baz. Dejar foopertenecer a root:barbaz.

Eso parece una solución bastante dura para mí. ¿No hay una forma más ordenada y sencilla de compartir el archivo de configuración fooentre los dos programas?

Por ahora, mantengo dos copias idénticas del archivo. Esto funciona, pero obviamente está mal. ¿Qué sería lo correcto?

Para información: tengo poca experiencia con grupos Unix y ninguno con setgid (2).

Puede usar ACL para que las personas de ambos grupos puedan leer el archivo.

chgrp bar file
chmod 640 file
setfacl -m g:baz:r-- file

Ahora ambos bary bazgrupos pueden leer el archivo.

Por ejemplo, aquí hay un archivo propiedad de bin: bin con modo 640.

$ ls -l foo
-rw-r-----+ 1 bin bin 5 Aug 17 12:19 foo

Los +medios que hay un conjunto de ACL, así que vamos a echar un vistazo a él.

$ getfacl foo
# file: foo
# owner: bin
# group: bin
user::rw-
group::r--
group:sweh:r--
mask::r--
other::---

Podemos ver la línea group:sweh:r--: eso significa que las personas del grupo swehpueden leerla.

¡Hola, soy yo!

$ id
uid=500(sweh) gid=500(sweh) groups=500(sweh)

Y sí, puedo leer el archivo.

$ cat foo
data

Es posible que desee reconsiderar estas declaraciones:

Posible solución: crear un nuevo grupo de barbaz cuyos miembros sean bary baz. Dejar foopertenecer a root:barbaz.

Eso parece una solución bastante dura para mí. ¿No hay una forma más ordenada y sencilla de compartir el archivo de configuración fooentre los dos programas?

¿Por qué es difícil crear un nuevo grupo? Hacerlo tiene las siguientes ventajas sobre las ACL:

• Aunque lo ha expresado como una hipótesis con comandos /usr/bin/bary /usr/bin/bazes relevante que estos dos programas puedan compartir un archivo de configuración. Esto sugiere que los programas están naturalmente relacionados. La creación de un nuevo grupo para ellos parecería describir una relación que realmente existe y debería desencadenar un comportamiento (como permisos para leer el archivo de configuración común).
• Resolver este problema a través de grupos es portátil para todos los Unix, lo que significa que puede confiar en el mismo mecanismo, que funciona exactamente de la misma manera, en cualquier sistema Unix o similar a Unix. Las ACL son mucho más complejas y la portabilidad puede ser un problema.

Personalmente, veo las ACL como la solución de mano dura aquí, y los grupos como la forma más simple y tradicional de Unix.

Creo que este sería un uso típico para las listas de control de acceso (ACL). Agregue ambos usuarios (o grupos) a la ACL del archivo de configuración:

/etc/foo  root:root rw-------  # Traditional Unix ownership and permission for foo

$ setfacl -m user: bar: rw- / etc / foo # Permite que la barra de usuario lea y escriba foo
$ setfacl -m usuario: baz: rw- / etc / foo # Permite también al usuario baz leer y escribir foo

Es posible que primero deba instalar el paquete acl.

Establezca el modo del archivo 0660(o incluso 0440si no se requiere escritura) y la propiedad bar:baz. Entonces, un proceso puede acceder al archivo gracias a los permisos del usuario, el otro gracias a los permisos de grupo. Esto funciona incluso en sistemas de archivos donde las ACL no lo hacen.

Enviaré esto ya que aún no se menciona. Aunque probablemente esto no sea lo que desea, puede ser la respuesta para otras personas con una pregunta similar.

La forma "nueva" "en la nube" es tener toda la configuración manejada por un sistema de gestión de configuración (como chef , puppet o ansible ). Entonces no importa que tenga dos archivos distintos pero idénticos en el servidor, ya que ambos son una copia del archivo único del sistema de gestión de la configuración.

Las principales ventajas de hacerlo así es que su configuración está versionada (junto con el resto de sus configuraciones), y que la implementación de un nuevo servidor idéntico o casi idéntico se vuelve tan fácil que puede automatizarse.

(Para el registro, ya que no está utilizando la gestión de configuración, iría con el sistema de grupo como en la respuesta de @ drg).