Por que não usamos o root para tudo (e o que fazemos em vez disso)

Publicado em 2026-09-12 por frfrand

Trabajar como root no ahorra tiempo: quita las advertencias, rompe los dueños de los archivos y borra el rastro de quién hizo qué. Qué hace sudo realmente y cómo configurarlo bien.

"Entro como root y listo, es mais rápido." Eu ouvi isso muitas vezes e, por um tempo, fiz isso.

O problema é que root não é um modo de especialista: é um modo sem freios. O kernel não verifica permissões para o uid 0, então nenhuma das proteções que o Linux traz ativadas se aplica a você.

O que segue não é uma regra moral, são quatro consequências bem concretas.

1. Não há rede de contenção

# rm -rf /var/www/ midirectorio

Esse espaço a mais apaga o /var/www/ inteiro e depois reclama que midirectorio não existe. Como root, ele é executado instantaneamente e sem perguntar.

Como usuário normal, esse mesmo comando falha com "Permissão negada" e nada acontece. O erro continua sendo seu, mas o sistema o impediu.

Muitas das catástrofes clássicas de administração são exatamente isso: um comando correto com um argumento errado, executado por alguém que podia tudo.

2. Quebra os donos dos arquivos

Esta consequência é menos dramática e muito mais frequente.

Se você clonar o repositório como root, todos esses arquivos ficam sendo de root. Depois, sua aplicação, que roda como www-data ou como deploy, não consegue escrever na pasta de cache, ou não consegue criar o arquivo de log, ou não consegue fazer upload de um arquivo.

O sintoma aparece dias depois e não se parece em nada com a causa: um erro 500 opaco, uma função que "não funciona no servidor, mas funciona localmente". A pista é sempre a mesma:

$ ls -l drwxr-xr-x 2 root root 4096 Nov 1 10:15 storage

Esse "root root" onde deveria dizer "deploy deploy" é a origem do problema.

3. Se perde o rastro

Se três pessoas compartilham a senha de root, o sistema registra que "root fez algo". Não serve para nada.

Quando cada pessoa entra com seu usuário e usa sudo, cada comando privilegiado fica em /var/log/auth.log:

Nov 1 10:22:11 srv sudo: deploy : TTY=pts/0 ; PWD=/home/deploy ; USER=root ; COMMAND=/bin/systemctl restart nginx

Isso não é para repartir culpas. É para poder responder "o que mudou aqui?" seis semanas depois sem depender da memória de ninguém. Na maioria das equipes, essa pergunta é feita muito mais frequentemente do que qualquer auditoria.

4. E a parte que quase ninguém faz: sudo se configura

sudo não é tudo ou nada. Pode-se conceder permissão para comandos específicos, que é como deveria ser usado na maioria dos casos:

# /etc/sudoers.d/deploy deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart miapp, /bin/systemctl status miapp

Com isso, o usuário deploy pode reiniciar sua aplicação sem senha e sem poder fazer nada mais. Perfeito para um script de implantação.

Dois avisos importantes:

• Edite sempre com visudo. Valide a sintaxe antes de salvar. Um erro nesse arquivo pode deixar todo mundo sem sudo, e corrigi-lo requer acesso ao console.
• Cuidado ao conceder permissão sobre comandos que permitem executar outra coisa. "sudo vim" é, na prática, sudo para tudo: a partir do vim, é possível abrir um shell.

Lo mínimo que conviene dejar hecho

En /etc/ssh/sshd_config:

PermitRootLogin no PasswordAuthentication no

Lo primero impide entrar como root por SSH directamente. Lo segundo obliga a usar clave. Con esas dos líneas, la enorme mayoría de los intentos automáticos que va a recibir tu servidor dejan de tener sentido.

Antes de recargar: sshd -t para validar, y dejá una segunda sesión abierta por las dudas.

La costumbre que vale la pena

Cuando estés por escribir sudo delante de algo, preguntate: ¿esto necesita root, o el servicio al que pertenece debería estar corriendo con otro usuario?

Muchas veces la respuesta correcta no es dar más permisos, sino arreglar de quién es el archivo.

En ArduMaker los VPS se entregan con el login de root por SSH deshabilitado y tu usuario ya creado con sudo. Y cada comando que se lanza desde el panel queda registrado con quién lo ejecutó, que es la versión automática del auth.log del que hablábamos arriba.