Usuários, grupos e permissões no Linux

Todo comando é executado com uma identidade. O Linux usa essa identidade para decidir quais arquivos o comando pode abrir e quais configurações pode alterar. Uma conta de usuário pode representar uma pessoa ou um serviço em execução em segundo plano.

O número por trás do nome

O kernel identifica uma conta por seu identificador de usuário (UID). Nomes como alice facilitam o reconhecimento do número, mas as permissões seguem o número. A conta root tem UID 0 e seu diretório pessoal é /root. Uma conta com outro nome e UID 0 tem o mesmo poder de superusuário.

Um usuário comum é a conta de uso cotidiano de uma pessoa. Na maioria das distribuições, UIDs de usuários comuns começam em 1000; UID_MIN em /etc/login.defs define esse limite. Um usuário comum pode alterar seus próprios arquivos e quaisquer outros que as permissões permitam. Alterar configurações protegidas do sistema exige privilégios elevados.

Uma conta de sistema dá a um serviço sua própria identidade limitada. A maioria tem UIDs abaixo de 1000 e um shell como /usr/sbin/nologin. A conta especial nobody geralmente tem UID 65534, portanto a faixa por si só não identifica todas as contas de serviço. Debian e Ubuntu usam www-data para serviços web; um serviço SSH pode usar sshd.

Consulte sua identidade atual

Execute whoami para ver seu nome de usuário ou id para ver os números e grupos. Por exemplo:

uid=1001(alice) gid=1001(alice) groups=1001(alice),27(sudo),1005(developers)

Leia a saída em três partes. O UID de Alice é 1001. Seu grupo primário é alice, GID 1001. Sua lista de grupos também inclui sudo e developers. Ela é uma usuária comum, não root: o grupo sudo pode autorizar comandos com privilégios elevados, mas seu shell atual continua sendo executado como Alice.

Muitos shells exibem # para root e $ para um usuário comum. Um prompt pode ser personalizado, então consulte id quando a identidade for importante. A primeira conta criada durante a instalação costuma ser uma conta comum com acesso ao sudo, inclusive no Ubuntu; ser criada primeiro não a torna root.

Verifique as sessões de login

Esses comandos respondem a uma pergunta diferente de whoami: eles informam sessões, não apenas a identidade do seu shell. O Debian 13 é um sistema que usa wtmpdb para seu histórico.

Identidades separadas promovem o princípio do menor privilégio, a responsabilização e o isolamento. Um serviço web pode ler os arquivos que fornece sem receber os documentos privados de todos os usuários. Os logs podem mostrar qual conta realizou uma ação. Se o serviço for comprometido, o ataque começa com as permissões dessa conta de serviço. Root pode contornar restrições comuns de leitura e escrita de arquivos, portanto uma segunda conta com UID 0 é uma séria preocupação de segurança.

Compartilhar um arquivo com uma equipe é mais fácil quando ela tem um grupo. Atribua o arquivo a esse grupo, conceda a ele as permissões necessárias e gerencie seus membros conforme as pessoas entram ou saem.

Um grupo primário, participações adicionais

Um grupo tem um nome e um identificador de grupo (GID) numérico. Cada usuário tem um grupo primário, armazenado como GID em /etc/passwd. Um novo arquivo normalmente recebe o grupo primário do processo que o cria. Mais adiante, um diretório com SGID apresentará outra regra para atribuir o grupo de um novo arquivo.

Usuários também podem ter vários grupos suplementares. Essas participações adicionam identidades de grupo aos seus processos; o usuário não precisa trocar de grupo primário sempre que abre o arquivo de outra equipe. Tanto o grupo primário quanto os suplementares contam quando o Linux verifica se o usuário pertence ao grupo de um arquivo.

A maioria das distribuições cria um grupo privado de usuário junto com cada usuário comum. Alice pode ter nome de usuário alice, UID 1001, grupo primário alice e GID 1001. Ainda são identidades separadas de usuário e grupo, mesmo quando seus nomes e números coincidem. Um arquivo atribuído ao grupo privado de Alice não é compartilhado com toda a equipe.

Examine uma participação

Use groups para ver os nomes dos seus próprios grupos. groups bob e id bob consultam os grupos de Bob; id -Gn exibe os nomes dos grupos do processo atual sem números. Uma consulta de grupo pode mostrar:

getent group developers
developers:x:1005:alice,bob

O grupo se chama developers, seu GID é 1005, e Alice e Bob estão listados como integrantes suplementares. Uma conta cujo GID primário é 1005 também pertence ao grupo, mesmo que seu nome esteja ausente dessa lista final. Para verificar todos os grupos de uma pessoa, use id com o nome dela em vez de depender apenas dessa lista.

Aplique as permissões de um grupo

Suponha que plan.txt pertença a bob:developers e tenha o modo rw-r-----. Alice não é Bob, mas pertence a developers. Portanto, ela usa a trinca de permissões do meio, r--: pode ler o plano, mas não alterar seu conteúdo. Chen não é o usuário proprietário nem pertence ao grupo, então usa a última trinca, ---.

Alterar o nome do grupo associado a um arquivo não cria permissões por si só. Se a trinca do grupo for ---, os integrantes ainda não receberão acesso por essa classe. O grupo proprietário identifica a equipe; os bits de permissão especificam o que ela pode fazer.

Reconheça grupos com permissões amplas

Algumas participações concedem muito mais do que acesso a uma pasta de projeto. Debian e Ubuntu geralmente autorizam o grupo sudo para comandos administrativos; Fedora e Red Hat Enterprise Linux geralmente usam wheel. No Debian e no Ubuntu, adm permite acesso a muitos logs do sistema. O grupo docker controla o serviço Docker e, na prática, oferece controle de nível root.

