Comportamento de permissões de link físico diferente entre o CentOS 6 e o CentOS 7

7

Estou recebendo um erro de permissão no CentOS 7 quando tento criar um link físico. Com as mesmas permissões definidas no CentOS 6, não obtenho o erro. O problema é centralizado em permissões de grupo. Não tenho certeza de qual versão do sistema operacional está correta e qual está errada.

Deixe-me ilustrar o que está acontecendo. No meu diretório de trabalho atual, tenho dois diretórios: source e destination. No início, o destino está vazio; source contém um arquivo de texto.

[root@tc-dlx-nba cwd]# ls -l
total 0
drwxrwxrwx. 2 root root  6 Jun 12 14:33 destination
drwxrwxrwx. 2 root root 21 Jun 12 14:33 source
[root@tc-dlx-nba cwd]# ls -l destination/
total 0
[root@tc-dlx-nba cwd]# ls -l source/
total 4
-rw-r--r--. 1 root root 8 Jun 12 14:20 test.txt
[root@tc-dlx-nba cwd]# 

Como você pode ver, em relação às permissões, os dois diretórios são 777, com o proprietário e o grupo definidos como raiz. O proprietário e o grupo do arquivo de texto também estão definidos para raiz. No entanto, as permissões do arquivo de texto são de leitura / gravação para o proprietário, mas somente leitura para o grupo.

Quando estou logado como root, não tenho problema em criar um link físico no diretório de destino que aponta para o arquivo de texto (no diretório de origem).

[root@tc-dlx-nba cwd]# ln source/test.txt destination/
[root@tc-dlx-nba cwd]# ls destination/
test.txt

No entanto, se eu fizer login como outro usuário, neste caso, admin, não posso criar o link. Eu recebo: "Operação não permitida".

[root@tc-dlx-nba cwd]# rm -f destination/test.txt 
[root@tc-dlx-nba cwd]# su admin
bash-4.2$ pwd
/root/cwd
bash-4.2$ ln source/test.txt destination/
ln: failed to create hard link ‘destination/test.txt’ => ‘source/test.txt’: Operation not permitted

O que acontece realmente faz sentido para mim, mas desde que o acima é permitido no CentOS 6, eu queria verificar se eu estava entendendo mal alguma coisa. Para mim, parece um bug no CentOS 6 que foi corrigido no CentOS 7.

Alguém sabe o que dá? Estou certo acreditando que o comportamento acima é o comportamento correto? O CentOS 6 está correto? Ou ambos estão certos e talvez haja algum problema sutil de permissões de grupo que esteja faltando? Obrigado.

Edit: Eu tentei o mesmo teste agora mesmo em uma máquina virtual Debian v7 que eu tenho. Debian concorda com o CentOS 7: "Operação não permitida".

Editar # 2: Eu tentei a mesma coisa no Mac OS X (Yosemite). Isso funcionou da maneira que o CentOS 6 fez. Em outras palavras, permitia que o link fosse criado. (Nota: No OS X, o grupo raiz é chamado de "roda". Essa é a única diferença, até onde eu sei).

    
por Mario 12.06.2015 / 21:22

1 resposta

5

Eu desenvolvi alguns CentOS 6 e 7 vm e consegui recriar o comportamento exato que você mostrou. Depois de fazer algumas pesquisas, verifica-se que isso é, na verdade, uma mudança no kernel em relação ao comportamento padrão em relação a links físicos e soft para fins de segurança. As páginas seguintes apontaram-me na direção certa:

link

link

Se você tornar o mundo do arquivo gravável, seu usuário administrador poderá criar o link físico.

Para reverter o comportamento do sistema CentOS 6, novos parâmetros do kernel foram adicionados. Defina o seguinte em /etc/sysctl.conf:

fs.protected_hardlinks = 0
fs.protected_symlinks = 0

execute

sysctl -p

Por que seu programa opta por usar links em vez de copiar arquivos, por que criar uma cópia exata de um arquivo que você precisa usar quando você pode simplesmente criar uma entrada que aponte para os blocos originais? Isso economiza espaço em disco e a operação é menos dispendiosa em termos de CPU e E / S. O novo link físico é o mesmo arquivo, apenas com metadados / inode diferentes. Se você excluir o arquivo original depois de criar um link físico, ele não afetará o link. Um arquivo é "excluído" somente depois que todos os links forem removidos.

    
por 13.06.2015 / 18:49