College Online
0%

Diretórios e Permissões

Módulo 5 · Aula 2 ~15 min de leitura Nível: Intermediário

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

  1. 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 em rules/ mas qualquer usuário possa ler.
  2. 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.
  3. 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

Verifique seu entendimento

Qual a diferença fundamental entre um hard link e um symbolic link?

  • Hard link copia o arquivo; symbolic link não
  • Hard link aponta para o inode diretamente; symbolic link armazena o caminho (path) do alvo
  • Hard link funciona entre filesystems; symbolic link não
  • Symbolic link só funciona com diretórios; hard link só com arquivos regulares