Antes de adicionar alguém a um grupo, identifique o que ele pode acessar. Um grupo de projeto pode ser uma forma restrita de compartilhar trabalho, enquanto um grupo administrativo pode conceder controle sobre toda a máquina.

O Linux mantém os dados públicos das contas separados dos dados de senha. Ler a ordem dos campos ajuda a explicar a identidade, a configuração de login e a política de senha de uma conta sem alterar os arquivos manualmente.

Leia um registro de conta

/etc/passwd tem sete campos separados por dois-pontos:

name:password:UID:GID:comment:home:shell
alice:x:1001:1001:Alice Moreau:/home/alice:/bin/bash

O UID e o GID primário de Alice são ambos 1001. O comentário, também chamado de campo GECOS, informa seu nome completo. Seu diretório pessoal é /home/alice, e seu shell de login é Bash. O x aponta para os dados de senha em /etc/shadow; não significa que sua senha esteja vazia.

Usuários comuns podem ler /etc/passwd, normalmente com modo 644. Programas precisam de seus dados públicos para converter UIDs armazenados em nomes. Manter hashes de senha em um arquivo protegido separado impede que todos os usuários locais os leiam.

Leia os dados de senha

/etc/shadow tem nove campos: nome, hash de senha, dia da última alteração, idade mínima, idade máxima, dias de aviso, dias de inatividade, dia de expiração da conta e um campo reservado. Root pode lê-lo; alguns sistemas também concedem acesso ao grupo shadow.

Um hash de senha é um resultado unidirecional, não uma criptografia reversível. No login, o sistema aplica o método e o sal armazenados à senha informada e compara o resultado com o hash armazenado. Um sal criptográfico aleatório faz os hashes serem diferentes mesmo quando dois usuários escolhem a mesma senha. Registros SHA-512 crypt usam $6$salt$hash, opcionalmente com um campo rounds=N; yescrypt usa $y$parameters$salt$hash.

Um ! inicial bloqueia a senha e mantém o hash. Um campo que contém apenas !, !! ou * não tem senha utilizável. Outros métodos de login, como chaves SSH, ainda podem funcionar com uma senha bloqueada.

Calcule as datas

Considere este registro com hash abreviado:

alice:$y$j9T$...:20514:0:90:7:::

As datas contam os dias desde 1º de janeiro de 1970, UTC. O dia 20514 é 2 de março de 2026. Uma idade mínima de 0 permite a alteração imediata da senha; uma máxima de 90 significa expiração em 31 de maio de 2026. O aviso de sete dias começa em 24 de maio. Campos vazios de inatividade e expiração da conta não definem nenhum desses limites. Um valor de última alteração igual a 0 força uma alteração no próximo login; uma idade máxima de 99999 representa, na prática, uma validade de senha muito longa. A expiração da senha e a expiração da conta são campos separados.

Leia registros de grupo com segurança

/etc/group usa name:password:GID:members. Em developers:x:1005:alice,bob, o último campo lista integrantes suplementares. Integrantes primários são encontrados pelo GID em seus registros passwd. O arquivo protegido /etc/gshadow armazena dados de senha e de administradores de grupos.

Use getent passwd alice ou getent group developers para consultas. getent consulta fontes de contas configuradas, além dos arquivos locais. cut -d: -f1,3 /etc/passwd exibe nomes locais e UIDs. Altere registros com comandos de contas como usermod e passwd; se a edição direta for inevitável, vipw e vigr bloqueiam os arquivos durante a edição.

Tarefas administrativas precisam de mais acesso do que o trabalho cotidiano. Mantenha seu shell habitual na sua própria conta e eleve privilégios para a ação que precisa deles. Arquivos criados por um comando com privilégios elevados podem pertencer a root mesmo quando estão dentro do seu diretório pessoal.

Escolha sudo ou su

Um shell de login carrega o ambiente de login do usuário de destino, incluindo o diretório pessoal e os arquivos de inicialização. Use exit para sair de um shell iniciado por su. sudo -i abre um shell de login de root; sudo -s abre um shell de root. Eles são úteis para uma sequência de tarefas administrativas relacionadas, mas todo comando nesse shell tem privilégios elevados até você sair.

O sudo verifica sua política antes de executar o comando e registra a tentativa. Os logs podem ir para o diário de registros do sistema, /var/log/auth.log em sistemas da família Debian ou /var/log/secure em sistemas da família Red Hat. sudo -l mostra os comandos que sua conta pode executar. A permissão para usar sudo é uma decisão da política, não o resultado de conhecer a senha de outra pessoa.

Entenda a autenticação

Por padrão, o sudo pede a senha do usuário que o invoca, não a de root. A política pode alterar esse comportamento. O registro de autenticação do projeto de origem do sudo dura cinco minutos por padrão; as configurações da distribuição podem usar outro valor, como 15 minutos. O registro normalmente se aplica naquele terminal. Execute sudo -k para invalidá-lo quando terminar.

O Ubuntu normalmente começa sem uma senha de root utilizável e coloca o usuário da instalação em sudo. O Fedora e sistemas da família Red Hat geralmente usam wheel. Uma tentativa negada pode informar que o usuário não está no arquivo sudoers; a tentativa é registrada.

Coloque a operação de escrita sob sudo

Este comando falha quando sua conta comum não pode escrever em /etc/hosts:

sudo echo "192.0.2.10 test.local" >> /etc/hosts

Seu shell atual abre o arquivo para >> antes de o sudo ser executado. Apenas echo recebe permissões de root, e echo não é o programa que abre o destino. Atribua a tarefa de escrita a um processo com privilégios elevados:

echo "192.0.2.10 test.local" | sudo tee -a /etc/hosts

Aqui, tee abre o arquivo protegido como root. Sua opção -a acrescenta ao final; omitir essa opção substituiria o conteúdo do arquivo. Para uma edição interativa, sudoedit /etc/hosts, também escrito como sudo -e /etc/hosts, executa seu editor como você e cuida da atualização do arquivo protegido.

