Diretórios e Permissões
Estruturas de Diretório
Um diretório é um arquivo especial que contém uma tabela de pares (nome, inode). Isso permite ao SO traduzir nomes de arquivo para a localização dos dados no disco.
Diretório Hierárquico (Árvore)
/ (root)
+-- bin/ (executáveis essenciais)
+-- etc/ (configurações do sistema)
| +-- nginx/
| | +-- nginx.conf
| +-- hostname
+-- home/ (diretórios dos usuários)
| +-- marco/
| | +-- projects/
| | | +-- way2fly/
| | | +-- harness-os/
| | +-- .bashrc
| +-- joao/
+-- proc/ (pseudo-filesystem do kernel)
+-- tmp/ (arquivos temporários)
+-- var/ (dados variáveis: logs, mail, spool)
Internamente, um diretório é uma tabela:
+--------+---------+
| Nome | Inode |
+--------+---------+
| . | 262144 | (referência a si mesmo)
| .. | 2 | (referência ao pai)
| nginx | 262150 |
| hostname| 262146 |
+--------+---------+
Links: Hard e Symbolic
Diagrama — Hard Link vs Symbolic Link
Hard Link: Symbolic Link:
Dois nomes apontam Um arquivo aponta
para o MESMO inode. para o CAMINHO de outro.
dir_entry: "file_a" --+ dir_entry: "link_s" --> [inode 999]
| |
dir_entry: "file_b" --+--> [inode 42] dados: "/home/marco/file_a"
| |
dados do arquivo quando acessado, SO segue
o caminho armazenado
|
v
[inode 42] dados reais
Hard link: Symbolic link:
+ Não ocupa espaço extra + Pode cruzar filesystems
+ Arquivo existe enquanto + Pode apontar para diretórios
houver pelo menos 1 link - Se o alvo é deletado: "dangling"
- Mesmo filesystem apenas link quebrado
- Não funciona para diretórios
Shell — Links na prática
# Criar hard link
$ ln arquivo.txt link_hard.txt
$ ls -li arquivo.txt link_hard.txt
262146 -rw-r--r-- 2 marco marco 100 arquivo.txt # mesmo inode!
262146 -rw-r--r-- 2 marco marco 100 link_hard.txt # link count = 2
# Criar symbolic link
$ ln -s /home/marco/arquivo.txt link_sym.txt
$ ls -li link_sym.txt
262200 lrwxrwxrwx 1 marco marco 25 link_sym.txt -> /home/marco/arquivo.txt
# Deletar o original
$ rm arquivo.txt
# Hard link: link_hard.txt ainda funciona (inode 262146 existe)
# Sym link: link_sym.txt quebra (dangling link)
Permissões Unix (rwx)
Cada arquivo tem permissões para três categorias: owner (dono), group (grupo), e others (todos os outros).
Permissões Unix
$ ls -l script.sh
-rwxr-xr-- 1 marco devs 1234 May 8 script.sh
Tipo Owner Group Others
- rwx r-x r--
| ||| ||| |||
| ||+x ||+x ||+- (execute)
| |+w- |+- |+- (write)
| +r-- +r-- +r-- (read)
+--- tipo (- = regular, d = dir, l = link)
Octal: rwx = 4+2+1 = 7
r-x = 4+0+1 = 5
r-- = 4+0+0 = 4
Resultado: 0754
Para DIRETÓRIOS, significado muda:
r = listar conteúdo (ls)
w = criar/deletar arquivos dentro
x = acessar/traversar (cd)
Sem x no diretório: não pode acessar nada dentro dele!
Shell — Gerenciando permissões
# Mudar permissões
$ chmod 755 script.sh # rwxr-xr-x
$ chmod u+x script.sh # adiciona execute ao owner
$ chmod go-w arquivo.txt # remove write de group e others
$ chmod a+r arquivo.txt # adiciona read para todos
# Mudar dono
$ chown marco:devs arquivo.txt
$ chown -R marco:devs diretorio/ # recursivo
# Permissões especiais
$ chmod 4755 programa # setuid: roda como o dono
$ chmod 2755 diretorio # setgid: herda grupo do dir
$ chmod 1777 /tmp # sticky bit: só dono pode deletar
# ACLs (Access Control Lists) — permissões estendidas
$ setfacl -m u:joao:rx arquivo.txt # dar rx ao joão especificamente
$ getfacl arquivo.txt # ver ACLs
setuid e segurança
Programas com setuid (como
/usr/bin/passwd) rodam com as permissões do dono do arquivo, não do usuário que o executa. passwd precisa escrever em /etc/shadow (root only), então tem setuid de root. Um bug num programa setuid pode dar acesso root a qualquer usuário — é um vetor de ataque clássico.
No harness.os
O modelo de permissões do harness.os mapeia diretamente para a concern governance (uma das 5 cross-cutting concerns):
Diagrama — Permissões no harness.os
Unix Permissions harness.os Governance
================= =====================
owner (marco) project owner (project_id)
rwx = controle total pode criar/editar/deletar knowledge
group (devs) mesh participants (mesh_id)
r-x = ler e executar podem ler knowledge e executar workflows
não podem alterar rules
others (world) external agents
r-- = apenas ler podem consultar, não podem modificar
Diretório permissions: Domain access:
/rules/ (drwxr-x---) knowledge by concern
Dono pode criar regras "security" concern: acesso restrito
Grupo pode ler regras "relational" concern: acesso amplo
Others: sem acesso
setuid = delegate_to_harness()
Agente executa com permissões Um agente filho roda com contexto
do dono do programa do projeto pai (herança de project_id)
ACLs = per-project permissions
Regras específicas por projeto cortex.ai tem rules diferentes de marco.ai
Mesmo que compartilhem o banco mesmo que compartilhem o harness kernel
Python — Access control no harness
class HarnessACL:
"""Access control para knowledge no harness."""
PERMISSIONS = {
"owner": {"read", "write", "delete"}, # rwx
"mesh": {"read"}, # r--
"public": set(), # ---
}
def check_access(self, agent_project, resource_project, operation):
if agent_project == resource_project:
role = "owner"
elif self.in_same_mesh(agent_project, resource_project):
role = "mesh"
else:
role = "public"
return operation in self.PERMISSIONS[role]
# Exemplo: agente do way2fly tentando ler knowledge do way2move
# in_same_mesh = True (ambos no marco.os mesh)
# role = "mesh", operation = "read" -> PERMITIDO
# operation = "write" -> NEGADO
Homework
- Crie uma estrutura de diretórios que simula o harness.os Scale 1:
mkdir -p projeto/{rules,knowledge,workflows}. Configure permissões para que apenas você possa escrever emrules/mas qualquer usuário possa ler. - Crie um hard link e um symbolic link para o mesmo arquivo. Delete o arquivo original. O que acontece com cada link? Explique usando o conceito de inode.
- No harness.os, descreva como você implementaria o equivalente de "sticky bit" para o diretório de knowledge compartilhado — onde todos os agentes do mesh podem adicionar knowledge, mas cada agente só pode deletar o que ele mesmo criou.
Resumo
- Diretório = tabela de pares (nome, inode); hierarquia em árvore
- Hard link: múltiplos nomes para o mesmo inode; symbolic link: ponteiro para um caminho
- Permissões rwx para owner/group/others; octal (chmod 755)
- setuid, setgid, sticky bit: permissões especiais com implicações de segurança
- ACLs para controle de acesso mais granular que rwx
Verifique seu entendimento
Qual a diferença fundamental entre um hard link e um symbolic link?