Usuários, grupos, permissões, ACLs e menor privilégio

Uma conta não acessa arquivos diretamente

Quando alguém abre um arquivo, inicia um programa ou consulta um diretório, o sistema operacional não decide apenas pelo nome digitado no login. A operação parte de um processo, e esse processo carrega credenciais: identificadores de usuário, grupos e, conforme a plataforma, privilégios ou capacidades adicionais. O kernel combina esse contexto com o objeto e com a operação solicitada para permitir ou negar o acesso.

Essa distinção corrige uma simplificação comum. Usuário é uma identidade registrada; grupo reúne identidades para administrar acessos recorrentes; processo é a entidade em execução que apresenta credenciais ao kernel; permissão descreve operações autorizadas sobre um objeto. Esses elementos se relacionam, mas não são intercambiáveis.

A aula sobre processos e contexto de execução mostrou que um programa em execução possui estado próprio. Aqui acrescentamos a identidade de segurança a esse contexto. Já os princípios organizacionais, a revisão de acessos e os modelos RBAC e ABAC permanecem na página canônica de controle de acesso e menor privilégio.

Identificar, autenticar e autorizar são decisões distintas

Uma sequência de acesso costuma envolver três perguntas:

Um login bem-sucedido não concede acesso irrestrito. Ele permite estabelecer um contexto autenticado; cada operação protegida ainda precisa ser autorizada. Da mesma forma, alterar o nome visível de uma conta não deveria trocar a identidade interna usada nas decisões.

Sistemas usam identificadores estáveis porque nomes são convenientes para pessoas, mas podem mudar ou ser reutilizados. Em sistemas Unix-like, contas e grupos são associados a números como UID e GID. No Windows, entidades de segurança são identificadas por SIDs. Interfaces traduzem esses valores para nomes legíveis, enquanto os mecanismos de segurança trabalham com as identidades internas.

Usuários e grupos organizam identidades locais

Uma conta de usuário pode representar uma pessoa, um serviço ou outra finalidade técnica. Nem toda conta precisa aceitar sessão interativa. Um serviço de banco de dados, por exemplo, pode executar com identidade própria justamente para não compartilhar os arquivos e poderes da pessoa que instalou o software.

Grupos reduzem a necessidade de conceder o mesmo acesso individualmente. Em vez de manter dez permissões diretas sobre uma pasta de projeto, pode-se atribuir o acesso a um grupo e administrar a participação das pessoas nesse grupo. A facilidade não elimina o cuidado: grupos muito amplos, aninhamentos difíceis de explicar e participações antigas continuam produzindo privilégios excessivos.

No modelo Unix, um processo possui UID e GID reais, IDs efetivos e uma lista de grupos suplementares. Em termos introdutórios:

• o ID real preserva a identidade de origem da execução;
• o ID efetivo costuma participar das verificações de permissão;
• IDs salvos permitem que programas específicos alternem privilégios sob regras controladas;
• grupos suplementares acrescentam associações além do grupo principal.

Essas diferenças existem para permitir transições controladas, não para que aplicações escolham livremente qualquer identidade. Chamadas que alteram credenciais são submetidas às regras do kernel. Em programas multithread, a biblioteca e o sistema também precisam preservar a visão coerente das credenciais esperada pelo modelo da plataforma.

No Windows, um processo normalmente possui um access token primário. O token reúne o SID do usuário, SIDs de grupos, privilégios e outros atributos usados nas decisões. Uma thread que representa temporariamente outro contexto pode usar um token de impersonação. Portanto, “qual usuário iniciou o programa?” nem sempre basta; é preciso saber qual token participa daquela operação.

Propriedade e modo formam a base Unix

Um arquivo Unix possui um proprietário, um grupo proprietário e bits de modo. Os nove bits mais conhecidos aparecem em três conjuntos: dono, grupo e outros. Cada conjunto pode conter leitura (r), escrita (w) e execução ou busca (x). Uma representação como -rw-r----- indica:

