Por que o rm tem permissão para excluir um arquivo sob a propriedade de um usuário diferente?

Question

Da postagem Por que a rm remover arquivos somente leitura? Eu entendo que rm só precisa de permissão de gravação no diretório para remover o arquivo. Mas acho difícil digerir o comportamento em que podemos facilmente excluir um arquivo com proprietário e grupo diferentes.

Eu tentei o seguinte

mtk: meu nome de usuário
abc: criou um novo usuário

$ ls -l file
-rw-rw-r-- 1 mtk mtk       0 Aug 31 15:40 file
$ sudo chown abc file
$ sudo chgrp abc file
$ ls -l file
-rw-rw-r-- 1 abc abc       0 Aug 31 15:40 file
$ rm file
$ ls -l file
<deleted>

Eu estava pensando que isso não deveria ter sido permitido. Um usuário deve poder excluir apenas arquivos sob sua propriedade? Alguém pode esclarecer por que isso é permitido? e qual é o caminho para evitar isso? Eu posso pensar apenas restringir a permissão de gravação do diretório pai para desabilitar exclusões de arquivo surpresas.

    

Answer 1

O motivo pelo qual isso é permitido está relacionado ao que a remoção de um arquivo realmente faz. Conceitualmente, o trabalho de rm é remover uma entrada de nome de um diretório. O fato de que o arquivo pode, então, tornar-se inacessível se esse fosse o único nome do arquivo e que o inode e o espaço ocupado pelo arquivo pudessem, portanto, ser recuperados nesse ponto, é quase incidental. O nome da chamada do sistema que o comando rm chama, que é unlink , é mesmo sugestivo desse fato.

E, remover uma entrada de nome de um diretório é fundamentalmente uma operação nesse diretório , de modo que o diretório é o que você precisa ter permissão para escrever.

O seguinte cenário pode fazer com que se sinta mais confortável? Suponha que existam diretórios:

/home/me    # owned and writable only by me
/home/you   # owned and writable only by you

E há um arquivo que pertence a mim e tem dois links físicos:

/home/me/myfile
/home/you/myfile

Não importa como o hard link /home/you/myfile chegou lá em primeiro lugar. Talvez root tenha colocado lá.

A ideia deste exemplo é que você deve ter permissão para remover o link físico /home/you/myfile . Afinal, está atravancando o seu diretório. Você deve ser capaz de controlar o que existe e o que não existe dentro de /home/you . E quando você remover /home/you/myfile , observe que você não excluiu o arquivo. Você removeu apenas um link para ele.

Observe que, se o bit adesivo estiver definido no diretório que contém um arquivo (exibido como t in ls ), você faz precisará ser o proprietário do arquivo para para ser permitido excluí-lo (a menos que você possua o diretório). O bit pegajoso é normalmente definido em /tmp .

    

Answer 2

Para remover um arquivo, você só precisa gravar no diretório em que ele está.

Se você não gosta disso, você pode definir o bit "pegajoso" via chmod +t dir se você estiver em um SO mais antigo (este recurso foi introduzido por volta de 1986 no SunOS).

Se você gosta de ser mais fino, você precisa de um sistema de arquivos com uma implementação de ACL moderna como o ZFS. As ACLs NFSv4 padrão baseadas no NTFS incluem suporte para permissões de exclusão específicas do arquivo por usuário e uma permissão "delete_child" para diretórios.