Observe arquivos de trabalho pertencentes a root

Após sudo mkdir ~/project, inspecione o resultado com ls -ld ~/project. O diretório está no seu diretório pessoal, mas foi criado por root. Portanto, suas permissões de proprietário se aplicam a root, enquanto sua conta pode ter apenas acesso de leitura e execução. Restabeleça o proprietário pretendido com sudo chown alice: ~/project quando Alice for a proprietária do projeto. Os dois-pontos finais também selecionam o grupo de login de Alice. A edição e a criação comuns de arquivos podem então ser feitas na conta de Alice.

Uma regra do sudo determina quem pode executar uma ação, em qual sistema hospedeiro e sob qual identidade. Conceder a uma equipe uma ação administrativa pode atender às suas necessidades sem dar controle irrestrito sobre a máquina.

Leia as partes de uma regra

O padrão básico é who where = (as_whom) what. Por exemplo:

alice ALL=(ALL:ALL) ALL
%sudo ALL=(ALL:ALL) ALL

A primeira regra permite que Alice execute qualquer comando em qualquer sistema hospedeiro como qualquer usuário e grupo. A segunda concede as mesmas permissões ao grupo sudo; % indica um nome de grupo. Uma regra comum da família Red Hat é %wheel ALL=(ALL) ALL.

Para tornar Alice administradora com permissões completas por meio de uma regra existente da distribuição, execute sudo usermod -aG sudo alice no Debian ou Ubuntu, ou use wheel no Fedora e em sistemas relacionados. Alice precisa fazer um novo login para que a participação chegue à sua sessão. O -a é importante: sem ele, -G substitui os outros grupos suplementares dela.

Edite e verifique a política

O arquivo principal é /etc/sudoers; regras adicionais podem ficar em /etc/sudoers.d/. Use sudo visudo ou um arquivo específico:

sudo visudo -f /etc/sudoers.d/webteam

O visudo bloqueia o arquivo de política durante a edição e verifica sua sintaxe antes de salvar. Uma política com erros pode impedir que administradores usem sudo. Nomeie o arquivo como webteam, e não webteam.conf: o tratamento de diretórios incluídos do sudo ignora nomes que contêm ponto ou terminam em ~.

Os arquivos no diretório incluído são lidos em ordem de nome. Quando várias regras correspondem, a última regra correspondente controla o resultado; a regra que parece mais específica não necessariamente prevalece. A inclusão normalmente fica perto do fim da política principal, então um arquivo adicional pode afetar uma regra escrita antes.

Conceda uma ação exata

Uma equipe que mantém um serviço web pode receber:

%webteam ALL=(root) /usr/bin/systemctl restart nginx

Um integrante pode executar sudo systemctl restart nginx. A regra especifica o caminho completo do comando e seus argumentos. Ela não autoriza systemctl stop nginx nem bash. Verifique as permissões efetivas com sudo -l; um administrador pode examinar a política de Bob com sudo -l -U bob.

O programa permitido também importa. Um shell de root pode fazer qualquer coisa. Editores e paginadores podem iniciar shells, e cp ou tee sem restrições pode sobrescrever configurações protegidas. Uma lista de comandos aparentemente curta pode, portanto, conceder controle completo.

Decida se uma senha é necessária

NOPASSWD: remove a solicitação de autenticação para um comando correspondente:

backup ALL=(root) NOPASSWD: /usr/local/bin/backup.sh

Isso pode atender a uma tarefa automatizada. O script deve ser controlado por root: se backup puder reescrevê-lo, a conta poderá substituir seu conteúdo por qualquer comando de root. Mantenha a ação permitida restrita e proteja o script.

Linhas Defaults alteram configurações da política. Defaults timestamp_timeout=10 define um registro de autenticação de dez minutos; Defaults logfile=/var/log/sudo.log seleciona um arquivo de log adicional. Essas configurações controlam o comportamento do sudo, enquanto as regras de comandos controlam as ações que ele autoriza.

Criar uma conta configura uma identidade, um ambiente de login e, muitas vezes, um diretório pessoal. Escolher as opções explicitamente torna o resultado previsível entre distribuições.

Crie uma conta comum

Suponha que o grupo developers já exista. Crie a conta de Priya e defina sua senha em dois comandos:

sudo useradd -m -s /bin/bash -c "Priya Shah" -G developers priya
sudo passwd priya

-m cria /home/priya e copia os arquivos iniciais de /etc/skel. -s /bin/bash seleciona Bash como shell de login, e -c fornece o comentário. -G developers adiciona uma participação em grupo suplementar; vários nomes de grupos formam uma lista separada por vírgulas, sem espaços. A conta normalmente também recebe um grupo primário privado.

O primeiro comando adiciona registros de conta a /etc/passwd e /etc/shadow e registros de grupo, conforme necessário, a /etc/group e /etc/gshadow. Seu campo inicial de senha está bloqueado, frequentemente com ! ou !!. A conta existe antes de ter uma senha utilizável. passwd priya define essa senha; sua solicitação mantém a senha fora da linha de comando.

Entenda os padrões das distribuições

useradd é o comando de baixo nível para criação de contas usado nas distribuições Linux. Debian e Ubuntu também fornecem um script interativo adduser que pede dados e cria um diretório pessoal. Em sistemas da família Red Hat, adduser é outro nome para useradd, portanto não oferece o mesmo processo interativo.

Sem opções explícitas, useradd depende dos padrões locais. Os padrões da família Red Hat geralmente criam um diretório pessoal; os do Debian e do Ubuntu não, a menos que -m seja informado. O shell padrão também pode ser diferente. Consulte useradd -D para ver padrões como o diretório base dos diretórios pessoais e o shell. /etc/default/useradd e /etc/login.defs fornecem configurações que incluem faixas de UID, grupos privados e validade de senhas.

