Como os links físicos, os links simbólicos e as permissões da pasta ACL interagem?

Question

Este foi um pouco difícil de entender, mas me deparei com um comportamento muito estranho envolvendo permissões de arquivos estendidos da ACL e links hard / simbólicos. Farei o meu melhor para manter a minha pergunta curta e direta, mas primeiro tenho que mostrar um exemplo da minha situação atual, já que não sei o que está acontecendo ou como é chamado.

Suponha que tenhamos um sistema com dois usuários, vamos chamá-los de alice e bob , que até certo ponto compartilham uma pasta chamada stuff com as seguintes permissões:

bob@server:~$ getfacl /home/stuff getfacl: 
Removing leading '/' from absolute path names
# file: home/stuff
# owner: alice
# group: bob 
user::rwx
group::-wx
other::---
default:user::rwx
default:user:bob:rwx
default:group::-wx
default:mask::rwx
default:other::---

Como você pode ver, o dono da pasta é alice , mas o bob pode escrever coisas lá e torná-lo executável, para que alice possa ser executado em (+ x flag). No entanto, devido à ACL, sempre que Bob escreve / copia um arquivo em stuff , as permissões do arquivo são alteradas e acabam sendo as seguintes. Suponha que criamos um arquivo no diretório inicial de bob e mova-o para stuff .

bob@server:~$ touch myfile
bob@server:~$ chmod 777 myfile
bob@server:~$ ls -la myfile
-rwxrwxrwx 1 bob bob 0 myfile

bob@server:~$ mv myfile /home/stuff/myfile
bob@server:~$ ls -la /home/stuff/myfile
-rwxrwx---+ 1 bob bob 0 /home/stuff/myfile

Como você pode ver, embora myfile esteja na pasta stuff , alice não teria acesso a ela. Como o arquivo pertence a bob:bob , alice teria que acessá-lo com as permissões de arquivo "outros", que são --- de acordo com o último dos comandos ls acima. Ainda assim, como alice é o proprietário da pasta, ela pode excluí-los (embora eu receba um aviso sobre o myfile estar protegido).

Agora vem a parte divertida. Se, em vez de mover / copiar o myfile , eu criar um link físico para ele, observe o que acontece.

bob@server:~$ ln myfile /home/stuff/myfile
bob@server:~$ ls -la /home/stuff/myfile
-rwxrwxrwx 2 bob bob 0 /home/stuff/myfile

Aparentemente alice pode ler e usar. Na verdade, se testado no meu sistema e ela pode, de fato. Não obstante, um link simbólico parece não funcionar.

bob@server:~$ ln -s myfile /home/stuff/myfile
bob@server:~$ ls -la /home/stuff/myfile
lrwxrwxrwx 1 bob bob 4 /home/stuff/myfile -> /home/bob/myfile

Desta vez, embora o link também tenha todas as permissões definidas como lrwxrwxrwx (precisamente porque é um link e qualquer um tem que ser capaz de segui-lo para obter as permissões) alice não pode executá-lo, apenas excluí-lo.

Minhas perguntas:

• Por que posso "pular" as permissões do ACS com um link físico no primeiro lugar?
• E por que esse mesmo truque não funciona com links simbólicos?
• Isso é intencional ou é um furo de segurança?

Answer 1

Como alice tem permissão de gravação para o diretório stuff/ , o alice pode modificar seu conteúdo mesmo que ela não seja a proprietária dos arquivos.

Ao usar ACLs do Linux, quando o arquivo é criado (ou copiado, quando a cópia cria um novo arquivo no destino), as permissões são aplicadas conforme descrito por man acl . Movendo um arquivo com mv preserva as permissões quando o arquivo pode ser movido sem copiar . Parece que, por algum motivo, mv não pode mover o arquivo e faz uma cópia, pois as ACLs são aplicadas a myfile .

Criar um link físico é bem diferente. Criar um link físico cria uma entrada de diretório (no diretório de destino), que aponta para o mesmo inode como o arquivo original, em outras palavras, o mesmo arquivo existe em mais de um diretório. Permissões de arquivo, tanto ACLs quanto permissões tradicionais do UNIX, são armazenadas no inode. Como /home/stuff/myfile e /home/bob/myfile apontam para o mesmo inode, qualquer alteração em um ou outro refletirá para o outro. É por isso que alice pode acessar o link físico. As permissões de /home/bob/myfile (777) são as mesmas que as permissões de /home/stuff/myfile .

Os links simbólicos apontam para o caminho de destino. Acessar o arquivo para o qual o link simbólico está apontando requer as mesmas permissões que acessar o arquivo de destino. Possivelmente alice não tem acesso de pesquisa (executar bit) ao diretório pessoal de bob e, portanto, o acesso falha.