Un file veut appartenir à deux users. Comment? La binding dure échoue

Deux programmes setuid, /usr/bin/bar et /usr/bin/baz , partagent un seul file de configuration foo . Le mode de file de configuration est 0640 , car il contient des informations sensibles. Le programme unique s'exécute sous forme de bar:bar (c'est-à-dire, barre user, barre de groupe); l'autre comme baz:baz . Changer d'user n'est pas une option, et même changer de groupe ne serait pas préférable.

Je souhaite relier durement le file de configuration unique sous /etc/bar/foo et /etc/baz/foo . Cependant, cela échoue parce que le file doit, pour autant que je sache, appartenir à root:bar ou à root:baz .

Solution potentielle: Créer un nouveau groupe barbaz dont les membres sont bar et baz . Laissez foo appartenir à root:barbaz .

Cela ressemble à une solution assez lourde pour moi. Existe-t-il un moyen plus simple et plus simple de partager le file de configuration foo entre les deux programmes?

Pour l'instant, je garde deux copys identiques du file. Cela fonctionne, mais est évidemment faux. Qu'est-ce qui serait juste?

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

Vous pouvez utiliser les lists de contrôle d'access pour que le file puisse être lu par les personnes des deux groupes.

 chgrp bar file chmod 640 file setfacl -mg:baz:r-- file 

Maintenant, les groupes bar et baz peuvent lire le file.

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

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

Le + signifie qu'il y a un jeu d'ACL, alors jetons un coup d'oeil dessus.

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

Nous pouvons voir le group:sweh:r-- lignes group:sweh:r-- : cela signifie que les personnes du groupe sweh peuvent le lire.

Hé, c'est moi!

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

Et oui, je peux lire le file.

 $ cat foo data 

Vous voudrez peut-être reconsidérer ces déclarations:

Solution potentielle: Créer un nouveau groupe barbaz dont les membres sont bar et baz . Laissez foo appartenir à root:barbaz .

Cela ressemble à une solution assez lourde pour moi. Existe-t-il un moyen plus simple et plus simple de partager le file de configuration foo entre les deux programmes?

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

  • Bien que vous ayez formulé ceci comme hypothétique avec les commands /usr/bin/bar et /usr/bin/baz , il est important que ces deux programmes puissent partager un file de configuration. Cela suggère que les programmes sont naturellement liés. La création d'un nouveau groupe pour eux semblerait décrire une relation qui existe réellement et devrait triggersr un comportement (comme les permissions pour lire le file de configuration commun).
  • Résoudre ce problème via des groupes est portable pour tous les Unix, ce qui signifie que vous pouvez countr sur le même mécanisme, fonctionnant exactement de la même manière, sur n'importe quel système Unix ou Unix. Les ACL sont beaucoup plus complexes et la portabilité peut être un problème.

Personnellement, je vois ACL comme la solution lourde main ici, et les groupes comme la façon plus simple et traditionnelle Unix.

Je pense que ce serait une utilisation typique pour les lists de contrôle d'access (ACL). Ajoutez les deux users (ou groupes) à la list de contrôle d'access du file de configuration:

 /etc/foo root:root rw------- # Traditional Unix ownership and permission for foo 
 $ setfacl -m user: bar: rw- / etc / foo # Permet à la barre user de lire et d'écrire foo
 $ setfacl -m user: baz: rw- / etc / foo # Permet aussi à l'user baz de lire et d'écrire foo

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

Rendre le mode 0660 du file (ou même 0440 si l'écriture n'est pas obligatoire) et la bar:baz propriété bar:baz . Ensuite, un process peut accéder au file grâce aux permissions de l'user, l'autre grâce aux permissions de groupe. Cela fonctionne même sur les filesystems où les lists de contrôle d'access ne le font pas.

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

Le «nouveau» «nuage» consiste à faire gérer toute la configuration par un système de gestion de configuration (tel que chef , marionnette ou ansible ). Il n'est donc pas important que vous ayez deux files distincts mais identiques sur le server, puisqu'il s'agit d'une copy du file unique du système de gestion de la configuration.

Les principaux avantages de le faire sont que votre configuration est versionnée (avec toutes les autres configurations) et que le deployment d'un nouveau server identique ou presque identique devient si simple qu'il peut être automatisé.

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