Informe outro diretório pessoal ou identidade

Opções úteis descrevem partes distintas da conta:

Um caminho de diretório pessoal no registro não cria o diretório por si só. Combine -d com -m quando o novo diretório pessoal precisar ser criado. No Debian, omitir -m pode deixar uma conta válida sem um diretório pessoal para usar no login.

Para uma identidade de serviço, sudo useradd -r -s /usr/sbin/nologin backupsvc solicita um UID de sistema e um shell não interativo. Contas de sistema não têm diretório pessoal por padrão. O shell nologin impede o login em um shell interativo comum sob essa identidade.

Verifique a configuração

Execute getent passwd priya, id priya e ls -la /home/priya. Verifique o caminho do diretório pessoal, o shell, o grupo primário, os grupos adicionais e os arquivos ocultos copiados. /etc/skel é um modelo: adicionar .bash_aliases ali afeta a criação posterior de diretórios pessoais, não os que já existem. Use nomes de conta simples em letras minúsculas, com algarismos, hífens ou sublinhados após a letra inicial; espaços e nomes incomuns são rejeitados ou tratados incorretamente por muitas ferramentas.

Uma conta pode precisar de uma nova senha, de outro diretório pessoal, de um bloqueio temporário de acesso ou de remoção permanente. Essas operações alteram partes diferentes da conta, portanto identifique o resultado pretendido antes de escolher um comando.

Altere uma senha ou sua validade

Execute passwd para alterar sua própria senha, normalmente após digitar a atual. Um administrador usa sudo passwd priya para definir a senha de Priya sem conhecer a antiga. Verificações de qualidade de senha podem rejeitar escolhas curtas ou simples.

sudo passwd -S priya informa o estado da senha. sudo passwd -l priya bloqueia a senha colocando ! antes de seu hash, e sudo passwd -u priya a desbloqueia. sudo passwd -e priya faz a senha expirar, de modo que o usuário precise escolher outra no próximo login. Fazer uma senha expirar é útil ao fornecer uma senha temporária.

Use sudo chage -l priya para consultar as datas de validade. Por exemplo:

sudo chage -M 90 -m 1 -W 7 priya

A idade máxima é de 90 dias, a mínima entre alterações é de um dia e os avisos começam sete dias antes da expiração. Esses valores vão para /etc/shadow. sudo chage -E 2026-12-31 priya define a data de expiração da conta inteira, separadamente da validade de sua senha.

Bloqueie o acesso sem excluir registros

Um bloqueio de senha impede a autenticação por senha. Ele não remove chaves SSH nem interrompe todos os outros métodos de autenticação. Para desabilitar logins futuros na conta de um usuário que está saindo, bloqueie a senha e defina uma data de expiração da conta no passado, como em sudo usermod -e 1 priya. O valor 1 é uma contagem de dias em janeiro de 1970, portanto essa data já passou. Isso não encerra processos que já estão em execução; eles precisam de atenção separada.

Altere uma conta existente

usermod pode alterar o comentário com -c, o shell com -s e o caminho do diretório pessoal com -d. Combine -d e -m para mover o conteúdo do diretório pessoal, como em sudo usermod -d /data/priya -m priya. -l newname altera o nome de login, mas o diretório pessoal e o grupo privado mantêm seus nomes existentes, a menos que também sejam alterados. -L e -U bloqueiam e desbloqueiam a senha.

Para adicionar uma participação em grupo suplementar, execute sudo usermod -aG developers priya. O -a significa acrescentar. Sem ele, usermod -G developers priya substitui toda a lista de grupos suplementares de Priya; uma participação anterior em sudo pode desaparecer. Seu grupo primário é uma configuração separada, controlada por -g.

Remova a conta e cuide de seus arquivos

sudo userdel priya exclui os registros da conta, mas mantém o diretório pessoal. sudo userdel -r priya também remove o diretório pessoal e a fila de correio. O comando normal se recusa a remover a conta enquanto o usuário ainda tiver processos em execução.

Arquivos em outros locais mantêm o UID numérico do proprietário. Após a exclusão da conta, uma listagem pode mostrar 1003 como proprietário porque nenhum nome corresponde a ele. Reutilizar esse UID para uma nova conta dá a ela a propriedade dos arquivos antigos. Use sudo find / -nouser para localizar arquivos sem usuário correspondente e depois arquive-os ou atribua-os a outro proprietário. Quando alguém sair, bloqueie primeiro os logins futuros, cuide das atividades em execução e preserve os arquivos necessários; depois, exclua a conta quando essas tarefas estiverem concluídas.

Uma pasta compartilhada precisa de um grupo, de membros e de permissões de diretório que permitam a esses membros trabalhar. Após uma alteração de participação em grupo, o banco de dados de contas e os grupos mantidos por um shell já em execução podem divergir temporariamente.

Crie e mantenha o grupo

sudo groupadd developers atribui o próximo GID disponível. Adicione -g 1500 para escolher um GID específico ou -r para criar um grupo de sistema. Verifique com getent group developers; um último campo vazio significa que ainda não há integrantes suplementares listados.

Adicione um membro com qualquer um dos comandos:

sudo usermod -aG developers priya
sudo gpasswd -a priya developers

sudo gpasswd -d priya developers remove essa participação suplementar. sudo gpasswd -M alice,bob developers define toda a lista de membros, substituindo a anterior. Escolha acrescentar, remover ou substituir conforme a alteração pretendida.

Atualize os grupos de uma sessão

Após adicionar Priya, id priya consulta o banco de dados de contas e mostra a nova participação imediatamente. id sem argumentos no shell existente dela informa os grupos que esse shell está realmente usando. Eles foram estabelecidos quando a sessão começou.

