Um arquivo deseja pertencer a dois usuários. Quão? Falha na vinculação física

Dois programas setuid /usr/bin/bare /usr/bin/bazcompartilham um único arquivo de configuração foo. O modo do arquivo de configuração é 0640, pois contém informações confidenciais. O único programa é executado como bar:bar(ou seja, como barra de usuário , barra de grupo ); o outro como baz:baz. Alterar usuários não é uma opção, e mesmo alterar grupos não seria preferível.

Desejo vincular o arquivo de configuração único como /etc/bar/fooe /etc/baz/foo. No entanto, isso falha porque o arquivo deve, tanto quanto eu saiba, pertencer a root:barou a root:baz.

Solução potencial: crie um novo grupo barbazcujos membros sejam bare baz. Deixe foopertencer a root:barbaz.

Isso me parece uma solução bastante pesada. Não existe uma maneira mais simples e simples de compartilhar o arquivo de configuração fooentre os dois programas?

Por enquanto, estou mantendo duas cópias idênticas do arquivo. Isso funciona, mas está obviamente errado. O que seria certo?

Para informações: Tenho pouca experiência com grupos Unix e nenhuma com setgid (2).

Você pode usar ACLs para que o arquivo possa ser lido por pessoas nos dois grupos.

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

Agora, ambos bare bazgrupos podem ler o arquivo.

Por exemplo, aqui está um arquivo de propriedade de bin: bin com o modo 640.

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

O +meio é que existe um conjunto de ACL, então vamos dar uma olhada nele.

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

Podemos ver a linha group:sweh:r--: isso significa que as pessoas do grupo swehpodem lê-la.

Ei, sou eu!

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

E sim, eu posso ler o arquivo.

$ cat foo
data

Você pode reconsiderar estas declarações:

Solução potencial: Crie um novo grupo barbaz cujos membros sejam bare baz. Deixe foopertencer a root:barbaz.

Isso me parece uma solução bastante pesada. Não existe uma maneira mais simples e simples de compartilhar o arquivo de configuração fooentre os dois programas?

Por que é difícil criar um novo grupo? Fazer isso tem as seguintes vantagens sobre as ACLs:

• Embora você tenha formulado isso como uma hipótese com comandos /usr/bin/bare /usr/bin/baz, é relevante que esses dois programas possam compartilhar um arquivo de configuração. Isso sugere que os programas estão naturalmente relacionados. Criar um novo grupo para eles parece descrever um relacionamento que realmente existe e deve desencadear um comportamento (como permissões para ler o arquivo de configuração comum).
• Resolver esse problema por meio de grupos é portátil para todo Unix, o que significa que você pode confiar no mesmo mecanismo, funcionando exatamente da mesma maneira, em qualquer sistema Unix ou semelhante ao Unix. As ACLs são muito mais complexas e a portabilidade pode ser um problema.

Pessoalmente, vejo as ACLs como a solução mais pesada aqui e os grupos como a maneira mais simples e tradicional do Unix.

Eu acho que esse seria um uso típico para as Listas de Controle de Acesso (ACLs). Adicione os dois usuários (ou grupos) à ACL do arquivo de configuração:

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

$ setfacl -m user: bar: rw- / etc / foo # Permite que a barra de usuários leia e escreva foo
$ setfacl -m user: baz: rw- / etc / foo # Permite também que o usuário baz leia e escreva foo

Você pode ter que instalar o pacote acl primeiro.

Crie o modo do arquivo 0660(ou mesmo 0440se a gravação não for necessária) e a propriedade bar:baz. Em seguida, um processo pode acessar o arquivo graças às permissões do usuário, o outro graças às permissões do grupo. Isso funciona mesmo em sistemas de arquivos onde as ACLs não.

Vou enviar isso, pois ainda não foi mencionado. Mesmo que isso provavelmente não seja o que você deseja, pode ser a resposta para outras pessoas com uma pergunta semelhante.

A maneira "nova" "nuvem" é ter todas as configurações tratadas por um sistema de gerenciamento de configurações (como chef , fantoche ou ansible ). Não importa, então, que você tenha dois arquivos distintos, mas idênticos, no servidor, pois ambos são uma cópia do arquivo único do sistema de gerenciamento de configuração.

As principais vantagens de fazer isso dessa maneira é que sua configuração é versionada (juntamente com todo o restante) e que a implantação de um novo servidor idêntico ou quase idêntico se torna tão fácil que a ot pode ser automatizada.

(Para constar, como você não está usando o gerenciamento de configuração, eu usaria o sistema de grupo como na resposta de @ drg).