O Vim é seguro para uso em combinação com o sudo?

Não é aconselhável usar sudocom um aplicativo gráfico como gedit, conforme descrito neste link . Assim, eu tendem a usar vimcom sudo.

Recentemente, notei que o meu ~/.viminfopertencia ao root em uma instalação bastante recente do Ubuntu 16.04 (Xenial Xerus), por isso me perguntei se até o Vim é considerado gráfico ou se há algum outro problema ao invocar sudo vim. Depois de alterar a propriedade para mim via:

sudo find $HOME -not -user $USER -exec chown $USER:$(id -g) {} +

e, subseqüentemente executando sudo vim, não consegui ter ~/.viminfo propriedade de raiz. No entanto, estou certo de que recentemente ele pertenceu à raiz.

É desaconselhável invocar sudo vim?

Sim, é seguro.

O problema sudo gedité que os aplicativos da GUI usam determinados arquivos, como ~/.cache/dconf, e após elevados, geditesse arquivo se torna de propriedade da raiz. Bem, esse arquivo em particular contém configurações específicas do usuário para aplicativos da GUI, incluindo a área de trabalho, portanto, se o sistema não puder ler essas configurações - é ruim. IIRC, um usuário não pode iniciar uma área de trabalho específica. Os dados dos arquivos recentes do usuário recently-used.xbeltambém são afetados.

Por outro lado, o Vim não tem esse problema. Ele não usa banco de dados relacionado à GUI e não coloca nada recently-used.xbel. Foi criado apenas para o console, embora o gVim também exista. De fato, em alguns sistemas, o Vim é sua única opção de editor. Portanto, é mais seguro que o gedit em virtude de não causar os mesmos problemas. Você ainda está editando como raiz nos dois casos, para poder causar problemas com a edição incorreta.

De acordo com este post do blog :

Na primeira vez em que você usa o vim, o arquivo ~/.viminfoé criado e, se você usar sudo vima primeira vez depois de instalá-lo em um sistema novo, as permissões ~/.viminfoterão o proprietário definido como root em vez do usuário padrão.

Enquanto o autor aponta que isso pode causar problemas, não há nada complexo - apenas chowno arquivo de volta para si mesmo.

Veja também:

• Que coisas ruins específicas acontecem quando o gedit é usado com o sudo?

Também é possível usar sudoeditpara conseguir isso; ele abre uma cópia temporária do arquivo no seu editor, com o seu editor sendo executado como você. Na página do manual :

1. São feitas cópias temporárias dos arquivos a serem editados com o proprietário definido para o usuário que está chamando.

2. O editor especificado pela política é executado para editar os arquivos temporários. A política de sudoers usa as variáveis ​​de ambiente SUDO_EDITOR, VISUALe EDITOR(nessa ordem). Se nenhum SUDO_EDITOR, VISUALou EDITORestiver definido, o primeiro programa listado na sudoers(5)opção do editor será usado.

3. Se eles foram modificados, os arquivos temporários são copiados de volta para o local original e as versões temporárias são removidas.

Isso funciona bem com o vim (é o que eu geralmente faço) e imagino que você também usaria o gedit. Existem algumas restrições de segurança .

O link é muito antigo (2013). Ele recomenda usar gksudoou gksupara aplicativos gráficos, mas ambos estão se tornando obsoletos. Mais tarde, a resposta aceita também sugere sudo -H.

O consenso geral na comunidade Ask Ubuntu recentemente é usar:

sudo -H gedit /path/to/filename

O único problema é que sudonão existe um perfil para configurações de guias, extensões, quebra de linha, nome da fonte, tamanho da fonte etc. Você pode herdá-las do seu perfil de usuário com um script de wrapper como este: Como sincronizar minha raiz gedit com as preferências do meu usuário gedit?

Sim, é seguro de usar sudo vim. Os problemas que encontro são

• Ter que sair do arquivo e reabri-lo sudo vimpara poder editá-lo.

• Tendo a raiz vimrccomo padrão, não minhas coisas úteis personalizadas.

Aqui está uma função que você pode colocar no seu bashrcpara permitir que o vim sudo automaticamente, se você não puder editar o arquivo normalmente.

vim() {
    #only good for auto-sudo. delete if no sudo privileges.
    #If you're not just opening a single file, let's not use this.
    if [[ "$#" -ne 1 ]]; then
        command vim "$@"
    #cases: if we can write to the file, or the file doesn't exist and we can make new files in that directory
    elif [[ -w "$1" || ( -w $(dirname "$1") && ! -f "$1" ) ]]; then
        # \vim or 'vim' only escape aliases, not functions
        command vim "$1"
    else
        sudo env HOME="$HOME" vim -u $HOME/.vimrc "$1"
    fi
}

É bom usar o vi como root. Haverá momentos em que você precisará editar um arquivo que exija privilégios sudo ou root, como alterar seu arquivo de interfaces de rede ou talvez editar seu arquivo de configuração sshd. Usar o root para coisas gráficas é ruim porque as pessoas se conectam ao IRC ou navegam na web como root. Se eles pegassem um vírus ao fazê-lo, ele teria acesso root completo.

Algo que não foi mencionado nas outras respostas é que a execução do vim com root dará privilégios de root a quaisquer plugins que você instalou. Portanto, a questão de saber se é seguro ou não ser executado como root depende se você confia que os desenvolvedores de plug-ins (ou colaboradores do projeto) não possuam o sistema em sua essência.

O Vim é normalmente avaliado pelos mantenedores de pacotes em todas as distribuições Linux, por isso é fácil confiar. No entanto, os plugins vim geralmente são instalados diretamente dos repositórios do GitHub e normalmente têm muito menos usuários auditando (talvez nulo). Em outras palavras, não há processo de verificação com eles.

Se você não carregar plugins enquanto estiver no root, acho que a execução como root depende se você confia nos desenvolvedores do vim. No entanto, você pode deixar de confiar neles, usando o sudoedit, criado pelos mesmos desenvolvedores do sudo, pessoas nas quais já confiamos com acesso root. GKFX e NieDzejkob já mencionaram por que o sudoedit é ideal. Além do ponto em que você não precisa confiar no acesso root a ninguém além dos desenvolvedores do sudo, você pode carregar todos os plugins em que você já confiou com sua conta de usuário normal.