Existe algum motivo pelo qual /proc/*/cmdline é legível para o mundo?

Suspeito que o principal, e talvez único, motivo seja histórico - /proc/.../cmdlineera inicialmente legível para o mundo, então permanece assim para compatibilidade com versões anteriores. cmdlinefoi adicionado em 0.98.6, lançado em 2 de dezembro de 1992, com o modo 444; o changelog diz

     - /proc filesystem extensions.  Based on ideas (and some code) by
       Darren Senn, but mostly written by yours truly.  More about that
       later.

Não sei quando foi “mais tarde”; até onde posso dizer, as ideias de Darren Senn estão perdidas nas brumas do tempo.

environé um contra-exemplo interessante para o argumento de compatibilidade com versões anteriores: ele começou legível por palavras, mas foi tornado legível apenas por seu proprietário em 1.1.85. Eu não encontrei o changelog para isso, então não sei qual foi o raciocínio.

A acessibilidade geral e visibilidade de /proc/${pid}(incluindo /proc/${pid}/cmdline) podem ser controladas usando proca hidepidopção mount do , que foi adicionada na versão 3.3 do kernel . A gidopção mount pode ser usada para dar acesso total a um grupo específico, por exemplo , para que os processos de monitoramento ainda possam ver tudo sem executar como root.

A linha de comando dos processos sempre foi considerada informação pública no Unix e sempre esteve disponível através do ps(1)comando. O ambiente de um processo, ao contrário, nunca foi uma informação tão pública.

Na implementação original do Unix, pshavia um executável setuid que abria /dev/meme extraía todas as informações diretamente da memória viva do kernel, na forma de um depurador. O Linux suportava um sistema de arquivos semelhante ao plan9 /procdesde o início e psfoi implementado como um programa simples não setuid que apenas abria e lia arquivos como /proc/<pid>/state /proc/<pid>/cmdline. Como eles foram concebidos tanto como a interface do kernel/usuário regular para obter essas informações e como uma alternativa amigável ao shell para analisar a saída de ps(eca), eles não poderiam ser e não fazia sentido ser mais restritivo do que ps.

Claro, isso afetaria outros usuários executando pse htopsimilares - mas isso é uma coisa boa, certo? Esse seria o ponto de não torná-lo legível para o mundo.

Não, não é uma coisa boa. Além de quebrar o padrão (veja o link acima) que tornará o sistema indepurável sem privilégios de root, e as vantagens de segurança disso seriam na melhor das hipóteses ilusórias. (Observe que na época em que o Unix foi inventado, a segurança por meio da obscuridade e as restrições à liberdade de expressão ainda não estavam na moda como são hoje.)

Você não precisa imaginar como seria um sistema Linux - já existe o Android, cujo sistema não enraizado é uma caixa preta desagradável (bloqueada de todas as maneiras possíveis, não apenas com hidepid) para seu(s) usuário(s) real(is) , mas não mais robusto contra invasores externos e coletores de dados do que um desktop ou servidor Debian ou Slackware típico.