Um novo login carrega a nova lista. newgrp developers oferece outra opção: inicia um novo shell com developers como grupo primário. Use exit para sair desse shell. Ao diagnosticar uma operação negada, examine a identidade na sessão que tenta executá-la, não apenas o registro no banco de dados.

Renomeie ou exclua um grupo

sudo groupmod -n devteam developers altera o nome, mas mantém o GID. Os arquivos existentes continuam se referindo ao mesmo grupo numérico. Já sudo groupmod -g 1600 developers altera o número do grupo. Arquivos que ainda contêm o GID antigo 1005 precisam de atenção; localize-os com sudo find / -gid 1005 e depois use chgrp para atribuir o grupo pretendido.

sudo groupdel developers recusa a exclusão se um usuário existente ainda o tiver como grupo primário. Defina outro grupo primário com usermod -g antes de excluí-lo. Excluir um nome de grupo não apaga os arquivos que contêm seu GID anterior.

Configure uma pasta de equipe

Para a equipe web de Priya e Kenji:

sudo groupadd webteam
sudo usermod -aG webteam priya
sudo usermod -aG webteam kenji
sudo mkdir /srv/web
sudo chgrp webteam /srv/web
sudo chmod 2770 /srv/web

Após novos logins, os dois usuários podem criar arquivos em /srv/web. O modo 2770 concede rwx ao proprietário e ao grupo, --- aos outros e define SGID no diretório. Um novo arquivo recebe o grupo webteam, mesmo quando o grupo primário de quem o criou é seu grupo privado. Novos subdiretórios também herdam SGID.

O diretório torna útil a participação na equipe e impede a entrada de outros usuários, mas cada arquivo ainda tem seu próprio modo. Com a solicitação usual de 666 para arquivos, uma umask 002 de quem cria concede escrita ao grupo, enquanto 022 deixa o grupo com acesso somente de leitura. Se integrantes da equipe precisarem editar os arquivos uns dos outros, verifique esses padrões de criação além da pasta.

Uma listagem detalhada coloca em uma linha as informações necessárias para uma decisão de acesso. Leia o proprietário e o grupo junto com os nove bits de permissão; os bits sozinhos não indicam quais permissões uma pessoa específica recebe.

Interprete uma listagem detalhada

-rw-r----- 1 priya developers 2048 Oct 22 09:15 report.txt

O primeiro campo contém o tipo de arquivo e as permissões. Os campos seguintes informam a contagem de links físicos, o usuário proprietário, o grupo proprietário, o tamanho em bytes, a data e hora de modificação e o nome. Esse arquivo comum pertence a Priya e ao grupo developers. O tamanho é de 2048 bytes; a data e hora exibidas registram a última modificação do conteúdo.

O primeiro caractere é - para um arquivo comum, d para um diretório ou l para um link simbólico. Você também pode encontrar c e b para dispositivos de caracteres e de blocos, p para um pipe nomeado e s para um socket.

Divida as nove posições seguintes em três trincas:

Em cada trinca, as posições significam leitura, escrita e execução, nessa ordem. Um traço indica uma permissão ausente, não uma posição vazia a ser pulada na contagem.

Escolha exatamente uma classe

Para uma verificação comum de permissão, o Linux pergunta:

1. O usuário do processo corresponde ao proprietário do arquivo? Use a trinca do proprietário.
2. Caso contrário, um de seus grupos corresponde ao grupo do arquivo? Use a trinca do grupo.
3. Caso contrário, use a trinca dos outros.

As classes não são somadas. Suponha que Priya seja proprietária de um arquivo cuja sequência completa de tipo e modo seja ----rw-rw-. Sua trinca de proprietário é ---, então ela não pode lê-lo por meio dos bits comuns, embora grupo e outros tenham rw-. Como proprietária, ela pode alterar o modo. Uma trinca menos restritiva de grupo ou outros não substitui a trinca selecionada do proprietário.

Root pode contornar as verificações comuns de permissão de leitura e escrita. Para executar um arquivo de programa comum, até root precisa de pelo menos um bit de execução nele. Portanto, uma verificação de modo precisa considerar tanto a identidade do usuário quanto a operação tentada.

Examine diretórios e números

ls -ld /srv/web lista o próprio diretório. Sem -d, ls -l /srv/web normalmente lista as entradas dentro dele, o que pode desviar sua atenção de uma restrição no diretório. ls -a inclui nomes ocultos, enquanto ls -n exibe proprietários e grupos numéricos. Arquivos armazenam UIDs e GIDs; se uma conta ou grupo tiver sido excluído, uma listagem comum também poderá mostrar o número restante.

Para um relatório compacto, execute:

stat -c '%A %a %U %G %n' report.txt

Ele pode mostrar -rw-r----- 640 priya developers report.txt, colocando letras e dígitos octais lado a lado. Um + após as letras indica entradas adicionais de lista de controle de acesso. Um link simbólico geralmente aparece como lrwxrwxrwx; o Linux usa as permissões do destino para determinar o acesso, não esses bits exibidos do link.

Leitura, escrita e execução descrevem ações diferentes em arquivos e diretórios. Um diretório armazena nomes que levam a arquivos, portanto alterar o conteúdo de um arquivo e remover seu nome são verificações de permissão diferentes.

Relacione o bit ao objeto

Um arquivo com permissão de escrita, mas sem permissão de leitura, pode receber conteúdo ao final sem ser lido. Por exemplo, um shell pode abrir um log com permissão de escrita para echo text >> log.txt mesmo quando cat log.txt falha. Um editor frequentemente precisa de leitura e escrita porque primeiro carrega o conteúdo existente.

Um script executado como ./backup.sh precisa de permissão de execução e deve ser legível por seu interpretador. Se o script for legível, mas não tiver execução, bash backup.sh ainda poderá lê-lo e executá-lo: Bash é o programa executável nesse comando.

Separe listagem de busca

