Qual é a diferença entre o usuário root e o comando sudo no Ubuntu? Quando deve ser usado root?

Question

No prompt de comando do Ubuntu, você pode fazer sudo -i e digitar root senha para fazer o login como root . Minha pergunta é, quando você deve entrar como este root no Ubuntu (ou Linux)? É só para evitar digitar sudo nos comandos que exigem root privilégio?

    

Answer 1

when must you login as this root in Ubuntu (or Linux)? Is it just to avoid typing sudo on commands requiring root privilege?

A minha interpretação das suas perguntas é:

• Há cenários em que você deve usar sudo -i porque sudo não é suficiente?
• Ou sudo -i é apenas para evitar digitar sudo vezes sem conta, mas não dá outra vantagem?

A principal vantagem de sudo -i é que ele inicia um shell. Você pode então usar pipes, redirecionamentos, etc. como root. Considere:

sudo dd if=/dev/sdc conv=noerror bs=32M | pv | gzip -c > /root/image.raw.gz

Nesse caso, sudo afeta apenas dd . Enquanto você está solicitando sua senha, pv já está em execução, seu monitor fica confuso. Ao mesmo tempo, seu shell informa que você não tem acesso a /root/image.raw.gz , apesar de usar sudo ; isso ocorre porque o redirecionamento ( > ) é executado pelo shell que está sendo executado sem sudo .

Existem várias técnicas para contornar esses obstáculos. A lista a seguir provavelmente não é exaustiva:

1. Execute sudo true antes e insira sua senha. Seu sudo não solicitará você novamente em alguns minutos, a menos que esteja configurado de outra forma.

2. Use sudo tee da seguinte forma:

   sudo dd if=/dev/sdc conv=noerror bs=32M | pv | gzip -c | sudo tee /root/image.raw.gz > /dev/null
   

3. Ou execute o comando dentro de um shell extra:

   sudo bash -c 'dd if=/dev/sdc conv=noerror bs=32M | pv | gzip -c > /root/image.raw.gz'
   

4. Ou execute este shell extra e trabalhe nele: sudo bash ou sudo -i (ambos os comandos não são bem equivalentes).

Então, você realmente não precisa de -i . Pode não existir, você ainda seria capaz de fazer as coisas como root.

Outra vantagem pode ser que sudo -i executa um shell que origina os arquivos da raiz (como .profile ), enquanto sudo bash ou sudo bash -l usa os arquivos do usuário invocador. Eu posso imaginar que um pode ter um ambiente definido para raiz, adaptado para tarefas administrativas. Nesse caso, sudo -i é útil.

Os perigos de trabalhar em um shell executando com privilégios de root são cobertos por outras respostas. Eu não vou repeti-los.

    

Answer 2

A menos que exista um bom motivo para você usar root regularmente - e não consigo pensar em um - sudo é a melhor alternativa para salvá-lo de si mesmo e fornecer proteção básica do sistema para a instalação do seu sistema operacional. / h3>

root é um artefato histórico de sistemas Unix / Linux. Muitos sistemas têm um usuário root definido como padrão - como RedHat e CentOS - mas, pelo que eu saiba, o Ubuntu especificamente força você a usar por padrão um usuário que não seja root para fazer sudo / root coisas obrigatórias. sudo nasceu da necessidade de impedir que root seja um usuário alvo tão conhecido e vulnerável e delegar root privileges a outros usuários no sistema de maneira controlada e focada. Como explicado em “ Sudo in a Nutshell ”:

Sudo (su "do") allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis, it is not a replacement for the shell. Its features include:

• The ability to restrict what commands a user may run on a per-host basis.
• Sudo does copious logging of each command, providing a clear audit trail of who did what. When used in tandem with syslogd, the system log daemon, sudo can log all commands to a central host (as well as on the local host). At CU, all admins use sudo in lieu of a root shell to take advantage of this logging.
• Sudo uses timestamp files to implement a "ticketing" system. When a user invokes sudo and enters their password, they are granted a ticket for 5 minutes (this timeout is configurable at compile-time). Each subsequent sudo command updates the ticket for another 5 minutes. This avoids the problem of leaving a root shell where others can physically get to your keyboard. There is also an easy way for a user to remove their ticket file, useful for placing in a .logout file.
• Sudo's configuration file, the sudoers file, is setup in such a way that the same sudoers file may be used on many machines. This allows for central administration while keeping the flexibility to define a user's privileges on a per-host basis. Please see the samples sudoers file below for a real-world example.