• -: objeto do tipo arquivo regular;
• rw-: o proprietário pode ler e escrever;
• r--: processos enquadrados na classe de grupo podem ler;
• ---: a classe de outros não recebe essas permissões.

Os valores octais surgem da soma r = 4, w = 2 e x = 1 em cada classe. Assim, 640 representa rw-r-----; 755 representa rwxr-xr-x. A notação é compacta, mas não substitui a pergunta importante: qual credencial cai em qual classe para esta operação?

No algoritmo tradicional, se o UID efetivo corresponde ao proprietário, usa-se a classe do dono; não se tenta depois obter uma combinação mais favorável pelo grupo. Se não corresponde, os grupos são comparados; caso nenhum se aplique, vale a classe de outros. ACLs estendem esse processo, como veremos adiante.

O proprietário não é automaticamente um “administrador do sistema”. Ele normalmente pode alterar o modo de seu objeto, mas outras operações dependem da plataforma, do sistema de arquivos, das capacidades do processo e de políticas adicionais. Também não é seguro concluir que UID zero ignora absolutamente todo controle: capacidades, mecanismos de segurança mandatória, montagem, imutabilidade e namespaces podem acrescentar limites.

r, w e x mudam de significado em diretórios

As letras são iguais, mas o objeto protegido muda:

Isso produz combinações menos intuitivas. Com busca (x) sem leitura (r) em um diretório, um processo pode alcançar um nome conhecido, se também tiver as permissões necessárias nos componentes seguintes, mas não listar livremente os nomes. Com leitura sem busca, pode enxergar nomes e ainda não conseguir abrir seus destinos pelo caminho.

Remover um arquivo altera uma entrada do diretório. Por isso, ter escrita no arquivo não é o critério central para excluí-lo; as permissões e regras do diretório pai participam. O sticky bit, comum em diretórios compartilhados como áreas temporárias, restringe remoção e renomeação para evitar que qualquer participante apague entradas de outros apenas por possuir escrita no diretório.

A resolução completa também exige busca em cada diretório do caminho. Se /projetos/equipe/relatorio está acessível no último componente, mas o processo não consegue atravessar /projetos, a operação falha antes de alcançá-lo. A aula de arquivos, diretórios, metadados e links aprofunda como o caminho é resolvido.

umask filtra permissões no momento da criação

A umask é uma máscara do processo usada quando uma operação cria um objeto. De forma simplificada, os bits indicados pela máscara são retirados do modo solicitado pela aplicação. Ela não percorre arquivos antigos, não redefine permissões a cada abertura e não “protege a conta inteira”.

Um programa que solicita 0666 para um arquivo sob umask 0022 obtém os bits tradicionais 0644:

modo solicitado:  0666  rw-rw-rw-
umask:             0022  ----w--w-
resultado básico:  0644  rw-r--r--

Para diretórios, uma solicitação comum é 0777; com a mesma máscara, o resultado básico é 0755. A máscara não inventa execução em um arquivo que a aplicação criou sem esse bit. ACL padrão no diretório e detalhes da chamada de criação também podem influenciar o resultado, por isso a conta acima é um modelo da camada tradicional, não uma promessa universal sobre todo sistema de arquivos.

Permissões iniciais seguras devem nascer da necessidade. Criar um segredo amplamente legível e tentar corrigi-lo depois abre uma janela de exposição. A aplicação pode solicitar um modo restritivo desde o início, usar criação exclusiva quando necessário e só então publicar ou compartilhar o objeto conforme um fluxo controlado.

Bits especiais resolvem casos específicos

Além dos nove bits, sistemas Unix-like possuem bits especiais:

• set-user-ID em executável: pode fazer a execução adquirir o UID efetivo do proprietário do arquivo;
• set-group-ID em executável: pode atribuir o GID efetivo associado ao arquivo;
• set-group-ID em diretório: frequentemente faz novos objetos herdarem o grupo do diretório, útil em áreas colaborativas;
• sticky em diretório: limita remoção ou renomeação de entradas em diretórios graváveis por várias identidades.

