Como você supõe, a permissão de execução raramente é útil como uma permissão. Tê-lo como uma permissão e não como um atributo do arquivo é um pouco de um acidente histórico. No entanto, desde que existe, não vai desaparecer. Ter uma permissão de execução diferente da permissão de leitura é importante em dois casos.
- Se a execução de um arquivo confere privilégios adicionais, importa quem pode executar esse arquivo em particular. Um executável setuid ou setgid ou setcap pode ser legível pelo mundo, mas não ser executável em todo o mundo (muitas distribuições tornam os arquivos setxid legíveis para o mundo, mesmo que não sejam executáveis por não serem confidenciais - qualquer um pode fazer o download do arquivo arquivos).
- Algumas contas podem estar restritas de tal forma que não podem gravar nenhum conteúdo em um arquivo executável. Por exemplo, uma conta pode ter acesso somente a um shell restrito sem
chmod ou só pode gravar em diretórios em um sistema de arquivos montado com noexec . Esse usuário está restrito aos arquivos executáveis que já existem.
Adicionar uma chamada de sistema para exec a partir da memória permite que contas restritas executem código arbitrário. É equivalente a ter um interpretador de código nativo acessível de qualquer lugar, até mesmo de contas restritas. Isso não seria aceito no kernel mainstream, uma vez que iria quebrar as restrições de segurança. Você pode implantá-lo em suas próprias máquinas, mas deve ter em mente as implicações.
No entanto, há muito trabalho e muita bagagem de segurança para carregar para um recurso que já existe. É possível executar código sem gravar no disco. Você só precisa escrever o código em um arquivo em um sistema de arquivos que não seja de disco, como o tmpfs.