Manter bit setgid (após a instalação do bower ou a compilação gulp)

Question

Nós executamos servidores da web nos quais temos a seguinte situação:

1. O usuário do www-data executa o servidor da web e deve ter acesso de leitura + gravação aos arquivos
2. O usuário de implante implanta todo o código
3. Os usuários bob e alice podem efetuar login via ssh e alterar configurações localmente

Todos os usuários devem ter acesso de leitura + gravação em / var / www / mysite. Atualmente, conseguimos isso possuindo o grupo de / var / www / site para www-data. Em seguida, definimos o bit write + setgid no grupo para garantir que todos os subdiretórios tenham os mesmos direitos.

Agora, tudo está funcionando bem por algum tempo, mas temos problemas com os seguintes cenários:

1. Usamos o bower para instalar pacotes com bower install . O usuário que executou bower install na primeira vez que possui o diretório public/bower_components e nenhum bit setgid está definido
2. Usamos o gulp para reduzir os javascripts de public/scripts/src para public/scripts/dist e o primeiro usuário que executou gulp build possui os arquivos

Em ambas as situações, um find path/to/dir -type d -exec chmod g+ws {} \; atenua o problema, mas é possível corrigir esse problema em primeiro lugar? Nós definimos o bit setgid no diretório /var/www/mysite , então por que bower install não segue esse conjunto de permissões?

Se não, existe uma maneira melhor de corrigir esse problema? Pensamos em definir os bits no processo de automação de implementação, mas se um usuário esquecer o bit de setgid, acreditamos que a implantação automatizada também poderia ficar presa.

    

Answer 1

As ACL Posix são a única maneira elegante de fazer isso, é assim que eu lido com conflitos de recursos compartilhados de leitura / gravação, particularmente em sistemas baseados na web. Aqui está um exemplo em execução.

No meu exemplo, tenho um diretório chamado /var/www/html/share . Além disso, tenho os usuários alice , bob , deploy e bower

Primeiro, criei um grupo chamado html e adicionei os usuários a esse grupo.

groupadd html
for i in alice bob deploy bower; do usermod -a -G html $user; done

Agora, adicionei um arquivo ACL contra esse grupo html nessa pasta.

setfacl -m g:html:rwx /var/www/html/share
setfacl -d -m g:html:rwx /var/www/html/share

O segundo comando é importante, faz com que a herança ocorra.

Agora, podemos testar o comportamento disso.

# for user in alice bob bower deploy; do \
    sudo -u $user touch "/var/www/html/share/file_${user}" \
done

[root@localhost html]# ls -l /var/www/html/share/
total 0
-rw-rw-r--+ 1 alice  alice  0 May 13 23:08 file_alice
-rw-rw-r--+ 1 bob    bob    0 May 13 23:08 file_bob
-rw-rw-r--+ 1 bower  bower  0 May 13 23:08 file_bower
-rw-rw-r--+ 1 deploy deploy 0 May 13 23:08 file_deploy
[root@localhost html]# 

À primeira vista, parece que as propriedades dos arquivos são simples e não permitem que um usuário interaja com outro. No entanto, podemos inspecionar o ACL usando getfacl , o que mostra mais informações.

# getfacl file_Al
getfacl: file_Al: No such file or directory
[root@localhost share]# getfacl file_alice 
# file: file_alice
# owner: alice
# group: alice
user::rw-
group::r-x          #effective:r--
group:html:rwx          #effective:rw-
mask::rw-
other::r--

Você pode ver que o grupo html tem controle sobre esses arquivos.

Observação: a permissão GROUP unix padrão indica a máscara contra as permissões. Como é rw para arquivos, também é efetivamente rw para a ACL, apesar da permissão real concedida ser rwx .

Permite que outros usuários possam modificar / excluir esses arquivos.