Setuid e setgid em executáveis são mecanismos sensíveis: um erro no programa pode ser explorado com os privilégios adquiridos. Sistemas de arquivos, opções de montagem, interpretadores e políticas podem restringir ou ignorar seu efeito. Eles não devem ser usados como atalho para evitar um desenho de privilégios adequado.

ACLs adicionam usuários e grupos nomeados

Os conjuntos dono, grupo e outros são simples, mas nem sempre expressam uma colaboração real. Uma ACL de acesso em Linux pode acrescentar entradas para usuários e grupos específicos. Um diretório também pode possuir uma ACL padrão, usada para derivar ACLs iniciais dos objetos criados dentro dele.

Uma forma textual ilustrativa é:

user::rwx
user:ana:rw-
group::r--
group:revisores:r-x
mask::r-x
other::---

A entrada user:: representa o proprietário. Entradas com nome qualificam identidades adicionais. A mask limita o máximo efetivo das entradas de usuários nomeados, do grupo proprietário e de grupos nomeados; ela não limita a entrada do proprietário nem other. No exemplo, ana aparenta ter rw-, mas a máscara r-x retira a escrita efetiva, resultando em leitura.

Isso explica por que olhar apenas os bits impressos sem inspecionar a ACL pode enganar. No modelo Linux descrito por acl(5), bits de modo e entradas básicas da ACL mantêm correspondência; executar chmod pode recalcular ou alterar a máscara e, consequentemente, as permissões efetivas de entradas nomeadas.

ACL não significa “a entrada mais específica sempre vence” nem “permissões de todos os grupos são somadas sem limite”. O algoritmo primeiro verifica o proprietário, depois um usuário nomeado correspondente, depois os grupos aplicáveis sob a máscara, e por fim other. Se a classe correspondente não concede tudo o que foi solicitado, o acesso é negado; a avaliação não caça outra classe mais permissiva.

Também é importante distinguir ACLs de plataformas diferentes. ACL é uma família de mecanismos, não um único formato portátil. Copiar arquivos entre sistemas, compactar, restaurar ou montar com opções diferentes pode não preservar todos os metadados. O procedimento precisa verificar suporte e resultado, não apenas assumir equivalência pelo nome.

Windows usa SIDs, tokens e descritores de segurança

No Windows, um objeto protegível possui um descritor de segurança. A DACL desse descritor contém ACEs que permitem ou negam direitos a trustees identificados por SIDs. Quando uma thread solicita acesso, o sistema compara as ACEs aplicáveis com os SIDs e atributos presentes no token usado pela thread.

Três cuidados evitam analogias erradas com rwx:

1. direitos dependem do tipo de objeto e podem ser mais granulares que ler, escrever e executar;
2. ACEs podem permitir ou negar direitos, e sua ordem é relevante para a avaliação;
3. ausência de DACL e DACL vazia têm resultados opostos: a primeira permite acesso amplo; a segunda não contém concessões e nega o acesso.

Ferramentas e APIs devem manter uma ordem canônica das ACEs. Dizer apenas que “negação sempre vence” é insuficiente, porque o algoritmo percorre a lista até negar um direito solicitado, conceder todos os direitos pedidos ou terminar com algum direito ainda não concedido. Herança, identidade proprietária, privilégios e integridade também podem participar conforme a operação.

Uma SACL não é a lista que concede acesso: ela define quais tentativas devem gerar auditoria. Concessão e registro são responsabilidades relacionadas, porém diferentes. Registrar tudo sem finalidade pode gerar ruído e dados sensíveis; registrar pouco demais impede reconstruir ações de alto impacto.

Menor privilégio é menor poder suficiente

O NIST resume menor privilégio como limitar recursos e autorizações ao mínimo necessário para a função. No sistema operacional, isso pode ser traduzido em perguntas concretas:

• qual identidade deve executar este serviço?
• quais caminhos e operações ele realmente usa?
• precisa de administração permanente ou apenas de uma operação elevada?
• o privilégio pode ser dividido em uma capacidade mais estreita?
• quando a necessidade termina e como a concessão será revogada?

