Por que o alias de root vi para vim se é padrão para outros usuários?

Question

Em centos (e eu acredito em muitas outras distros) o vi é aliado ao vim para todos os usuários por padrão. No entanto, por alguma razão vi não é alias para vim para o usuário root, algo que sempre me irrita quando eu me esqueço de digitar vim em vez de vi ao usar o sudo e não tem recursos vim que eu vim a dar como certo, como destaque de sintaxe padrão.

Eu entendo como o aliasing é feito, e programaticamente porque um alias não existe quando eu sudo / su. Eu estou perguntando se há uma razão para isso ser um comportamento desejável, ou seja, por que os desenvolvedores centos não adicionaram um apelido para root também? Existe algum tipo de problema de segurança ou funcionalidade com o aliasing para vim para usuários raiz que não existe para usuários regulares? Existe uma razão histórica pela qual a raiz sozinha não deveria ter esse pseudônimo?

Indo adiante, há algum mal em adicionar um alias padrão do vi ao vim para os usuários raiz em servidores que eu mantenho? E se eu fosse fazer isso, haveria um método preferível que eu deveria usar para fazer isso (ou, mais precisamente, qualquer método que eu deveria evitar usar por razões de segurança?)

    

Answer 1

I'm asking if there is a reason for this to be desirable behavior, ie why didn't the centos developers add an alias for root as well? Is there some sort of security or functionality issue with aliasing to vim for root users that doesn't exist for regular users? Is there a historical reason root alone should not have this alias?

se você observar root versus usuários em echo $PATH , verá uma lista muito abreviada ... por padrão

É basicamente uma mentalidade de segurança para uma postura de segurança padrão para o Linux fora da caixa ... para aquelas pessoas que desejam apenas instalar e esperar tudo a ser configurado com relação a segurança .

Going along with that is there any harm in my adding a default alias of vi to vim for the root users on servers I maintain? And if I was to do it is there a preferable method I should use to go about it (or more accurately any method I should avoid using for security reasons?)

na maior parte do tempo, não há nenhum problema em adicionar aliases à conta raiz. Basta ter em mente como e onde você faz isso. A mentalidade segurança assume algo como isso pode acontecer e isso seria um vetor de ataque e um dos muitos meios para hackear um sistema. Mentalidade de segurança = minimizar ou impedir qualquer / todos os métodos de ataque, portanto, nenhum apelido.

fwiw, eu uso o SLES e usei o RHEL. Eu prefiro editar /etc/bash.bashrc.local e /etc/csh.cshrc.local para adicionar meus aliases, isso funciona para usuários não privilegiados. E esses dois arquivos são de propriedade de root.root com permissões -rw-r--r-- . Para root, eu simplesmente editei /root/.bashrc .

aliases não contornam as políticas de segurança básicas; se o fizerem, o problema não é com o alias que está com outra coisa.

    

Answer 2

Esta questão está prestes a solicitar opinião pessoal. Um administrador tem permissão para configurar seu sistema de maneira que ele seja adequado e, se a configuração padrão estiver incomodando, sugiro alterá-lo.

No entanto ...

O usuário root não é um usuário comum, e todas as ações tomadas no prompt interativo enquanto logado como root devem, idealmente, ser cuidadosamente consideradas. Para lembrar um administrador que eles estão logados como root, o prompt de root na maioria dos shells é por padrão diferente do prompt padrão para usuários privilegiados, e de fato, trabalhar em um prompt root deve lembrá-lo que você realmente não deveria estar lá para muito longo, se em tudo ¹ .

Uma razão vi não está com alias para vim pode me que, em uma situação em que bibliotecas compartilhadas passaram AWOL (devido a uma falha de disco ou exclusão acidental), vi pode ser um executável estático que funcionaria de qualquer maneira (ou pode ser vinculado a bibliotecas de outro caminho), permitindo que o administrador edite arquivos para colocar o restante do sistema em funcionamento novamente.

