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
etbaz
. Laissezfoo
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:
/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). 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).