Executar tudo como root ou administrador simplifica o primeiro teste, mas amplia qualquer erro, comprometimento ou comando equivocado. Uma conta de serviço dedicada, arquivos com propriedade adequada e permissões restritas criam limites úteis mesmo quando a aplicação apresenta uma falha.

No Linux, capabilities dividem parte dos poderes tradicionalmente associados ao superusuário em unidades. CAP_NET_BIND_SERVICE, por exemplo, permite vincular portas privilegiadas sem entregar todo o conjunto de poderes de UID zero. Isso melhora a granularidade, mas uma capability continua sendo privilégio e pode ter escopo amplo; CAP_SYS_ADMIN concentra tantas operações que não funciona como uma permissão estreita na prática.

Elevação temporária também não deve significar executar uma sessão inteira com poder máximo. Prefira autorizar uma tarefa definida, separar conta cotidiana de contexto administrativo, limitar duração e preservar registro. Em emergência, procedimentos de acesso excepcional precisam ser possíveis, mas controlados e revisados depois.

Verificar antes e usar depois pode criar uma corrida

Uma aplicação pode tentar perguntar “tenho acesso?” e só depois abrir o arquivo. Entre a verificação e o uso, outro processo pode trocar um componente do caminho ou alterar o objeto: é a classe de falhas time of check to time of use, ou TOCTOU.

No Linux, access() verifica acessibilidade com IDs reais por um propósito específico e não deve ser tratado como autorização antecipada universal. Quando a aplicação pretende realizar a operação, normalmente é mais seguro solicitar diretamente open(), rename() ou outra chamada apropriada e tratar o resultado. Interfaces baseadas em descritores e caminhos relativos a diretórios já abertos ajudam a reduzir ambiguidades conforme o caso.

O princípio geral é: a verificação de segurança deve ficar o mais próxima possível da operação protegida e usar o mesmo objeto e contexto. Uma validação duplicada na interface não substitui a decisão do kernel.

Observe credenciais e ACLs sem modificá-las

No Linux, uma primeira inspeção somente de leitura pode usar:

id
umask
stat -c 'tipo=%F dono=%U(%u) grupo=%G(%g) modo=%A(%a)' -- caminho
namei -l -- caminho
getfacl --absolute-names -- caminho

id mostra IDs e grupos do contexto atual; umask exibe a máscara do shell; stat consulta metadados; namei -l percorre os componentes; getfacl mostra entradas e permissões efetivas quando a ferramenta e o sistema suportam ACLs. Não publique saídas sem revisar nomes de usuários, caminhos e dados internos.

Para observar credenciais do próprio processo no Linux:

grep -E '^(Uid|Gid|Groups|Cap(Inh|Prm|Eff|Bnd|Amb)):' /proc/self/status

Os valores de capabilities aparecem como máscaras e exigem uma ferramenta ou documentação correspondente para interpretação. Ausência de uma capability não prova ausência de todo privilégio; outros mecanismos ainda podem existir.

No Windows, comandos de leitura incluem:

whoami /user
whoami /groups
whoami /priv
Get-Acl -LiteralPath 'C:\caminho' | Format-List Owner,AccessToString

Essas saídas mostram partes do contexto e da ACL, não uma prova isolada de que toda operação será aceita. Compartilhamentos, políticas, herança, token efetivo, integridade e o próprio tipo de objeto podem adicionar condições. Faça o diagnóstico sobre a operação real e preserve evidências antes de alterar permissões.

Um roteiro seguro para investigar acesso negado

1. registre a operação exata, o caminho e a mensagem de erro;
2. confirme qual processo e qual credencial efetiva fizeram o pedido;
3. resolva todos os componentes do caminho, links e pontos de montagem;
4. inspecione proprietário, grupo, modo, ACL e permissões efetivas;
5. verifique políticas adicionais, opções de montagem e confinamento;
6. compare com a necessidade legítima, sem conceder acesso amplo “para testar”;
7. reproduza com o menor caso seguro e documente a causa;
8. planeje mudança, validação e reversão antes de modificar propriedade ou ACL.

