Os subdiretórios não vazios de outro usuário estão protegidos contra exclusão no meu diretório?

Só é possível remover um diretório (com a rmdir()chamada do sistema) se estiver vazio.

rm -r dirremove o diretório e todos os arquivos contidos nele, começando pelas folhas da árvore de diretórios e subindo até a raiz ( dir).

Para remover um arquivo (com rmdir()para diretórios e unlink()para outros tipos de arquivos, ou *at()variantes), o que importa não é a permissão do arquivo em si, mas as do diretório do qual você está removendo o arquivo (cuidado com o tbit nas permissões, como para /tmp, acrescenta mais complicações a isso).

Antes de tudo, você não está realmente removendo o arquivo , você está desvinculando-o de um diretório (e quando for o último link que você está removendo, o arquivo acaba sendo deletado por consequência), ou seja, você está modificando o diretório, então você precisa modificar (escrever) permissões para esse diretório.

O motivo pelo qual você não pode remover non-empty-diré que não pode desvincular subdirprimeiro, pois não tem o direito de modificar non-empty-dir. Você teria o direito de desvincular non-empty-dirde seu diretório pessoal, pois tem permissão de gravação/modificação para aquele, apenas você não pode remover um diretório que não esteja vazio.

No seu caso, conforme observado por @PeterCordes nos comentários, a rmdir()chamada do sistema falha com um ENOTEMPTYcódigo de erro (Diretório não vazio), mas como você não tem permissão de leitura para o diretório, rmnão consegue nem descobrir quais arquivos e diretórios (incluindo subdir) ele precisaria se desvincular dele para poder esvaziá-lo (não que pudesse desvinculá-los se soubesse, pois não tem permissões de gravação).

Você também pode entrar em situações em que rm poderia remover um diretório se pudesse descobrir quais arquivos estão nele, como no caso de um diretório somente para gravação:

$ mkdir dir
$ touch dir/file
$ chmod a=,u=wx dir
$ ls -ld dir
d-wx------ 2 me me 4096 Nov 30 19:43 dir/
$ rm -rf dir
rm: cannot remove 'dir': Permission denied

Ainda assim, posso removê-lo, pois sei que ele contém apenas um filearquivo:

$ rm dir/file
$ rmdir dir
$

Observe também que com Unices modernos você pode renomear isso non-empty-dir, mas em alguns como Linux ou FreeBSD (mas não Solaris), não movê-lo para um diretório diferente, mesmo se você também tivesse permissão de gravação para esse diretório, como (eu acho que e para Linux , conforme sugerido pelo comentário para o código relevante ) isso envolveria modificação non-empty-dir(a ..entrada nele apontaria para um diretório diferente).

Pode-se argumentar que remover your empty-dirtambém envolve remover as entradas ..e .nele, portanto, modificá-lo, mas ainda assim, o sistema permite que você faça isso.

Ignorando a possível alteração por meio das ACLs, posso confirmar esse comportamento para meu sistema (sem ACLs).

O comportamento observado é a consequência lógica de dois princípios:

1) Os direitos de um diretório determinam quem pode alterar o diretório, ou seja, excluir entradas no diretório. Os direitos das entradas nesse diretório não desempenham nenhum papel nisso.

2) A remoção de um arquivo requer potencialmente a remoção e limpeza das informações associadas, ou seja, inodes, listas de alocação de blocos etc. tornar-se inacessível, mas as informações associadas não teriam sido limpas.

Portanto, você pode remover empty-subdir, porque tem o direito de gravar no diretório em que ele está. Você não pode remover non-empty-subdir, porque não tem o direito de limpar primeiro os arquivos contidos neste subdiretório.

Não há realmente nenhuma razão ou caso de uso para isso. Alguém poderia ter construído uma limpeza recursiva de um subdiretório no kernel, mas o Unix original manteve tudo simples, e a limpeza recursiva teria sido muito complicada quando pode ser realizada com um utilitário de espaço de usuário.

Não posso fornecer uma visão geral abrangente entre os diferentes tipos, mas esse era o comportamento no Unix original e esperaria que fosse o mesmo em todos os tipos de Unix, e ficaria surpreso se houvesse um tipo de Unix que se comportou de maneira diferente.

Tentei reproduzir o que você descreve e executei strace rm -rf ./nonempty. O que isso revela é o seguinte:

unlinkat(4, "subdir", AT_REMOVEDIR)     = -1 EACCES (Permission denied)

e de acordo com o unlinkatmanual (que no Linux é o mesmo unlink(2), grifo meu):

EACCES O acesso de gravação ao diretório que contém o nome do caminho não é permitido para o UID efetivo do processo ou um dos diretórios no nome do caminho não permite a permissão de pesquisa . (Consulte também path_resolution(7).)

Como o diretório pai, nonempty, não concede userpermissão x (pesquisa), faz sentido com base na EACCESdescrição que subdirnão pode ser removida.