Por que os pacotes linux esperam permissões de root para instalar?

Esta é uma pergunta sobre as escolhas de design do * nix, e não como evitá-lo.

Qual é o propósito de exigir acesso root para instalar a maioria dos pacotes? Parece uma falha de segurança em potencial exigir que você use root, já que a maioria dos pacotes não precisará modificar o kernel ou precisar de privilégios de root para executar. Se o objetivo é apenas instalar o pacote uma vez por máquina para todos os usuários economizarem espaço, por que não ter um usuário não-root diferente para essa finalidade?

Atualização: Estou presumindo aqui que os pacotes instalados sem acesso root não seriam instalados nos diretórios protegidos por raiz, mas em outro lugar.

Como outros observaram nos comentários, uma razão óbvia para exigir permissões de root é que os pacotes pré-compilados são instalados em diretórios compartilhados do sistema, que não devem ser gravados por qualquer pessoa. Por que não "um usuário não-root diferente"? Eu diria, porque pacotes suficientes precisam fazer mudanças nos arquivos e diretórios compartilhados do sistema que não vale a complexidade de saber quais pacotes realmente precisam de root e quais não, e porque não instalar como root não compra todos muito - você já está colocando sua fé no fornecedor para muitos dos pacotes principais, então o que há de mais. Mas, em última análise, sim, há uma compensação de segurança e parece que os fornecedores decidiram que a simplicidade ganha aqui.

Isso nos leva à questão de por que os pacotes não podem ser instalados apenas para, digamos, o diretório pessoal de um usuário. Na verdade, em muitos casos, eles podem, mas somente se você usar uma distribuição baseada em fonte, como o Gentoo. Nesse caso, você apenas compila o programa com um --prefix ou argumento similar (muitos, mas não todos, pedaços de software suportam tal conceito). A maioria das distros é baseada em binários, e, nesse caso, o problema é que muitos programas Unix são escritos de tal forma que vários caminhos são codificados no programa em tempo de compilação, e uma tonelada de trabalho e coordenação seria necessária para mudar isso quando você está lidando com milhares de pacotes e seus mantenedores. A coordenação é especialmente difícil no mundo Unix, pois há relativamente muitos fornecedores de sistemas, ao contrário do Windows, onde a Microsoft pode ditar mudanças em grande medida - e até mesmo a Microsoft tem problemas para fazer com que todos entrem na fila, daí a necessidade de medidas de compatibilidade como Virtualização UAC .

Indo mais para o problema do caminho codificado, considere um programa foo que precisa acessar seu banco de dados de algum tipo. Onde está esse arquivo? Um caminho plausível é /usr/share/foo/foo.db, que seria codificado no programa, para que ele saiba exatamente onde procurar. Você pode objetar que um programa poderia simplesmente tentar $HOME/usr/share/foo/foo.db ou similar, se não encontrar o arquivo codificado. Isso é verdade, e isso seria bom, exceto que não existe um padrão ou uma convenção real para esse tipo de coisa, então a maioria dos programas simplesmente não implementa esse mecanismo de fallback (esse problema de coordenação, novamente). E, sem dúvida, também adiciona complexidade que beneficia uma parte relativamente pequena da população de usuários, mas isso é outra lata de worms.

Um problema relacionado é como um programa carrega as bibliotecas compartilhadas das quais depende. O vinculador dinâmico, ld.so, precisa saber onde encontrar todas essas bibliotecas compartilhadas. Basicamente, uma lista de caminhos pode ser (novamente) codificada no executável em tempo de compilação, caso em que ld.so pesquisará esses caminhos primeiro; falhando naquilo, ld.so procura nos diretórios configurados /etc/ld.so.conf. Esse problema é relativamente fácil de superar, por exemplo, definindo LD_LIBRARY_PATH variável de ambiente de forma adequada.

Assim, a conclusão é que muitos programas não são projetados para serem flexíveis (em tempo de execução) sobre como eles encontram seus arquivos e, conseqüentemente, os desenvolvedores de pacotes não acham que vale a pena oferecer a opção de instalar para alternar. diretórios. Não é que isso seja tecnicamente impossível - apenas que até agora, não houve a vontade de criar um padrão e fazer com que todos o seguissem. Para um exemplo mostrando como isso não é tecnicamente impossível, você pode dar uma olhada na minha resposta para essa pergunta: Instalar git no servidor sem sudo . Note como é uma solução feia, e esse é o triste estado das coisas.

Para o registro, eu realmente compartilho sua frustração em não ser capaz de instalar facilmente pacotes binários em locais alternativos, e passei tempo e esforço consideráveis ​​ao longo dos anos na compilação manual de pacotes ou trabalhando em torno de problemas de empacotamento (de maneira semelhante à pergunta à qual me vinculei no parágrafo anterior) ao executar em sistemas nos quais os administradores de sistema não são cooperativos sobre a instalação de pacotes que desejo usar.