Un fichier veut appartenir à deux utilisateurs. Comment? La liaison dure échoue

Deux programmes setuid /usr/bin/baret /usr/bin/bazpartagent un seul fichier de configuration foo. Le mode du fichier de configuration est 0640, car il contient des informations sensibles. Les pistes de l' un programme en tant que bar:bar(qui est, en tant qu'utilisateur bar, groupe bar ); l'autre comme baz:baz. Changer les utilisateurs n'est pas une option, et même changer de groupe ne serait pas préférable.

Je souhaite lier en dur le fichier de configuration unique en tant que /etc/bar/fooet /etc/baz/foo. Cependant, cela échoue car le fichier doit, à ma connaissance, appartenir à root:barou à root:baz.

Solution potentielle: Créez un nouveau groupe barbazdont les membres sont baret baz. Laisser fooappartenir à root:barbaz.

Cela ressemble à une solution assez lourde pour moi. N'y a-t-il pas un moyen plus simple et plus simple de partager le fichier de configuration fooentre les deux programmes?

Pour le moment, je conserve deux copies identiques du fichier. Cela fonctionne, mais est évidemment faux. Quel serait le droit?

Pour information: j'ai peu d'expérience avec les groupes Unix et aucun avec setgid (2).

Vous pouvez utiliser des listes de contrôle d'accès pour que le fichier puisse être lu par les personnes des deux groupes.

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

Maintenant , les deux baret les bazgroupes peuvent lire le fichier.

Par exemple, voici un fichier appartenant à bin: bin avec le mode 640.

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

Les +moyens il y a un ensemble ACL, donc nous allons jeter un coup d' oeil.

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

Nous pouvons voir la ligne group:sweh:r--: cela signifie que les membres du groupe swehpeuvent la lire.

Hé, c'est moi!

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

Et oui, je peux lire le fichier.

$ cat foo
data

Vous voudrez peut-être reconsidérer ces affirmations:

Solution potentielle: Créez un nouveau groupe barbaz dont les membres sont baret baz. Laisser fooappartenir à root:barbaz.

Cela ressemble à une solution assez lourde pour moi. N'y a-t-il pas un moyen plus simple et plus simple de partager le fichier de configuration fooentre les deux programmes?

Pourquoi est-ce lourd de créer un nouveau groupe? Cela présente les avantages suivants par rapport aux ACL:

• Bien que vous ayez formulé ainsi une hypothétique avec des commandes /usr/bin/baret /usr/bin/baz, il est pertinent que ces deux programmes peuvent partager un fichier de configuration. Cela suggère que les programmes sont naturellement liés. Créer un nouveau groupe pour eux semblerait décrire une relation qui existe réellement et devrait déclencher un comportement (tel que les autorisations pour lire le fichier de configuration commun).
• La résolution de ce problème via des groupes est portable pour chaque Unix, ce qui signifie que vous pouvez compter sur le même mécanisme, fonctionnant exactement de la même manière, sur n’importe quel système Unix ou de type Unix. Les ACL sont beaucoup plus complexes et la portabilité peut être un problème.

Personnellement, je considère les ACL comme la solution à la main lourde ici, et les groupes comme la méthode Unix plus simple et traditionnelle.

Je penserais que ce serait une utilisation typique des listes de contrôle d'accès (ACL). Ajoutez les deux utilisateurs (ou groupes) à la liste de contrôle d'accès du fichier de configuration:

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

$ setfacl -m utilisateur: barre: rw- / etc / foo # Permet à la barre d’utilisateur de lire et d’écrire foo
$ setfacl -m utilisateur: baz: rw- / etc / foo # Permet également à l'utilisateur baz de lire et d'écrire foo

Vous devrez peut-être d'abord installer le paquet acl.

Rendre le mode du fichier 0660(ou même 0440si l'écriture n'est pas requise) et la propriété bar:baz. Ensuite, un processus peut accéder au fichier grâce aux autorisations de l’utilisateur, l’autre grâce aux autorisations du groupe. Cela fonctionne même sur les systèmes de fichiers où les ACL ne fonctionnent pas.

Je vais soumettre cela car ce n'est pas encore mentionné. Même si ce n'est probablement pas ce que vous voulez, cela peut être la réponse pour d'autres personnes ayant une question similaire.

La "nouvelle" "voie" consiste à faire en sorte que toute la configuration soit gérée par un système de gestion de la configuration (type chef , marionnette ou ansible ). Peu importe alors que vous avez deux fichiers distincts mais identiques sur le serveur, car les deux sont une copie du fichier unique à partir du système de gestion de la configuration.

Le principal avantage de procéder ainsi est que votre configuration est versionnée (avec le reste de vos configurations) et que le déploiement d'un nouveau serveur identique ou presque identique devient si facile qu'il est impossible de l'automatiser.

(Pour mémoire, puisque vous n'utilisez pas la gestion de la configuration, j'utiliserais le système de groupe comme dans la réponse de @ drg).