Em um nível prático, usar sudo força o usuário final a pensar sobre o que está fazendo. Se eu fosse simplesmente digitar rm -rf * as root o comando funcionaria ... Mas 99% do tempo qualquer coisa que alguém faz em um sistema Unix / Linux não precisa de root privileges. poder ilimitado como root todo o tempo é bobo na melhor das hipóteses, arriscado na pior das hipóteses.

Além disso, como root é um login conhecido, muitos administradores de sistema desabilitam o logon root da conta - e bloqueiam-no - por padrão e atribuem direitos equivalentes via sudo a outro usuário. Acredite ou não, simplesmente desativar root é uma das maneiras mais rápidas, simples e melhores de fornecer segurança básica a um sistema contra ataques de tentativas de login por SSH. Basta criar um novo usuário, algo como cooldude - e, em seguida, conceda a esse usuário sudo direitos e seu sistema já estará em uma situação sólida.

A razão disso é o "script kiddies" do gajillion e as ferramentas de penetração do sistema disponíveis no mercado segmentam root access por meio de (aparentemente) intermináveis tentativas de login SSH diretamente da caixa. Essas ferramentas de penetração de sistemas disponíveis no mercado são, na melhor das hipóteses, ferramentas genéricas e sem cérebro. Você deixa root ativo com uma senha simples e está esperando que um problema aconteça. Mas simplesmente dando direitos de administrador para alguém como cooldude , todos esses scripts são ineficazes. Sim, claro, se alguém souber que seu root equivalente é cooldude , ele pode segmentar isso ... Mas, em 99,9999% das vezes, um invasor não será ambicioso o suficiente para investigar essa profundidade.

Mude para root por sua conta e risco. Eu faço o trabalho de administração do sistema Linux profissional e não toquei em root após um estágio de instalação inicial nos últimos 20 anos.

    

Answer 3

sudo -i é simplesmente uma maneira de obter uma sessão interativa como root. (Existem várias outras maneiras disponíveis no Ubuntu, incluindo sudo / bin / bash, e habilitar uma senha de root e logar como root).

A ideia por trás disso tudo é "privilégio mínimo". Para a maioria das coisas do dia-a-dia (navegação na web, edição de fotos, documentos de escritório, etc.), você não precisa entrar nos componentes internos do sistema. Executar como um usuário normal impede que você faça algumas coisas estúpidas em seu sistema e é uma prática recomendada.

Ocasionalmente, você precisará fazer algo que exija mais privilégios - por exemplo, formatar um disco ou instalar um software que seja compartilhado entre os usuários - nesses casos, você usaria o root. Se for um único comando, usar o sudo é adequado, mas muitas vezes há várias tarefas relacionadas a fazer, e nesse caso usar o sudo se irrita muito rápido.

Separar o uso da administração do acesso regular do usuário pode impedir que programas ruins causem danos - como apagar todo o sistema - e é uma boa precaução - mas ele realmente acontece quando um dispositivo é compartilhado entre vários usuários.

O acesso sudo / root é análogo a "executar como administrador" em uma caixa do Windows - e fornece benefícios e frustrações semelhantes. Eu noto que o sudo pode ser usado não apenas para obter acesso root, mas também para obter acesso a outros usuários não-root. Há também controles e permissões (geralmente configurados em / etc / sudoers ou /etc/sudoers.d) que podem permitir que determinados usuários apenas executem determinadas coisas com privilégios elevados e / ou permitam acesso sem uma senha adicional para alguns usuários. / p>     

Answer 4

Não se deve logar como usuário root, a menos que haja uma razão muito específica para isso. Quando logado como root, você tem a capacidade de, na pior das hipóteses, destruir todo o sistema. Alguns sistemas UNIX / Linux usam como padrão negar os privilégios de login do usuário root para evitar tal ocorrência. Forçar um usuário a efetuar login como usuário padrão e usar sudo para executar comandos elevados é uma medida de proteção e segurança.

Tenho certeza de que muitas pessoas na SU e em outros sites do StackExchange relacionados a TI (inclusive eu) cometeram o erro de fazer login como raiz (ou Administrador no Windows) e esqueceram. Então eles fizeram algo que eles muito não queriam fazer.