A permissão de leitura de diretório permite ver nomes. A execução de diretório, também chamada de permissão de busca, permite acessar uma entrada pelo nome. Com leitura, mas sem execução, ls pode mostrar nomes, enquanto ls -l não consegue obter seus detalhes e pode exibir erros e pontos de interrogação. Você não pode abrir os arquivos nomeados por esse diretório.

Com execução, mas sem leitura, o inverso é possível: você pode acessar notes.txt se já souber seu nome exato, mas não pode listar o diretório para descobrir os nomes. O próprio modo do arquivo ainda deve permitir o acesso solicitado.

Examine todo o caminho

Para ler /home/priya/notes/public.txt, Kenji precisa de permissão de execução em todos os diretórios do caminho e permissão de leitura no arquivo. Se /home/priya tiver modo 700, sua trinca dos outros será ---; Kenji para ali mesmo que public.txt tenha modo 644. Acrescentar mais permissão de leitura ao arquivo não corrige a falta de um bit de busca em um diretório acima dele.

Use ls -ld /home/priya /home/priya/notes para examinar os próprios diretórios. Em cada nível, escolha a classe que se aplica a Kenji e verifique seu bit de execução. A classe relevante pode mudar de um diretório para outro porque seus proprietários e grupos podem ser diferentes.

Preveja exclusões e renomeações

Excluir um arquivo remove uma entrada de diretório. Kenji precisa de escrita e execução no diretório que o contém, não de escrita no arquivo. Em um diretório comum com permissão de escrita e sem sticky bit, ele pode remover o arquivo somente de leitura de Priya. Por outro lado, ser proprietário de um arquivo não permite que ele o exclua de um diretório onde não tem permissão de escrita.

Portanto, remover a escrita do arquivo é útil para proteger o conteúdo contra edições, mas não protege o nome contra remoção. O sticky bit de um diretório acrescenta uma restrição de propriedade à exclusão e à renomeação em pastas compartilhadas com permissão de escrita. O acesso ao arquivo e o acesso à entrada de diretório respondem a perguntas diferentes.

Use chmod para alterar as permissões de um arquivo ou diretório do qual você é proprietário. Root também pode alterá-las. Ter acesso de escrita por meio de um grupo permite alterar o conteúdo do arquivo, mas não torna você proprietário nem permite definir seu modo.

Faça uma alteração simbólica específica

Um modo simbólico tem uma classe, um operador e bits. As classes são u para proprietário, g para grupo, o para outros e a para as três. + adiciona permissões, - as remove e = define exatamente as permissões dessa classe.

chmod u+x deploy.sh
chmod go-w notes.txt
chmod u=rw,g=r,o= report.txt

O primeiro comando adiciona apenas o bit de execução do proprietário. O segundo remove a escrita do grupo e dos outros, mantendo seus demais bits. O terceiro concede leitura e escrita ao proprietário, leitura ao grupo e nenhuma permissão aos outros: rw-r-----.

Especifique a classe quando quiser uma alteração precisa. Se você a omitir, como em chmod +w notes.txt, a umask restringirá quais bits de classe serão afetados. Com umask 022, esse comando adiciona escrita somente para o proprietário; chmod a+w notes.txt inclui explicitamente as três classes.

Converta cada trinca em um dígito octal

Leitura tem valor 4, escrita 2 e execução 1. Some os valores presentes em cada classe:

Para rw-r-----, divida em rw-, r--, ---: os dígitos são 6, 4, 0. chmod 640 report.txt define esses nove bits comuns, independentemente do modo comum anterior. Inverta o processo para 750: 7 fornece rwx, 5 fornece r-x e 0 fornece ---, formando rwxr-x---.

Escolha um modo final útil

O modo 600 mantém um arquivo privado para seu proprietário. O modo 644 permite que outros usuários leiam um arquivo comum. O modo 664 também permite que o grupo edite. Diretórios privados geralmente usam 700, diretórios legíveis pelo grupo usam 750 e diretórios nos quais o grupo pode escrever usam 770. Programas ou diretórios públicos geralmente usam 755.

Os mesmos dígitos permitem ações úteis diferentes em objetos diferentes. Aplicar 644 a um diretório remove a execução de todas as classes. Nem mesmo seu proprietário pode mais entrar nele ou abrir arquivos por meio dele. Use um modo de diretório com permissão de busca para as pessoas que precisam de acesso.

Aplique alterações a uma árvore

chmod -R 755 site/ também torna todos os arquivos comuns executáveis. Para uma árvore que contém diretórios e documentos comuns, use a execução condicional:

chmod -R u=rwX,go=rX site/

O X maiúsculo adiciona execução a diretórios e a arquivos que já têm um bit de execução. Arquivos não executáveis passam a ter 644; diretórios passam a ter 755. Arquivos executáveis existentes mantêm o acesso de execução. Isso mantém o percurso possível sem marcar todo documento como programa. Os bits especiais são separados: o GNU chmod preserva SUID e SGID de diretórios, a menos que você os limpe explicitamente, por exemplo com chmod g-s site/.

O proprietário e o grupo identificam o usuário e o grupo cujas trincas de permissão serão verificadas. Atribuí-los corretamente pode corrigir uma pasta de trabalho criada acidentalmente com sudo, sem conceder acesso mais amplo a todos os outros.

Leia as formas de chown

chown pode alterar um usuário, um grupo ou ambos:

Identificadores numéricos também funcionam, como em sudo chown 1002:1005 report.txt. Os nomes são resolvidos em números; o arquivo armazena esses números.

Somente root pode transferir um arquivo para outro usuário proprietário. Um proprietário pode alterar o grupo de seu próprio arquivo para um grupo ao qual pertence. Assim, Priya pode usar chgrp webteam plan.txt se for proprietária do arquivo e pertencer a webteam. Para atribuí-lo a finance, ela também precisaria pertencer a esse grupo. A capacidade de outro integrante de editar o arquivo não concede a capacidade de alterar seu proprietário ou modo.