O mesmo raciocínio pode ser aplicado a outros "sinos e assobios" dos quais usuários comuns podem desfrutar. Em situações em que um administrador pode ser forçado a exibir um shell raiz interativo, as dependências dos recursos extras podem simplesmente não estar disponíveis.

¹ _{Trabalhando em um prompt de raiz, você não possui uma trilha de auditoria dos comandos que você digitou. Portanto, é melhor usar recursos como sudo para executar tarefas relacionadas à raiz, pois sudo , por padrão, registra quem faz o quê quando. Isso é extremamente importante em sistemas nos quais mais de uma pessoa possui direitos de administrador e sistemas corporativos.}

    

Answer 3

Decisões como essa geralmente dependem de preocupações com a facilidade de manutenção e segurança , embora essa segurança, mencionada em outras respostas, seja um fator. Alguns administradores de sistema não querem personalizações pessoais não documentadas para o ambiente interativo do superusuário. Eles querem que as coisas se comportem de maneira padronizada e documentada; sem surpresas desagradáveis. Além disso, eles precisam evitar a reaplicação de personalizações pessoais após novas instalações, atualizações do sistema e assim por diante.

No caso de vi , aliasing a vim potencialmente exibe um programa diferente no CentOS, /usr/bin/vim em vez de /bin/vi . O primeiro é um "VIM aprimorado" opcional que pode estar presente, com todos os tipos de recursos compilados, enquanto o último é "minúsculo VIM" com muito poucos recursos opcionais ativados. (O Ubuntu tem uma ideia similar.) As pessoas geralmente querem que o comando vi se comporte como o comando padrão vi , especialmente ao fazer coisas como o superusuário. Eles não querem um recurso aprimorado ou um material de alteração de plug-in de maneiras surpreendentes; ou, pior, quebrar nos modos de resgate ou emergência. Eles não querem que todo o documente de referência vi que alguém fazendo um trabalho crítico como o superusuário consulta, seja drasticamente errado por causa de tais coisas.

Isso significa chamar vi quando o administrador solicitar vi , não vim .

Dito de outro modo: Considerando que você passou a aceitar todos os tipos de personalizações e extensões VIM, o que outras pessoas tendem a considerar como garantido é que a conta de superusuário não / em> tem essas personalizações e extensões. Eles constroem essa suposição em páginas WWW, respostas Q & A e livros que eles escrevem. Eles formam hábitos e transportam conhecimento de um sistema para o próximo do que eles obterão quando o superusuário executar vi . (E às vezes isso é que tem VIMisms, ironicamente. Uma das coisas que as pessoas têm que aprender indo de um sistema operacional Linux para o FreeBSD é que vi is nvi e nenhum sabor de VIM em tudo.)

Além disso: eles não querem ter que lembrar de transportar /root/.vimrc e /root/.gvimrc sobre alterações no disco rígido, reinstalações do sistema e semelhantes; além dos arquivos de configuração do sistema.

Outro exemplo desse pensamento em ação é a conta toor no FreeBSD. É o superusuário, mas com uma casca semelhante a Bourne (a casca de Almquist, na verdade). A conta root tem o shell TENEX C, e porque há décadas - do BSD doco que mostram o superusuário dirigindo o sistema com o shell C, o conselho que as pessoas dão é deixar isso como é, e use toor para interação tipo Bourne. O shell C é o ambiente esperado quando logado como root , e se ele surgiu com um shell parecido com o Bourne para um superusuário que tinha (digamos) um livro de instruções shell para administrar o FreeBSD, hilaridade e desastre em potencial seguir.

Leitura adicional

• " vi ". Shell e utilitários . Única especificação do UNIX. Edição 7. IEEE 1003.1. 2018. O Grupo Aberto.
• link
• Dru Lavigne (fevereiro de 2009). BSD Hacks: 100 Dica Industrial & Ferramentas . O'Reilly Media. ISBN 9780596006792.
• link
• Sven Guckes (2017). Vi Clones e HomePages . guckes.net.