Por que a rm tem permissão para excluir um arquivo pertencente a outro usuário?

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

Eu tentei o seguinte

mtk: my username
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 de sua propriedade? Alguém pode esclarecer por que isso é permitido? e qual é a maneira de evitar isso? Só posso pensar em restringir a permissão de gravação do diretório pai para desabilitar exclusões de arquivos surpresas.

A razão pela qual isso é permitido está relacionada ao que a remoção de um arquivo realmente faz. Conceitualmente, rmo trabalho é remover uma entrada de nome de um diretório. O fato de o arquivo ficar inacessível se esse for o único nome do arquivo e que o inode e o espaço ocupado pelo arquivo puderem ser recuperados nesse ponto é quase incidental. O nome da chamada do sistema que o rmcomando chama, ou seja unlink, é até sugestivo desse fato.

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

O cenário a seguir pode torná-lo mais confortável? Suponha que haja diretórios:

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

E há um arquivo que é de minha propriedade e que possui dois links físicos:

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

Não importa como esse link /home/you/myfiledireto chegou lá em primeiro lugar. Talvez rootcoloque lá.

A ideia deste exemplo é que você deve remover o link físico /home/you/myfile. Afinal, está bagunçando seu diretório. Você deve poder controlar o que existe e o que não existe lá dentro /home/you. E quando você remover /home/you/myfile, observe que você realmente não excluiu o arquivo. Você removeu apenas um link para ele.

Note que se o sticky bit é definido no diretório que contém um arquivo (mostra-se como tem ls), então você fazer necessidade de ser o proprietário do arquivo, a fim de ser autorizado a excluí-lo (a menos que você possui o diretório). A parte pegajosa geralmente está ativada /tmp.

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

Se você não gostar disso, poderá definir o bit "pegajoso" via chmod +t dirse estiver em um sistema operacional recente (esse recurso foi introduzido por volta de 1986 no SunOS).

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

A lógica é semelhante à de uma casa: o proprietário ou inquilino decide quais convidados serão expulsos, independentemente de quem é o proprietário. Além disso, o convidado despejado que é bem-vindo em outra casa (tem outro link no diretório de outra pessoa) não congelará até a morte lá fora.