Corrija uma pasta criada acidentalmente como propriedade de root

Kenji executou um comando de criação com sudo. A listagem é:

drwxr-xr-x 2 root root 4096 Oct 22 10:02 /home/kenji/app

Ele não é o proprietário nem está usando o grupo proprietário, então recebe o r-x dos outros. Ele pode inspecionar a pasta e entrar nela, mas não pode criar entradas porque falta escrita. Tornar a pasta gravável por todos concederia mais acesso do que o projeto dele precisa.

Se o projeto pertence a Kenji, sudo chown -R kenji: ~/app restabelece sua propriedade e seu grupo de login em todo o projeto. Sua trinca de proprietário agora é rwx, então ele pode criar arquivos. Inspecione o caminho de destino antes de qualquer comando recursivo de alteração de propriedade: aplicá-lo a /etc ou /usr pode prejudicar o funcionamento do sistema. -R significa o diretório e tudo abaixo dele.

Preveja a propriedade após operações com arquivos

Um arquivo recém-criado pertence ao usuário do processo que o cria. Seu grupo normalmente vem do grupo primário desse processo ou de um diretório pai com SGID. Portanto, criar uma nova cópia comum com cp torna quem executa o comando seu proprietário. Um mv dentro do mesmo sistema de arquivos altera o local de um arquivo existente e mantém seu proprietário e grupo. Opções de cópia que preservam a propriedade têm um comportamento diferente do de uma nova cópia comum.

Essa distinção explica por que mover um arquivo antigo para uma pasta compartilhada não aplica a ele a regra de herança de grupo dessa pasta. SGID se aplica na criação; use chgrp quando o grupo de um arquivo existente precisar ser alterado.

Combine identidade e acesso

Atribuir webteam com chgrp seleciona quem a classe de grupo representa. Isso não adiciona leitura ou escrita ao grupo. Use chmod para conceder os bits necessários após escolher o grupo. Alterar o proprietário ou o grupo de um executável também pode limpar privilégios SUID ou SGID; examine o modo resultante quando esses bits forem importantes.

As permissões de um novo arquivo vêm de duas entradas: o modo solicitado pelo programa que o cria e a umask do processo. A máscara remove bits solicitados; ela nunca adiciona permissões que o programa não pediu.

Comece pela solicitação de criação

Editores e redirecionamento do shell geralmente solicitam 666, ou rw-rw-rw-, para novos arquivos comuns. A criação de diretórios geralmente solicita 777, ou rwxrwxrwx. Uma umask é um conjunto de bits a limpar dessa solicitação. Um bit permanece somente quando a solicitação o inclui e a máscara não.

Para umask 022, mantenha todos os bits solicitados do proprietário, remova a escrita do grupo e remova a escrita dos outros. Um arquivo passa a ter 644; um diretório passa a ter 755. Leia cada dígito como bits, não como uma quantidade decimal comum.

Com 027, o grupo perde escrita enquanto os outros perdem os três bits. Ela é útil quando uma equipe deve ler novos arquivos, mas usuários fora da equipe não devem ter acesso. Com 002, a escrita do grupo continua disponível; o grupo proprietário do arquivo ainda determina quem a recebe.

Por que a subtração falha

Considere a solicitação de arquivo 666 e a máscara 033. Cada 3 significa escrita mais execução. Mas cada trinca solicitada para o arquivo é rw-: a execução já está ausente. Limpar escrita e execução deixa r-- para grupo e outros, então o resultado é 644. Subtrair os dígitos produziria 633, sugerindo incorretamente que bits de execução podem aparecer.

Para uma solicitação de diretório de 777, limpar esses mesmos bits produz 744. Esse diretório não tem execução para grupo e outros, então essas classes não podem acessar suas entradas, mesmo podendo listar os nomes. Uma máscara que produz o modo de arquivo desejado pode produzir um resultado inconveniente para diretórios.

Consulte e defina sua máscara

Execute umask para ver a configuração atual, frequentemente exibida com um zero inicial, como 0022. O zero inicial é formatação; o Linux usa os nove bits comuns de permissão. umask -S exibe os bits permitidos, como u=rwx,g=rx,o=rx para 022; um programa pode solicitar um subconjunto desses bits.

umask 027 altera o shell atual e é herdado pelos programas iniciados por ele. Arquivos existentes mantêm seus modos. Use chmod quando um arquivo já criado precisar de permissões diferentes.

Escolha um padrão persistente

Uma linha como umask 027 em ~/.profile ou ~/.bashrc pode definir o valor para os shells que leem esse arquivo de inicialização. Os padrões do sistema podem vir de /etc/profile ou de UMASK em /etc/login.defs. A distribuição e a configuração da conta determinam quais arquivos são lidos e quando.

Muitos sistemas usam 022, enquanto configurações com grupos privados frequentemente usam 002 para usuários comuns. Um compilador pode solicitar saída executável com modo 777; sob 022, ela passa a ter 755. A solicitação 666 de um editor de texto não tem bits de execução, então escrever um script não o torna executável por si só.

Três bits especiais acrescentam comportamentos além das permissões comuns de proprietário, grupo e outros. Seu significado depende de o objeto ser um programa ou um diretório.

Reconheça o dígito adicional

Um dígito octal inicial combina SUID 4, SGID 2 e sticky 1. O modo 4755 é SUID mais o modo comum 755. O modo 2770 é SGID mais 770. O modo 3770 combina SGID e sticky porque 2 mais 1 é 3.

Em uma listagem detalhada, os bits compartilham as posições de execução. Um s minúsculo na posição do proprietário significa SUID e execução para o proprietário; um s minúsculo na posição do grupo significa SGID e execução para o grupo. Um t minúsculo na posição dos outros significa sticky e execução para os outros. Um S ou T maiúsculo significa que o bit especial está presente, mas a execução nessa posição está ausente.