# sudo -u alice /bin/bash
[alice@localhost share]$ pwd
/var/www/html/share
[alice@localhost share]$ echo "hello world" >>file_alice
[alice@localhost share]$ echo "hello world" >>file_bob
[alice@localhost share]$ echo "hello world" >>file_deploy
[alice@localhost share]$ echo "hello world" >>file_bower
[alice@localhost share]$ ll
total 16
-rw-rw-r--+ 1 alice  alice  12 May 13 23:15 file_alice
-rw-rw-r--+ 1 bob    bob    12 May 13 23:15 file_bob
-rw-rw-r--+ 1 bower  bower  12 May 13 23:15 file_bower
-rw-rw-r--+ 1 deploy deploy 12 May 13 23:15 file_deploy
[alice@localhost share]$ rm file_deploy

Finalmente, o pouco complicado. O que acontece quando Alice cria um diretório?

[alice@localhost share]$ mkdir dir_alice;
[alice@localhost share]$ ls -l 
total 12
drwxrwxr-x+ 1 alice alice  0 May 13 23:16 dir_alice
-rw-rw-r--+ 1 alice alice 12 May 13 23:15 file_alice
-rw-rw-r--+ 1 bob   bob   12 May 13 23:15 file_bob
-rw-rw-r--+ 1 bower bower 12 May 13 23:15 file_bower
[alice@localhost share]$ getfacl dir_alice
# file: dir_alice
# owner: alice
# group: alice
user::rwx
group::r-x
group:html:rwx
mask::rwx
other::r-x
default:user::rwx
default:group::r-x
default:group:html:rwx
default:mask::rwx
default:other::r-x

Como passamos -d para setfacl , ele instrui os novos diretórios a também herdarem (e aplicar essa herança a outros subdiretórios). Então, agora como usuário deploy , podemos adicionar e editar arquivos existentes dentro desse novo subdiretório.

[alice@localhost share]$ touch dir_alice/file_indir_alice
[alice@localhost share]$ exit
exit
# sudo -u deploy /bin/bash
[deploy@localhost share]$ cd /var/www/html/share/dir_alice/
[deploy@localhost dir_alice]$ touch file_indir_deploy
[deploy@localhost dir_alice]$ rm file_indir_alice 
[deploy@localhost dir_alice]$ 

    

Answer 2

Você confundiu semântica de fixas e setgid.

O bit pegajoso em um diretório é usado quando vários usuários têm permissão para criar arquivos e diretórios nesse diretório, mas eles só podem alterá-los, eles criaram eles mesmos, eles não têm permissão para mexer com o conteúdo criado por outros usuários. O diretório /tmp é o caso de uso típico para isso.

O bit pegajoso não é herdado por subdiretórios. Não há necessidade de que ele seja herdado para satisfazer seu propósito pretendido. Os subdiretórios criados em um diretório fixo devem estar fora dos limites por padrão para todos, exceto o criador.

O bit setgid em um diretório indica que os arquivos e diretórios criados dentro desse diretório herdam o grupo do diretório, em vez de fazer com que o grupo atual do usuário o crie. O bit setgid é herdado pelos novos diretórios criados dentro do diretório setgid.

O bit setgid pode atingir parte do objetivo que você está tentando alcançar. Ele alcançaria a parte em que toda a hierarquia de diretórios e arquivos terá o mesmo grupo (a menos que seja explicitamente substituído).

No entanto, não garante que tudo será escrito pelo grupo. Isso pode ser conseguido através da configuração de umask.

O umask indica um conjunto de bits, que não devem ser definidos em arquivos e diretórios recém-criados. Valores típicos para umask são 0002 , 0007 , 0022 , 0027 , 0077 . No seu caso, você quer que esses diretórios sejam graváveis para o grupo, o que significa que você quer 0002 , o que significa que será criado para todos fora do grupo ou 0007 , o que significa que é inacessível para todos fora do grupo grupo.

Você precisa garantir que o umask esteja configurado em algum momento antes de criar novos arquivos ou diretórios. O umask é herdado por processos filhos. Cuidado com os arquivos criados fora desse diretório específico, já que o umask é aplicado em outro lugar também, então qualquer coisa criada em outro lugar ainda será gravável pelo grupo, mesmo que seja um grupo diferente do que é usado na hierarquia /var/www . p>     

Answer 3

Você pode tentar tornar mais difícil redefinir as permissões do diretório raiz, tornando-o apenas anexado com chattr :

chattr +a /var/www/mysite