Evitar que os usuários alterem o grupo de seus próprios arquivos

Question

Estou escrevendo um conjunto de scripts para provisionar servidores de jogos.

Eu tenho cada servidor de jogo sendo instalado como um usuário separado, para que eles fiquem isolados e não possam acessar os arquivos uns dos outros.

O daemon / servidor que lida com o provisionamento é executado como um usuário sem privilégios, com permissão sudo para criar usuários.

Agora estou desenvolvendo um recurso que exige que o daemon edite arquivos em nome dos usuários após os servidores serem provisionados.

Eu estava pensando em adicionar o daemon a um grupo como "admin", configurando o grupo em todos os arquivos de usuários como "admin" com permissões de grupo para que o daemon pudesse ler e gravar seus arquivos o grupo "admin" para que eles não possam ler os arquivos uns dos outros.

Isso funciona na primeira instalação, e eu posso definir o bit setgid para garantir que novos arquivos e pastas herdem o grupo "admin". No entanto, é possível para os usuários "chgrp" para o seu próprio grupo, o que quebra este sistema. O daemon não pode mais acessar os arquivos, e até mesmo os usuários não podem reverter o grupo de volta para "admin" porque eles não pertencem a esse grupo.

Existe uma maneira:

1. Para evitar que os usuários do servidor de jogos alterem o grupo de seus arquivos para algo diferente de "admin", os itens acima funcionarão; ou
2. Existe uma maneira melhor de alcançar o que estou tentando alcançar aqui?

Answer 1

O acesso à propriedade inclui o acesso para definir o ID do grupo, os bits de permissões e as ACLs; Portanto, não há nada que você possa fazer para impedir que os proprietários de um arquivo definam essas coisas.

Naturalmente, oculto nessa frase está a semente de duas abordagens diferentes:

1. Não conceda acesso de propriedade em primeiro lugar. Não torne as contas de usuário os proprietários dos arquivos. Em vez disso, use setfacl para conceder às contas de usuário individuais rwx (ou qualquer outro) acesso em uma ACL. Faça-os pertencer a alguma outra conta, designada a um grupo de que as contas não fazem parte e que não sejam acessíveis ao mundo. As desvantagens aqui são coisas como cotas de disco.
2. Use uma forma de controle de acesso que o proprietário possa ativar novamente. Torne as contas de usuários individuais os proprietários, mas use setfacl para conceder acesso à conta do daemon rw- (ou qualquer outra) em uma ACL. A desvantagem aqui é que as contas de usuário podem desativar o acesso em primeiro lugar.

Avalie os trade-offs de acordo com a necessidade. Use as ACLs padrão no diretório pai se quiser definir automaticamente essas ACLs em todos os arquivos criados.

Leitura adicional

• Dá acesso de usuário à pasta sem alterar a propriedade?