Adicionar 777, controle total ou execução administrativa pode esconder o ponto da falha e criar outra vulnerabilidade. O objetivo do diagnóstico não é apenas fazer funcionar, mas descobrir qual autorização mínima está ausente — ou por que a operação deveria continuar negada.

Erros comuns

• “O nome da conta é a identidade interna.” Sistemas usam UIDs, GIDs ou SIDs; nomes são representações administráveis.
• “O usuário abre o arquivo diretamente.” A operação é executada por um processo com credenciais efetivas.
• “Autenticou, então está autorizado.” Login confirmado não concede toda operação.
• “Grupo principal é o único grupo relevante.” Grupos suplementares também podem participar.
• “As classes Unix se somam.” A credencial é enquadrada pela ordem do algoritmo; não escolhe qualquer classe favorável.
• “Escrita no arquivo permite excluí-lo.” Remoção altera o diretório pai e depende de suas regras.
• “x sempre significa executar.” Em diretório, representa busca ou travessia.
• “umask 022 altera arquivos existentes.” Ela filtra modos no momento da criação.
• “ACL sempre aumenta acesso.” Uma entrada ou máscara também pode restringir o resultado efetivo.
• “chmod não afeta ACL.” Em ACLs Linux, modo e entradas básicas mantêm correspondência.
• “DACL ausente e DACL vazia são iguais.” No Windows, uma permite amplamente e a outra não concede direitos.
• “Uma negação sempre vence independentemente da ordem.” A avaliação de ACEs depende da lista canônica e dos direitos solicitados.
• “Capability não é privilégio.” Ela reduz a unidade de poder, mas ainda amplia o que a execução pode fazer.
• “Rodar como administrador é um teste inofensivo.” Isso muda o contexto, mascara a causa e amplia impacto.
• “Checar acesso e depois usar elimina o risco.” A separação pode introduzir uma corrida TOCTOU.

O que você deve guardar

Identidade, autenticação e autorização são etapas diferentes. O kernel autoriza uma operação apresentada por um processo com credenciais, não apenas por um nome de usuário. Em Unix, UID, GID, grupos, propriedade e bits de modo formam a base; o significado de rwx depende de o objeto ser arquivo ou diretório.

umask filtra o modo solicitado durante a criação. ACLs acrescentam usuários e grupos nomeados, mas a máscara pode limitar permissões efetivas. No Windows, tokens carregam SIDs e privilégios; descritores de segurança e DACLs definem ACEs avaliadas para o direito solicitado.

Menor privilégio transforma uma necessidade em poder suficiente, de escopo e duração limitados. Contas de serviço dedicadas, elevação por tarefa e capabilities podem reduzir exposição, mas precisam ser verificadas no contexto real. Diagnóstico seguro observa primeiro e altera somente depois de localizar a autorização mínima correta.

Na próxima aula, veremos como serviços e daemons são iniciados, supervisionados e investigados por unidades, dependências e registros do sistema.

Referências

• The Open Group — POSIX.1-2024: General Concepts, File Access Permissions. Acesso em 5 set. 2026.
• The Open Group — POSIX.1-2024: umask. Acesso em 5 set. 2026.
• The Open Group — POSIX.1-2024: access. Acesso em 5 set. 2026.
• Linux man-pages — credentials(7). Acesso em 5 set. 2026.
• Linux man-pages — capabilities(7). Acesso em 5 set. 2026.
• Linux ACL project — acl(5). Acesso em 5 set. 2026.
• Microsoft Learn — Access Tokens. Acesso em 5 set. 2026.
• Microsoft Learn — Access Control Lists. Acesso em 5 set. 2026.
• Microsoft Learn — How AccessCheck Works. Acesso em 5 set. 2026.
• NIST CSRC Glossary — Least Privilege. Acesso em 5 set. 2026.