Um arquivo quer pertencer a dois usuários. Como? Ligação difícil falha

Question

Dois programas setuid, /usr/bin/bar e /usr/bin/baz , compartilham 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 (isto é, como usuário bar, grupo bar ); o outro como baz:baz . Alterar usuários não é uma opção, e nem mesmo a mudança de grupos seria preferível.

Gostaria de vincular rigidamente o arquivo de configuração único como /etc/bar/foo e /etc/baz/foo . No entanto, isso falha porque o arquivo deve, até onde eu sei, pertencer a root:bar ou a root:baz .

Solução potencial: crie um novo grupo barbaz cujos membros são bar e baz . Deixe foo pertencer a root:barbaz .

Parece uma solução bem pesada para mim. Não existe uma maneira mais simples e simples de compartilhar o arquivo de configuração foo entre 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: Eu tenho pouca experiência com grupos Unix e nenhum com setgid (2).

    

Answer 1

Você pode usar as ACLs para que o arquivo possa ser lido por pessoas em ambos os grupos.

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

Agora os grupos bar e baz podem ler o arquivo.

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

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

O + significa que há um conjunto de ACLs, 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-- : significa que as pessoas do grupo sweh podem lê-lo.

Olá, sou eu!

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

E sim, eu posso ler o arquivo.

$ cat foo
data

    

Answer 2

Você pode querer reconsiderar estas declarações:

Potential solution: Create a new group barbaz whose members are bar and baz. Let foo belong to root:barbaz.

That looks like a pretty heavy-handed solution to me. Is there no neater, simpler way to share the configuration file foo between the two programs?

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

• Embora você tenha formulado isso como uma hipotética com os comandos /usr/bin/bar e /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 acionar o comportamento (como permissões para ler o arquivo de configuração comum).
• Resolver este problema através de grupos é portável para todo Unix, o que significa que você pode confiar no mesmo mecanismo, trabalhando exatamente da mesma maneira, em qualquer sistema Unix ou Unix-like. 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 agrupam-se como a maneira mais simples e tradicional do Unix.

    

Answer 3

Eu acho que isso seria um uso típico para AccessControlLists (ACLs). Adicione ambos os 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  # Allows user bar to read and write foo
$ setfacl -m user:baz:rw- /etc/foo  # Allows also user baz to read and write foo

Você pode ter que instalar o pacote acl primeiro.

    

Answer 4

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

    

Answer 5

I'll submit this since it's not yet mentioned. Even though this is probably not what you want, it may be the answer for other people with a similar question.

A maneira "nova" da "nuvem" é ter toda a configuração tratada por um sistema de gerenciamento de configurações (como < href="https://www.chef.io/"> chef , fantoche ou ansible ). Não importa, portanto, que você tenha dois arquivos distintos, mas idênticos, no servidor, já que ambos são uma cópia do arquivo único do sistema de gerenciamento de configurações.

As principais vantagens de se fazer isso é que sua configuração é versionada (juntamente com todas as outras configurações ), e que a implementação de um novo servidor idêntico ou quase idêntico torna-se tão fácil que não pode ser automatizado.

(Para o registro, desde que você não está usando o gerenciamento de configuração, eu iria com o sistema de grupo como na resposta do @ drg).