Existe uma boa razão para não adicionar sbin ao PATH padrão?

Question

Histórico:

A variável de ambiente PATH especifica os diretórios a serem pesquisados quando um comando é emitido sem especificar um caminho. Os caminhos "sbin" ( /sbin , /usr/sbin ) destinam-se a abrigar utilitários administrativos, de modo que muitas distribuições * nix não incluem esses diretórios na configuração padrão para PATH . Dito isto, há muitas circunstâncias em que as contas não administrativas legitimamente precisam acessar esses utilitários e devem especificar caminhos completos ou modificar sua variável PATH para fazer isso. Essa tarefa é relativamente fácil de executar, mas pode ser incômoda para novos usuários. Pior, há problemas mais difíceis quando você envolve PAM, sudo, ssh e outros utilitários que interagem e às vezes modificam a configuração PATH . Uma pesquisa neste site ou na internet em geral produz muitas amostras desses problemas, que afligem usuários novos e veteranos.

A pergunta:

Com o plano de fundo mencionado anteriormente, há uma boa razão para não adicionar diretórios sbin ao PATH padrão? (presumivelmente através de /etc/profile , /etc/profile.d ou equivalente)

Eu reconheço que "bom" é subjetivo, mas aqui estão algumas razões que não prendem a água na minha opinião. Talvez você discorde?

Não é bom:

• Segurança
  • Privilégios elevados e o diretório que contém um utilitário não estão relacionados para diretórios acessíveis ao mundo ( r-x ). Um argumento de obscuridade poderia ser feito de que malvados inadequados não poderiam encontrar utilidades "escondidas", mas isso seria uma cortina tristemente transparente.
• Namespace
  • Pode-se argumentar que um usuário pode querer escrever seu próprio comando reboot , que acessa por meio de seu próprio diretório customizado, que incluiu em seu PATH , e um padrão do sistema em um diretório sbin superaria sua configuração . Este é um caso crucial e um caso em que o usuário em questão já insere PATH implicações e pode modificar sua configuração para usar seu diretório mais cedo na sequência.
• Padrões
  • Isso não é uma alteração no Padrão de Hierarquia do Sistema de Arquivos; utilitários ainda são organizados em seus diretórios de acordo com suas funções.
  • Não consertar um problema porque "estamos acostumados a ter esse problema" é bobo.

Answer 1

Não há nenhuma razão real para usuários comuns não terem esses programas em seu PATH , e se ter um usuário comum ligar para um desses programas é um problema, então o programa e / ou sua segurança precisam ser corrigidos. / p>

Você terá prazer em encontrar no RHEL 6 e superior que /sbin e /usr/sbin agora estão no padrão PATH para todos os usuários, pois está no Fedora há muitos anos . (E /sbin é um link simbólico para /usr/sbin a partir do RHEL 7, mas isso é outro problema.)

    

Answer 2

Você pode adicionar isso facilmente através da definição PATH local ou do sistema. A razão para a separação é principalmente tradição e era uma função dos comandos em "sbin" sendo binários do sistema ...

Nas minhas instalações e ambientes, isso não é um problema. Meus usuários não precisam de acesso aos utilitários do sistema. A etapa adicional de executar sudo ou su - para escalar privilégios ou digitar um caminho de comando completo é razoável, pois os sistemas normalmente não hospedam sessões interativas. No entanto, isso pode não ser o caso da sua situação. Se for um problema, modifique a variável PATH.