Qual é o motivo de ter ou restringir as permissões do proprietário do arquivo?

Existem várias razões para reduzir as permissões do proprietário (embora raramente para menos do que as do grupo).

• O mais comum é não ter permissão de execução em arquivos que não devem ser executados. Muitas vezes, scripts de shell são fragmentos destinados a serem originados de outros scripts (por exemplo, seu .profile) e não fazem sentido como processos de nível superior. A conclusão do comando oferecerá apenas arquivos executáveis, portanto, as permissões corretas ajudam nos shells interativos.

• A substituição acidental de um arquivo é um risco substancial - pode acontecer por meio da digitação incorreta de um comando ou ainda mais facilmente em programas GUI. Uma das primeiras coisas que faço ao copiar arquivos da minha câmera é torná-los (e o diretório que os contém) não graváveis, de modo que todas as edições que eu fizer sejam cópias, em vez de sobrescrever o original.

• Às vezes é importante que os arquivos nem sejam legíveis. Se eu atualizar meu Emacs e tiver problemas com pacotes locais em meu ~/lispdiretório, eu os desabilito seletivamente (com chmod -r) até que ele possa iniciar com sucesso; então posso torná-los legíveis um de cada vez enquanto corrijo problemas de compatibilidade.

Um conjunto correto de permissões para usuário indica intencionalidade . Embora o usuário possa alterar as permissões, programas bem comportados não farão isso (pelo menos, não sem perguntar primeiro). Em vez de pensar nas permissões como restringindo o usuário , pense nelas como restringindo o que os processos do usuário podem fazer em um determinado momento.

Você parece estar perdendo um ponto bastante importante aqui: processos bem comportados não modificam as permissões dos arquivos aos quais eles têm acesso. lsnão tornará aleatoriamente um diretório para o qual você aponta legível apenas para poder listar o conteúdo do diretório. sshnão 'conserta' as permissões ~/.sshou os arquivos que ele contém se estiverem errados, ele simplesmente se recusará a ser executado. E geralmente é seguro assumir que qualquer programa que você provavelmente usará se comporta bem dessa maneira.

Isso significa que quais permissões são definidas em um determinado arquivo para o proprietário geralmente são honradas (a menos que você seja o usuário root ou de alguma outra forma seja capaz de curto-circuitar as verificações de DAC (como CAP_DAC_OVERRIDEno Linux), porque programas sãos apenas confie no kernel para verificar as permissões) e, portanto, geralmente é útil proteger um determinado arquivo contra modificação ou execução acidental. E embora isso possa ser superado com relativa facilidade, o usuário precisa explicitamente fazer algo para superá-lo . IOW, funciona como mais uma etapa de confirmação para indicar que 'Sim, eu realmente quero fazer isso.'.

Mais genericamente, porém, como as permissões do proprietário geralmente são respeitadas, há várias coisas úteis que você pode fazer com elas:

• Torne os arquivos ou diretórios somente leitura (equivalente a definir o atributo 'Somente leitura' no Windows).
• Marque os arquivos como não executáveis ​​(ou .desktoparquivos XDG como não confiáveis).
• Funcionalmente 'ocultar' o conteúdo de diretórios (marcando o diretório como não legível) ou arquivos. Isso é realmente muito útil ao depurar problemas com plug-ins para alguns aplicativos, porque a maioria dos aplicativos que usam diretórios ou arquivos por plug-in age como se o plug-in não estivesse lá se seus arquivos não fossem legíveis.

Na maioria das vezes, faço isso para evitar a exclusão/modificação acidental, como você sugeriu. Às vezes, no entanto, faço isso para poder realizar modificações em lote em todos os arquivos/diretórios em uma determinada árvore, exceto aqueles que "protegi".

Permissões de proprietário restritas são úteis em ambientes restritos, onde o usuário não tem acesso a ferramentas que alteram permissões.

O exemplo clássico são os servidores FTP anônimos. Você pode criar um diretório "caixa de depósito" onde o proprietário tenha permissões de gravação, mas não permissões de leitura. Isso permite que usuários anônimos carreguem arquivos, mas não listem os arquivos que outros usuários enviaram. Enquanto isso, o diretório seria legível por seu grupo, então colocaríamos os usuários que têm permissão para recuperar do diretório nesse grupo. Se o servidor FTP não fornecer um chmodcomando, os usuários anônimos não poderão substituir isso e dar a si mesmos permissão para listar o diretório.