Por que o Linux é multiusuário desde o primeiro dia

Publicado em 2026-09-12 por frfrand

De dónde salen los permisos, los uid y la costumbre de que cada servicio tenga su propio usuario, y por qué ese diseño de hace cincuenta años sigue siendo la mejor defensa gratuita que tenés.

Quando alguém começa com Linux, as permissões parecem burocracia. Por que tenho que usar sudo para tudo? Por que há quinze usuários que eu não criei?

A resposta está na origem. Unix, do qual Linux é herdeiro direto, nasceu em 1969 em um mundo onde um computador custava o que hoje custa um prédio e era usado por dezenas de pessoas ao mesmo tempo. Não era uma máquina pessoal: era um recurso compartilhado.

Isso obrigou o sistema a responder uma pergunta em cada operação: quem está solicitando isso?

O uid é o que realmente importa

O sistema não trabalha com nomes, trabalha com números. Cada usuário tem um identificador, o uid, e o nome é apenas um rótulo para que os humanos o leiam.

$ id uid=1000(deploy) gid=1000(deploy) groups=1000(deploy),27(sudo)

Há uma convenção bastante universal:

• uid 0 é root. Não é "o administrador" por configuração: é root porque seu uid é 0, e o kernel ignora as verificações de permissão para o uid 0. Se você mudar o nome, ele continua podendo tudo.
• uid 1 a 999 são usuários de sistema: serviços, daemons. Eles não têm senha nem shell de login.
• uid 1000 em diante são as pessoas.

Por isso o whoami pode mentir e o id não: o primeiro mostra o nome, o segundo o número.

Cada serviço com seu usuário

Este é o hábito que mais segurança oferece e que mais gente quebra sem perceber.

Em um servidor bem configurado, cada serviço roda como um usuário distinto:

$ ps -eo user,comm | sort -u | head postgres postgres redis redis-server root systemd www-data nginx

A lógica é de contenção de danos. Suponha que surge uma vulnerabilidade no nginx e alguém consegue executar código por meio dela. O que ele consegue? As permissões do www-data, que normalmente são apenas ler os arquivos do site, e pouco mais.

Não pode ler seu .env, porque esse arquivo é de deploy com permissões 600. Não pode reiniciar serviços, porque isso requer root. Não pode consultar o banco de dados, porque as credenciais estão em um arquivo que ele não pode abrir.

O ataque ocorreu, mas ficou preso dentro de uma caixa.

Os grupos são o outro eixo

Um usuário pertence a um grupo primário e aos que você adiciona. Os grupos resolvem o caso "várias pessoas precisam da mesma coisa".

$ usermod -aG docker deploy # deploy agora pode usar Docker $ usermod -aG sudo deploy # deploy agora pode usar sudo

Atenção ao "a" nesse comando: sem ela, usermod -G substitui todos os grupos secundários em vez de adicionar. É uma das formas mais rápidas de se remover do grupo sudo e ficar sem poder administrar o servidor.

E um detalhe que surpreende: adicionar alguém ao grupo docker é, na prática, dar acesso root. Quem pode iniciar contêineres pode montar o disco do host dentro de um. Não é uma falha: é assim que o Docker funciona. Vale saber antes de distribuir esse grupo.

Os permissões de um arquivo, lidas de uma vez

$ ls -l .env -rw------- 1 deploy deploy 412 Nov 1 10:22 .env

É lido em blocos de três: o primeiro é o dono, o segundo o grupo, o terceiro todos os outros. rw- para o dono, nada para o resto. Isso é 600.

Os números vêm da soma: leitura 4, escrita 2, execução 1. Então 755 é "o dono pode tudo, o resto pode ler e executar", que é o normal para uma pasta ou um programa. E 600 é "apenas o dono, e nem mesmo pode executá-lo", que é o correto para um arquivo de segredos.

Uma armadilha clássica: nas pastas, o permissão de execução significa "poder entrar". Uma pasta 644 é ilegível mesmo que seus arquivos estejam bem.

Por que isso não é história antiga

Poderia parecer que em um servidor onde você trabalha sozinho tudo isso é desnecessário. É o contrário: é exatamente aí que mais importa, porque não há ninguém mais olhando.

O modelo multiusuário do Linux é a única defesa que já está instalada, não custa nada e funciona mesmo contra ataques que ainda não existem. Aproveitá-lo é, quase sempre, não brigar com ele.

No ArduMaker cada VPS é criado com essa estrutura já pronta: seu usuário com sudo, os serviços com o deles, e root reservado para o que realmente precisa. Os usuários adicionais são criados a partir do painel, com sua chave SSH própria.