SUID e SGID em programas

O SUID permite que um executável seja executado com a identidade efetiva do proprietário do arquivo. /usr/bin/passwd geralmente aparece como -rwsr-xr-x root root: o programa pode atualizar dados protegidos de senha enquanto controla qual senha de usuário quem o invocou pode alterar. Iniciá-lo não dá a essa pessoa um shell de root. O Linux ignora SUID em scripts e diretórios.

O SGID em um executável usa, de forma semelhante, a identidade de grupo do arquivo. Esses bits concedem acesso controlado pelo programa, portanto o comportamento do programa importa. Nunca adicione SUID a um shell, editor ou script. Um administrador pode listar arquivos comuns com SUID usando sudo find / -perm -4000 -type f 2>/dev/null; use -perm -2000 para arquivos SGID e compare os resultados com a configuração esperada do sistema.

SGID em um diretório de equipe

Em um diretório, SGID faz com que novas entradas recebam o grupo do diretório, e novos subdiretórios herdem SGID. Suponha que /srv/web pertença a root:webteam, com modo 2770, exibido como drwxrws---. Priya tem um grupo primário privado, mas pertence a webteam. Quando ela cria index.html nesse diretório, seu grupo passa a ser webteam.

Seu modo comum ainda depende da criação. Com uma solicitação de arquivo de 666 e umask 002, ele passa a ter 664 e Kenji, outro integrante da equipe, pode editá-lo. Com 022, passa a ter 644, então Kenji tem apenas acesso de leitura. SGID fornece o grupo, não um bit adicional de escrita.

Diretórios com sticky bit e exclusão

O sticky bit restringe a exclusão e a renomeação: com o acesso necessário ao diretório, uma entrada pode ser removida pelo proprietário do arquivo, pelo proprietário do diretório ou por root. Isso torna úteis os diretórios compartilhados com permissão de escrita sem permitir que usuários removam as entradas uns dos outros. /tmp e /var/tmp geralmente usam 1777, exibido como drwxrwxrwt. O sticky bit não impede edições no conteúdo do arquivo quando seu modo as permite. O Linux o ignora em arquivos comuns.

Defina bits com chmod u+s prog, chmod g+s /srv/web ou chmod o+t /srv/drop. Limpe-os com u-s, g-s ou o-t. Com GNU chmod, chmod 755 /srv/web preserva um bit SGID existente no diretório; use chmod g-s /srv/web para limpá-lo explicitamente.

Um erro “Permission denied” identifica uma operação que falhou, não necessariamente um modo de arquivo incorreto. O bloqueio pode estar nos grupos da sua sessão, em um diretório pai, no próprio arquivo ou na propriedade deixada por um comando com privilégios elevados.

Examine identidade, caminho, classe e operação

Comece com id sem argumentos na sessão afetada. Se um grupo foi adicionado recentemente, compare a lista ativa com id username, que consulta o banco de dados. Um novo login pode carregar a nova participação.

Em seguida, examine todo o caminho:

namei -l /srv/reports/q3.txt

namei -l informa proprietários, grupos e modos ao longo do caminho. Você também pode examinar cada diretório com ls -ld. Em cada objeto, selecione a primeira classe correspondente: proprietário, caso contrário grupo, caso contrário outros. Depois pergunte do que a operação tentada precisa. A leitura exige r no arquivo e permissão de busca em todos os diretórios pais. Criar, remover ou renomear uma entrada exige w e x em seu diretório, com restrições do sticky bit onde ele estiver presente.

Encontre a primeira operação bloqueada

Kenji pertence a finance e tenta executar cat /srv/reports/q3.txt. Os objetos relevantes são:

drwxr-xr-x root  root     /srv
drwxr-x--- root  finance  /srv/reports
-rw------- maria finance  /srv/reports/q3.txt

Kenji pode atravessar /srv usando a execução dos outros. Em /srv/reports, sua participação em finance seleciona o r-x do grupo, então ele também pode atravessá-lo. Em q3.txt, ele não é Maria, e a trinca de finance é ---. A permissão ausente é a leitura do arquivo para o grupo.

Se integrantes de finance devem ler o relatório, Maria ou root pode executar chmod g+r /srv/reports/q3.txt. O modo resultante é 640. Ele fornece a permissão ausente sem dar escrita ao grupo nem abrir o relatório aos outros. Um administrador pode testar com sudo -u kenji cat /srv/reports/q3.txt, executando o comando como Kenji em vez de testá-lo como root.

Escolha a menor correção

Uma correção adequada pode ser adicionar uma participação em equipe, definir leitura para o grupo, restabelecer o proprietário de um projeto ou adicionar busca no diretório para a classe pretendida. chmod -R 777 concede a todas as contas locais acesso de escrita em toda a árvore e torna arquivos comuns executáveis. Ele também não consegue resolver todas as causas de falha de acesso.

Verifique causas comuns antes de editar uma árvore grande: nova participação ainda inativa, x ausente em um diretório pai, arquivos de trabalho pertencentes a root criados com sudo e novos arquivos cuja umask removeu o acesso necessário à equipe. Unidades FAT32 e exFAT não armazenam UIDs, GIDs e modos nativos do Linux; as opções de montagem fornecem esses valores, então chmod ou chown por arquivo pode falhar ou não ter efeito.

Mantenha dados privados protegidos

Uma chave privada SSH como ~/.ssh/id_ed25519 normalmente deve ter modo 600; seu diretório .ssh geralmente tem 700. O SSH verifica a proteção da chave privada e pode rejeitar uma chave excessivamente acessível. /etc/shadow continua inacessível a usuários comuns. Administradores com sudo completo podem contornar a privacidade comum dos arquivos, portanto mantenha esse grupo pequeno e conceda ações específicas quando a administração completa for desnecessária.