Fișiere, procese, utilizatori și permisiuni: autoritatea reală a unui agent

120–150 de minute · +60–90 de minute pentru exerciții · Nivel: începător · Recomandat înainte: Lecțiile 1–4

Lecția pe scurt

Întrebarea centrală: dacă un agent¹ „vrea” să citească un document, să scrie un fișier¹⁰, să pornească un program¹⁴ sau să oprească un proces¹⁵, cine hotărăște în realitate dacă acea acțiune este permisă?

Primele patru lecții au construit harta. Ai separat modelul de agent¹, ai urmărit întregul stack și ai învățat să plasezi produse concrete în responsabilitățile potrivite. La sfârșitul Lecției 4 a rămas însă o întrebare mai profundă: unde este aplicată autoritatea, în mod concret?

Un model poate propune „șterge fișierul¹⁰”, iar controllerul⁸ agentului¹ poate decide să apeleze un instrument³ de ștergere. Totuși, nici modelul și nici textul din prompt² nu pot modifica singure SSD-ul. La capătul traseului există un proces¹⁵ care rulează sub o anumită identitate, încearcă o operație asupra unui fișier, folder¹¹ sau alt proces, iar sistemul de operare verifică dacă acea operație este permisă.

Aceasta este lecția în care cuvântul „permisiune” încetează să mai fie o idee abstractă dintr-o diagramă. Vom vedea cine are identitate în Linux, cum sunt reprezentate drepturile asupra fișierelor¹⁰, ce este un proces¹⁵, de ce un program¹⁴, un proces și un thread nu sunt același lucru, ce înseamnă utilizator, grup²¹, UID¹⁸, GID¹⁹, proprietar²⁰, rwx, root²⁶, sudo, ACL²⁸ și privilegiile Linux numite capabilities²⁹ — și de ce toate acestea contează atunci când dai unui agent¹ instrumente³ cu efect real.

La finalul lecției vei putea

1. să explici diferența dintre program¹⁴, proces¹⁵ și thread fără să folosești termenii ca sinonime;
2. să descrii ce informații importante are un proces¹⁵: PID¹⁶, proces-părinte, stare⁴, identitate, memorie și descriptori²⁴ de fișiere¹⁰;
3. să explici relația dintre nume de utilizator, UID¹⁸, grupuri²¹ și GID¹⁹;
4. să citești permisiunile rwx pentru proprietar²⁰, grup²¹ și ceilalți²² și să explici ce înseamnă fiecare clasă;
5. să explici de ce rwx are alt sens pentru un folder¹¹ decât pentru un fișier¹⁰ obișnuit;
6. să explici de ce dreptul de a șterge un fișier¹⁰ depinde în primul rând de folderul¹¹ care îl conține;
7. să deosebești root²⁶ de sudo și să explici de ce „rulează totul ca root” este o soluție periculoasă;
8. să recunoști rolul ACL²⁸-urilor, al capabilities²⁹ și al măștii de creare umask fără să le confunzi cu permisiunile de bază;
9. să urmărești o acțiune a agentului¹ până la verificarea concretă făcută de sistemul de operare;
10. să inspectezi conceptual un proces¹⁵ local și să explici ce poate și ce nu poate face — pregătirea directă pentru laboratorul acestei lecții.

1. De la diagrama de arhitectură la autoritatea reală

Lecția 4 a separat agentul¹, modelul și sandbox-ul⁵. Acum coborâm în sistemul de operare și vedem ce înseamnă efectiv „agentul are voie”.

Imaginează-ți un agent¹ pentru documente care primește cererea: „citește contractele din folderul¹¹ companiei, pregătește un rezumat și salvează-l în folderul de drafturi; nu modifica documentele originale”. La nivel de arhitectură, cerința este clară: citire dintr-o zonă, scriere în alta, fără modificare a sursei.

Dar unde este transformată această regulă într-o limită tehnică? Poți scrie instrucțiunea în prompt². Poți adăuga în controller⁸ o regulă „nu modifica sursele”. Poți cere aprobare umană înainte de scriere. Toate sunt utile. Totuși, există o diferență între o regulă pe care aplicația promite să o respecte și o operație pe care sistemul de operare o poate refuza chiar dacă aplicația încearcă să o facă.

Dacă procesul¹⁵ agentului¹ nu are drept de scriere în folderul¹¹ cu documente originale, o încercare obișnuită de a modifica acea zonă va fi refuzată de kernel. Dacă procesul are drept de scriere peste tot și rulează cu privilegii foarte mari, sistemul de operare nu mai oferă aceeași plasă de siguranță. De aceea proiectarea unei aplicații cu agenți include nu doar „ce instrucțiuni îi dau?”, ci și „cu ce identitate rulează procesul și ce resurse poate atinge acea identitate?”.

O analogie scurtă: angajatul, ecusonul și ușa

Gândește-te la un angajat care primește o sarcină. Sarcina spune unde vrea să ajungă; ecusonul stabilește în ce camere poate intra; sistemul de acces de la ușă aplică regula. Faptul că angajatul are un motiv excelent nu schimbă automat drepturile ecusonului. În Linux, procesul¹⁵ este „angajatul”, UID-ul¹⁸ și grupurile²¹ fac parte din „ecuson”, iar kernelul aplică regulile de acces.

2. Vocabularul minim: obiecte, identități și drepturi

Înainte să urmărim verificarea unei permisiuni, fixăm termenii pe care îi vei întâlni în documentație, mesaje de eroare și instrumente³ Linux.

Nu încerca să memorezi toate excepțiile acum. Harta principală are doar patru elemente: obiectul asupra căruia se acționează, procesul¹⁵ care acționează, identitatea procesului și regula de acces pe care kernelul o verifică.

3. Fișierele nu sunt doar documente, iar folderele nu sunt doar „cutii”

Pentru a înțelege permisiunile trebuie să separăm numele pe care îl vedem de obiectul pe care sistemul de fișiere¹⁰ îl gestionează.

Când vezi un nume precum contract.pdf, este tentant să te gândești că numele și fișierul¹⁰ sunt același lucru. Într-un sistem de fișiere¹² Linux obișnuit, folderul¹¹ păstrează o asociere între un nume și un obiect identificat intern. Metadatele importante ale acelui obiect — tip, proprietar²⁰, grup²¹, mod de acces, dimensiune și marcaje temporale — sunt legate de inode¹³. Dacă numele este șters după ce fișierul a fost deschis, descriptorul²⁴ poate rămâne valid până când procesul¹⁵ îl închide; obiectul nu dispare complet cât timp mai există referințe deschise sau alte legături către el.

Această separare explică o serie de comportamente care altfel par ciudate. Un obiect poate avea mai multe nume prin legături fizice (hard links). O legătură simbolică este un alt obiect care conține o cale către o țintă. Un proces¹⁵ care a deschis deja un fișier¹⁰ poate păstra accesul prin descriptorul²⁴ deschis chiar dacă numele respectiv este ulterior șters din folder¹¹. Nu trebuie să stăpânești toate detaliile acestor mecanisme în această lecție, dar trebuie să renunți la ideea simplistă „numele din folder este obiectul însuși”.

Tipuri de obiecte pe care le poți întâlni

Descriptorul de fișier — cum ține procesul legătura cu o resursă deschisă

Când un proces¹⁵ deschide cu succes un fișier¹⁰, kernelul îi întoarce un descriptor²⁴ de fișier: un număr mic pe care procesul îl folosește ulterior pentru citire, scriere sau alte operații. Descriptorul nu este calea. Calea este folosită pentru a găsi și deschide obiectul; după deschidere, procesul lucrează prin descriptor.

Acest detaliu va deveni important mai târziu când vei lucra cu procese¹⁵, pipe-uri, socket-uri și redirectări. Pentru moment reține doar ideea: un proces are o tabelă de resurse deschise. Linux expune informații despre ele și prin /proc/<pid>/fd.

4. Programul stă pe disc; procesul este execuția vie

Unul dintre cele mai importante salturi conceptuale pentru un începător este să nu mai spună „programul¹⁴ are permisiune” atunci când, tehnic, operația este făcută de un proces¹⁵.

Un fișier¹⁰ executabil sau un script Python poate exista ani întregi pe SSD fără să ruleze. Când este pornit, sistemul creează un proces¹⁵: o execuție cu un identificator, memorie, stare⁴, credențiale și resurse deschise. Poți porni același program¹⁴ de două ori și obții două procese diferite.

Asta contează direct pentru agenți¹. Poți avea același cod al agentului pornit o dată ca utilizator obișnuit și altă dată sub un cont de serviciu³³. Codul este același. Autoritatea efectivă poate fi diferită deoarece procesele¹⁵ rulează cu identități diferite și pot primi configurații, medii și resurse diferite.

Ce trebuie să recunoști într-un proces

În Linux, o mare parte din aceste informații poate fi observată prin sistemul de fișiere¹⁰ virtual /proc. De exemplu, /proc/<pid>/status poate expune PID¹⁶, PPID¹⁷, stare⁴, UID¹⁸-uri, GID¹⁹-uri, grupuri²¹ și alte date despre proces¹⁵. Laboratorul va folosi aceste informații ca dovadă, nu ca decor.

Thread-ul — mai multe fire de execuție în același proces

Un thread (fir de execuție) este o cale de execuție din interiorul unui proces¹⁵. Un proces poate avea un singur thread sau mai multe. Thread-urile aceluiași proces împart, în mod normal, memoria globală, descriptorii de fișiere¹⁰, folderul¹¹ curent și multe alte resurse ale procesului, dar fiecare thread are propria stivă de apeluri și propria stare⁴ de execuție.

Pentru un începător, diferența importantă este aceasta: un proces¹⁵ este containerul de resurse și identitate al execuției, iar thread-urile sunt firele de lucru care rulează în interiorul lui. Două procese sunt mai separate între ele decât două thread-uri ale aceluiași proces. De aceea o eroare într-un thread poate afecta datele comune ale întregului proces.

Proces-părinte, proces-copil și subproces

Un agent¹ care „rulează un instrument³” pornește adesea un alt proces¹⁵. De exemplu, un agent de programare poate porni un test, un compilator sau un utilitar. Procesul nou nu devine automat o identitate complet diferită. În situația obișnuită, procesul-copil pornește cu credențiale moștenite de la părinte; anumite proprietăți pot fi apoi schimbate prin mecanisme explicite.

Consecința practică este simplă: dacă agentul¹ rulează cu drepturi excesive și pornește o comandă externă, acea comandă poate primi o autoritate similară. „Instrumentul³ este doar un subproces³⁵” nu este o măsură de securitate.

Semnale — cum este notificat sau oprit un proces

Linux folosește semnale²⁵ pentru a transmite anumite evenimente către procese¹⁵. Un semnal poate cere terminarea, oprirea sau continuarea unui proces ori poate semnala o condiție specială. Un program¹⁴ poate trata unele semnale și poate face o închidere controlată.

Două nume apar frecvent: SIGTERM este cererea obișnuită de terminare, pe care un proces¹⁵ o poate trata pentru a închide resurse și salva stare⁴; SIGKILL forțează terminarea și nu poate fi prins, blocat sau ignorat de proces. Lecția 6 va arăta comenzile cu care interacționezi cu procesele; aici ne interesează diferența conceptuală dintre „cer să se oprească” și „kernelul îl termină forțat”.

5. Utilizatori și grupuri: identitatea cu care acționează procesul

Numele de utilizator este pentru oameni; kernelul aplică regulile folosind identificatori și credențiale asociate procesului¹⁵.

Linux este proiectat ca sistem cu mai mulți utilizatori. Chiar dacă pe laptop lucrează o singură persoană, sistemul folosește mai multe identități: utilizatorul tău, root²⁶ și diverse conturi folosite de servicii. Separarea identităților permite limitarea impactului unei aplicații.

Grupurile suplimentare

Un proces¹⁵ nu este limitat la un singur grup²¹. Pe lângă grupul principal, poate avea o listă de grupuri suplimentare³². Acestea sunt importante deoarece un fișier¹⁰ poate acorda acces grupului său, iar procesul poate satisface acea condiție prin oricare dintre grupurile relevante.

Această structură permite politici simple. Poți avea un grup²¹ legal-readers pentru procese¹⁵ care pot citi contracte și un grup draft-writers pentru procese care pot scrie în zona de drafturi. Nu trebuie să dai aceleași drepturi tuturor utilizatorilor și nici să rulezi aplicația ca root²⁶.

Conturile de serviciu

O aplicație care rulează permanent nu trebuie să fie executată neapărat sub contul personal al unui administrator. În producție este comun să existe un cont dedicat serviciului. Avantajul este că poți acorda acelei identități exact accesul de care are nevoie și poți separa activitatea aplicației de activitatea oamenilor.

Pentru un agent¹, această separare este foarte valoroasă. Dacă agentul trebuie să citească documente dintr-o zonă și să scrie numai rezultate într-o altă zonă, contul de serviciu poate primi tocmai acele drepturi. În cazul unei erori de logică sau al unui prompt² rău intenționat, sistemul de operare păstrează limitele identității respective.

6. Modelul clasic rwx: proprietar, grup și ceilalți

Permisiunile clasice Unix/Linux sunt compacte: trei clase de identitate și trei tipuri de drepturi. Simplitatea lor ascunde însă câteva detalii importante.

Un obiect are, în modelul clasic, un proprietar²⁰ și un grup²¹ asociat. Biții de permisiune sunt grupați astfel:

proprietar    grup       ceilalți
r w x          r w x      r w x

Cum citești un șir de permisiuni

În instrumentele³ Linux, de exemplu în ceea ce afișează comanda ls -l, pe care o vei folosi în laborator, drepturile apar de obicei ca un șir de zece caractere, urmat de proprietar²⁰ și grup²¹. Dacă păstrăm doar coloanele care ne interesează, o linie poate arăta astfel:

-rw-r-----  root      legal-readers  contract-a.pdf

Primul caracter arată tipul obiectului: - pentru un fișier¹⁰ obișnuit, d pentru un folder¹¹ și l pentru o legătură simbolică (symbolic link). Următoarele nouă caractere se citesc în trei grupe: rw- pentru proprietar²⁰, r-- pentru grup²¹ și --- pentru ceilalți²². O liniuță înseamnă că dreptul respectiv lipsește.

În exemplul de mai sus, proprietarul²⁰ root poate citi și scrie, membrii grupului²¹ legal-readers pot doar citi, iar ceilalți²² nu au niciun drept. Pentru un folder¹¹, șirul începe cu d; de exemplu, drwxr-x---.

Când procesul¹⁵ încearcă accesul, sistemul determină clasa relevantă. În forma simplificată: dacă identitatea procesului se potrivește cu proprietarul²⁰, se folosesc drepturile proprietarului; altfel, dacă grupul²¹ obiectului se potrivește cu grupurile procesului, se folosesc drepturile de grup; în celelalte cazuri, se folosesc drepturile pentru ceilalți²². Când există ACL-uri²⁸, algoritmul devine mai bogat, dar principiul rămâne: kernelul compară credențialele procesului cu regulile obiectului.

Ce înseamnă rwx pentru un fișier obișnuit

Ce înseamnă rwx pentru un folder

Aici apar cele mai multe confuzii. Pentru un folder¹¹, litera x nu înseamnă „execută folderul”. Este numită adesea search sau traverse permission.

De aceea un folder¹¹ cu r dar fără x poate permite observarea unor nume, dar nu accesarea normală a obiectelor prin acele nume. Invers, un folder cu x fără r poate permite accesarea unui nume pe care îl cunoști deja, fără să îți permită să enumeri întregul conținut.

De ce vezi permisiuni precum 644 și 755

Documentația și comenzile Linux folosesc adesea și o formă numerică. Fiecare literă are o valoare: r = 4, w = 2, x = 1. Valorile se adună separat pentru proprietar²⁰, grup²¹ și ceilalți²².

Astfel, 644 înseamnă rw-r--r--: proprietarul²⁰ poate citi și scrie, iar grupul²¹ și ceilalți²² pot doar citi. 755 înseamnă rwxr-xr-x. Nu memora numerele ca pe parole; reconstruiește-le din 4, 2 și 1.

7. De ce poți uneori șterge un fișier pe care nu îl poți modifica

Ștergerea și redenumirea ne obligă să vedem folderul¹¹ ca pe o structură de nume, nu ca pe o simplă cutie grafică.

Un proces¹⁵ poate ajunge într-o situație aparent paradoxală: fișierul¹⁰ nu îi permite modificarea conținutului, dar folderul¹¹ părinte îi permite eliminarea intrării. În cazul obișnuit, ștergerea cere drept de scriere și de traversare³⁴ (w + x) pe folderul părinte, plus absența unor reguli care blochează operația. Invers, procesul poate modifica un fișier, dar nu îl poate redenumi ori șterge dacă nu are drepturile necesare asupra folderului.

Mai există și sticky bit³¹, folosit frecvent pe foldere¹¹ partajate. Când este activ pe un folder, ștergerea și redenumirea intrărilor sunt restrânse suplimentar: în termeni simpli, nu este suficient să ai doar dreptul general de scriere în folder pentru a elimina fișierele¹⁰ altcuiva. Acesta este un exemplu de regulă care se adaugă modelului de bază.

8. Cum ajunge Linux la „permis” sau „refuzat”

În realitate nu există o singură etichetă „permisiune”. Mai multe verificări se compun, iar o operație poate fi blocată înainte să ajungă la obiectul final.

Pentru o operație asupra unui fișier¹⁰, îți poți imagina traseul astfel:

În Linux, șirul rwx este doar o parte a răspunsului. ACL²⁸-urile pot introduce reguli pentru utilizatori și grupuri²¹ nominale. Un sistem de fișiere¹² montat doar pentru citire poate refuza scrierea chiar dacă biții clasici par permisivi. Un sandbox⁵ sau un container poate schimba ce căi sunt vizibile, iar Linux Security Modules precum AppArmor sau SELinux pot aplica politici suplimentare. De aceea diagnosticul bun pornește de la operația concretă și urmărește toate limitele relevante, nu doar rezultatul lui ls -l.

9. Dincolo de cele nouă litere: ACL, umask și biți speciali

Modelul proprietar²⁰/grup²¹/ceilalți²² este fundația, dar un sistem real poate avea reguli mai fine sau comportamente speciale la creare și execuție.

ACL — când trei clase nu sunt suficiente

O listă de control al accesului (Access Control List, ACL²⁸) extinde modelul clasic. Pe lângă proprietar²⁰, grupul²¹ principal al obiectului și ceilalți²², un ACL poate conține intrări pentru utilizatori nominali și grupuri nominale. Astfel poți acorda acces lui ana și grupului legal-readers fără să schimbi proprietarul fișierului¹⁰.

Umask — ce se întâmplă la creare

Când un program¹⁴ creează un fișier¹⁰ sau un folder¹¹, cere un set maxim de permisiuni prin parametrul mode. Dacă folderul părinte nu are un ACL²⁸ implicit, umask elimină din acel set biții marcați de mască. De exemplu, un program care cere 666 pentru un fișier, împreună cu o umask de 022, ajunge în cazul obișnuit la 644. Pentru foldere, o cerere de 777 cu aceeași mască ajunge de obicei la 755.

Set-user-ID, set-group-ID și sticky bit

Linux păstrează și biți speciali. Pentru executabile, set-user-ID și set-group-ID pot influența identitatea efectivă la execuție. Pentru foldere¹¹, set-group-ID poate face ca obiectele nou create să moștenească grupul²¹ folderului, lucru util în zone colaborative. Sticky bit³¹ restrânge ștergerea/redenumirea în foldere partajate.

Nu vom configura aceste mecanisme aici. Scopul este să știi că ele există, astfel încât un sistem cu permisiuni aparent „simple” să nu te surprindă.

10. Root, sudo și capabilities: privilegiul nu este un buton magic

Cea mai rapidă metodă de a face să dispară o eroare de permisiune este adesea și cea mai rapidă metodă de a ascunde o problemă de proiectare.

Root — UID 0 și putere foarte mare

În Unix tradițional, root²⁶ este utilizatorul privilegiat (superuser) cu UID¹⁸ 0. Linux păstrează acest model, dar îl implementează împreună cu sistemul de capabilities²⁹. Un proces¹⁵ care rulează ca root primește, în configurația obișnuită, un set foarte larg de privilegii și poate trece de multe verificări care opresc un utilizator obișnuit. Asta nu înseamnă că root este în afara tuturor regulilor: politici precum AppArmor/SELinux, spațiile de nume (namespaces), opțiunile de montare și alte mecanisme pot impune în continuare limite.

Dacă un agent¹ obișnuit poate scrie numai în spațiul său de lucru, o comandă greșită poate distruge acel spațiu de lucru. Dacă același agent rulează cu privilegii sistemice, aceeași eroare poate modifica configurații de sistem, alte aplicații sau date care nu au legătură cu sarcina lui.

sudo nu este root

sudo este un program¹⁴ care permite unui utilizator autorizat să execute o comandă ca alt utilizator sau grup²¹, conform unei politici de securitate; ținta implicită este adesea root²⁶, dar nu trebuie să fie root. De aceea sudo este un mecanism de schimbare controlată a identității pentru o comandă, nu o „permisiune” lipită de program și nici o reparație universală pentru erorile de acces.

Dacă o aplicație cere sudo pentru o operație care ar trebui să fie posibilă cu drepturi limitate, trebuie să întrebi de ce. Poate fi o operație administrativă legitimă; poate fi o proprietate/permisiune configurată greșit; sau poate fi o proiectare care oferă aplicației prea multă autoritate.

Capabilities — împărțirea privilegiului root

În Linux modern, multe privilegii asociate tradițional utilizatorului root²⁶ sunt împărțite în privilegii distincte numite capabilities²⁹. De exemplu, CAP_NET_BIND_SERVICE permite legarea la porturi de rețea privilegiate, iar CAP_DAC_OVERRIDE poate ocoli anumite verificări clasice de acces la fișiere¹⁰. Ideea este să poți acorda un privilegiu precis fără să oferi întregul set de privilegii root.

11. Un proces nu poate controla automat orice alt proces

Linux verifică identitatea și privilegiile atunci când un proces¹⁵ încearcă să trimită un semnal²⁵ altui proces. În cazul obișnuit, un proces fără privilegii poate semnala un alt proces dacă identitățile lor se potrivesc conform regulilor kernelului; altfel este nevoie de privilegiul corespunzător, de exemplu CAP_KILL. De aceea simplul fapt că un agent¹ cunoaște PID-ul¹⁶ unui proces nu îi dă automat dreptul să îl oprească.

Vizibilitatea proceselor poate fi și ea limitată. /proc oferă informații foarte bogate, dar sistemul poate fi configurat astfel încât un utilizator să nu vadă toate detaliile proceselor altor utilizatori. Aceasta este o altă dovadă că „pot afla PID-ul¹⁶” și „pot controla procesul¹⁵” sunt întrebări diferite.

Pentru un agent¹ de administrare sau DevOps, acest lucru devine esențial. Instrumentul³ „restart service” sau „kill process” nu trebuie analizat numai după funcția sa. Trebuie analizat după identitatea cu care va executa operația și sfera proceselor pe care le poate afecta.

12. Exemplu complet — un agent de documente cu autoritate limitată

Urmărim aceeași sarcină de la intenția utilizatorului până la verificarea făcută de sistemul de operare.

Presupunem un agent¹ intern cu următoarea regulă de lucru:

„Citește contractele aprobate, extrage clauzele importante și salvează numai drafturi de analiză. Nu modifica originalele și nu accesa configurația serverului.”

Agentul¹ rulează sub un cont dedicat agentbot. Pentru claritate, folosim două grupuri²¹ conceptuale: legal-readers și draft-writers.

/srv/
├── contracts/           drwxr-x---  root : legal-readers   (750)
│   ├── contract-a.pdf   -rw-r-----  root : legal-readers   (640)
│   └── contract-b.pdf   -rw-r-----  root : legal-readers   (640)
├── drafts/              drwxrwx---  root : draft-writers   (770)
└── system-config/       drwx------  root : root            (700)

Citește fiecare șir cu regula din secțiunea 6. În contracts/, grupul²¹ legal-readers are r-x: poate vedea numele și traversa folderul¹¹, dar nu poate adăuga sau șterge intrări, iar fișierele¹⁰ îi dau numai r. În drafts/, grupul draft-writers are rwx, deci poate crea fișiere. În system-config/, numai root²⁶ are drepturi.

Procesul¹⁵ agentului¹ rulează sub agentbot, iar identitatea lui aparține grupurilor necesare pentru citirea contractelor și scrierea drafturilor. Nu are drepturi administrative asupra configurației serverului.

Acesta este un exemplu de apărare în profunzime: controllerul⁸ are o regulă explicită, instrumentul³ poate fi proiectat doar pentru citire pentru surse, iar sistemul de operare limitează identitatea procesului¹⁵. Dacă una dintre reguli este greșită, celelalte pot reduce impactul.

13. Ce se schimbă când procesul este controlat de un agent

Un agent¹ introduce incertitudine în alegerea acțiunilor, dar nu schimbă legile de bază ale sistemului de operare.

Injecția de prompt (prompt injection) nu creează permisiuni — dar poate exploata permisiuni existente

Un document rău intenționat poate conține instrucțiuni care încearcă să convingă agentul¹ să execute o acțiune periculoasă. Dacă agentul nu are instrumentul³ și procesul¹⁵ nu are drepturile necesare, atacatorul are mai puțină putere. Dacă procesul poate citi toate secretele și poate scrie oriunde, injecția de prompt² are un impact potențial mult mai mare.

De aici rezultă o regulă esențială pentru proiectarea sistemelor agentice: nu acorda procesului¹⁵ drepturi presupunând că modelul „nu le va folosi greșit”. Limitează drepturile după necesitatea reală a sarcinii.

Dacă procesul poate citi un secret, tratează secretul ca accesibil aplicației

Un fișier¹⁰ cu o cheie API⁶ poate fi ascuns vizual într-un folder¹¹, dar dacă procesul¹⁵ agentului¹ îl poate citi și are un instrument³ general de citire a fișierelor, acel secret se află în sfera lui de autoritate. Politica bună este să nu expui procesele folosite de agenți la mai multe secrete decât au nevoie.

Un subproces nu este o zonă de siguranță

Dacă agentul¹ pornește un compilator, un script sau un utilitar, acel proces¹⁵ copil pornește de obicei cu aceeași identitate de bază. Prin urmare, „rulez comanda într-un subproces³⁵” descrie mecanismul de execuție, nu o reducere automată a drepturilor. Izolarea necesită un mecanism separat: cont dedicat, sandbox⁵, container configurat restrictiv, VM sau altă limită.

Căile și legăturile simbolice pot schimba ținta reală

Dacă un agent¹ primește o cale dintr-o sursă care nu este de încredere și apoi scrie sau șterge fără validare, o legătură simbolică sau o structură de foldere¹¹ neașteptată poate face ca operația să ajungă în alt loc decât crede aplicația. Lecția 6 va intra în detaliile căilor; pentru această lecție reține principiul: permisiunile corecte reduc impactul chiar și atunci când aplicația rezolvă greșit o țintă.

14. Principiul privilegiului minim pentru agenți

Nu proiectăm permisiunile după întrebarea „ce ar putea fi util cândva?”, ci după „ce trebuie să poată face acest proces¹⁵ pentru sarcina lui actuală?”.

Principiul privilegiului minim nu spune „agentul¹ nu trebuie să poată face nimic”. Spune că fiecare autoritate trebuie justificată de o funcție concretă. Dacă un drept nu este necesar, absența lui este o protecție.

15. Trei familii de confuzii care produc probleme reale

Nu memorăm zeci de excepții. Grupăm greșelile după mecanism, astfel încât să le poți recunoaște și în sisteme noi.

Fiecare card pornește de la o propoziție pe care o spune des cineva care învață. Citește-o, încearcă să vezi singur problema, apoi citește explicația.

15.1 Fișier versus folder

chmod 444 parinte/fisier
ls -l parinte/fisier
-r--r--r-- 1 ai ai 0 oct 17 10:15 parinte/fisier
rm parinte/fisier
rm: remove write-protected regular empty file 'parinte/fisier'? y
( ștergere reușită )

chmod 000 /tmp/l5q/x
ls /tmp/l5q/x/y/document
ls: cannot access '/tmp/l5q/x/y/document': Permission denied
chmod 755 /tmp/l5q/x
ls /tmp/l5q/x/y/document
/tmp/l5q/x/y/document

ls -l /proc/self/fd/0
lr-x------ 1 ai ai 64 oct 17 10:15 /proc/self/fd/0 -> /dev/null

15.2 Utilizator versus proces

ps -o user:12,args -p 1
USER         COMMAND
root         /usr/lib/systemd/systemd --system --deserialize=125

15.3 Program versus proces și izolare

sh -c 'id -u'
1000
id -u
1000

sh -c 'id -u'
1000
id -u
1000

16. Găsește greșeala — „Rulează agentul cu sudo și nu mai ai probleme”

Exercițiul verifică dacă ai înțeles diferența dintre eliminarea unui mesaj de eroare și rezolvarea corectă a unei limite de autoritate.

17. Cinci domenii: aceeași regulă de autoritate, riscuri diferite

Permisiunile de sistem nu sunt o problemă exclusivă a agenților¹ de programare. Orice agent care produce efecte locale rulează în contextul unei identități.

18. Fișa de autoritate — descrie ce poate face procesul înainte să îi dai instrumente

Aceasta este puntea directă către laborator. Înainte să inspectezi un proces¹⁵ real, exersează să descrii autoritatea lui în propoziții verificabile.

În laborator vei transforma această fișă într-o observație reală asupra unui proces¹⁵ local. Scopul nu va fi să „spargi permisiuni”, ci să poți explica de ce o operație este permisă sau refuzată.

19. Exerciții practice

Exercițiile cresc de la clasificare la raționament. Nu folosi încă terminalul dacă nu vrei; scopul este să poți explica regulile înainte să le inspectezi practic.

chmod 444 parinte/fisier
ls -l parinte/fisier
-r--r--r-- 1 ai ai 0 oct 17 10:15 parinte/fisier
rm parinte/fisier
rm: remove write-protected regular empty file 'parinte/fisier'? y
( ștergere reușită )

sh -c 'id -u'
1000
id -u
1000

20. Quiz cu răspunsuri explicate

Răspunde înainte să deschizi explicația. Încearcă să formulezi răspunsul în ordinea: proces¹⁵ → identitate → obiect → drept → rezultat.

1

Care este diferența esențială dintre program¹⁴ și proces¹⁵?

Deschide răspunsul

Programul¹⁴ este fișierul¹⁰ pregătit pentru execuție, iar procesul¹⁵ este execuția vie a acelui program, cu propria identitate și propriile resurse. Programul este artefactul⁷ de pe disc — codul, cu instrucțiunile lui; procesul este instanța activă: are PID¹⁶, memorie alocată, stare⁴, credențiale și fișiere deschise (secțiunea 4).

Exemplu concret: comanda cp /bin/sleep /tmp/l5demo copiază un program¹⁴ pe disc; pornind de două ori programul /tmp/l5demo, sistemul creează două procese¹⁵ distincte. Rularea reală a arătat:

ps -o pid,args | grep "/tmp/l5demo 60"
2534318 /tmp/l5demo 60
2534319 /tmp/l5demo 60

Un singur program¹⁴ pe disc, două procese¹⁵ vii, fiecare cu propriul PID¹⁶ și propria memorie.

Capcana: să spui „procesul¹⁵ meu este fișierul¹⁰ ăsta” — fișierul nu are stare⁴ și nu poate acționa. Pentru constructorul de agenți¹, distincția este fundamentală: agentul, ca proces, primește drepturi și limite pe care fișierul de pe disc nu le are.

2

Cine execută efectiv o acțiune cerută de agent¹: modelul sau procesul¹⁵?

Deschide răspunsul

Acțiunea locală o execută întotdeauna un proces¹⁵ — codul care rulează în sistemul de operare — iar modelul poate influența doar decizia din spatele ei. Modelul generează text: propuneri, comenzi, argumente. Sistemul de operare nu vede „intenția modelului”; vede procesul care execută comanda și credențialele lui — utilizatorul și grupurile²¹ cu care acționează (secțiunea 5).

Povestea, în ordine: modelul propune „rulează acest script”; controllerul⁸ agentului¹ acceptă propunerea; un proces¹⁵ nou pornește, cu credențialele controllerului; sistemul de operare verifică permisiunile acelui proces și abia apoi acțiunea se realizează sau este refuzată. Modelul nu apare nicăieri în această verificare.

Capcana: să spui „modelul a șters fișierul¹⁰”. Pentru constructorul de agenți¹, distincția arată unde se aplică securitatea: nu „la model”, ci la proces¹⁵ și la credențialele cu care rulează — exact ceea ce poate fi limitat tehnic.

3

Ce identifică PID-ul¹⁶?

Deschide răspunsul

PID-ul¹⁶ identifică o instanță de proces¹⁵ — o execuție vie a unui program¹⁴ — și nu programul în general și nici utilizatorul care l-a pornit. Procesul este execuția vie a unui program (secțiunea 4), iar PID-ul (process ID) este numărul unic prin care sistemul de operare îl numește, îl urmărește și îl controlează.

La ce folosește: comenzile ps și kill lucrează cu PID¹⁶-uri — ps afișează procesele¹⁵ cu PID-urile lor, kill trimite un semnal²⁵ procesului numit prin PID —, iar folderul¹¹ /proc/<pid>/ expune informațiile procesului: memorie, stare⁴, conexiuni. Demonstrație reală pe Ubuntu 24.04: același program¹⁴ copiat în /tmp/l5demo, pornit de două ori:

ps -o pid,args | grep "/tmp/l5demo 60"
2534318 /tmp/l5demo 60
2534319 /tmp/l5demo 60

Două procese¹⁵ din același fișier¹⁰ program¹⁴, cu două PID¹⁶-uri diferite — deci PID-ul nu identifică programul. Și nu identifică utilizatorul: identitatea aparține credențialelor procesului (UID¹⁸, GID¹⁹, secțiunea 5), vizibile cu id, nu PID-ului. Iar PID-urile sunt reutilizate: după ce procesul se termină, numărul poate fi atribuit altui proces.

Capcana: să reții PID-ul¹⁶ unui agent¹ ca identificator stabil între rulări. Pentru constructorul de agenți, PID-ul identifică execuția „acum”: kill pe PID-ul corect oprește exact procesul¹⁵ vizat, iar /proc/<pid>/ îi arată starea⁴ reală.

4

Ce rol au UID¹⁸ și GID¹⁹?

Deschide răspunsul

UID¹⁸ și GID¹⁹ sunt identificatorii numerici ai utilizatorului, respectiv ai grupurilor, iar Linux îi folosește în credențialele procesului¹⁵ și în fiecare verificare de acces. UID (user ID) identifică utilizatorul, GID (group ID) identifică grupul²¹ principal; numele pe care le vezi în terminal sunt doar etichete prietenoase pentru aceste numere.

Comanda reală id, pe Ubuntu 24.04, arată ambele:

id
uid=1000(ai) gid=1000(ai) groups=1000(ai),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),114(lpadmin),125(docker),988(sambashare),1002(shared)

Fiecare element are sens: uid=1000(ai) este utilizatorul, gid=1000(ai) grupul²¹ principal, iar lista groups=… sunt grupurile suplimentare — printre care și grupul sudo, care dă dreptul de a rula comenzi administrative. Când procesul¹⁵ încearcă să citească sau să scrie, sistemul compară aceste numere cu drepturile obiectului, nu cu numele tău.

Capcana: să crezi că „numele la fel” înseamnă „aceeași identitate”. Pentru constructorul de agenți¹, contează pentru că identitatea cu care rulează procesul¹⁵ agentului decide la ce are acces — de aceea se folosește un cont dedicat, nu contul tău personal.

5

x pe un folder¹¹ înseamnă că „execuți folderul”?

Deschide răspunsul

Nu — litera x pe un folder¹¹ înseamnă drept de traversare³⁴: procesul¹⁵ poate trece prin acel folder și poate ajunge la nume pe care deja le cunoaște, dacă restul regulilor permit. Traversarea este folosirea folderului ca parte a unei căi — a trece prin el — și nu listarea conținutului, care cere r (secțiunea 6).

Exemplu concret: pe un folder¹¹ cu permisiuni --x, ls folder eșuează (nu poți lista numele), dar ls folder/nume-cunoscut poate reuși — știi numele, iar x îți permite să traversezi până la el. x pe un fișier¹⁰ este altceva: dreptul de a-l executa ca program¹⁴ — același semn, alt sens, după tipul obiectului.

Capcana: să acorzi x pe foldere¹¹ crezând că acorzi citirea; sau să acorzi r fără x și să te aștepți să „intrai” în folder. Pentru constructorul de agenți¹, distincția este esențială la folderele intermediare ale căilor agentului: fără x pe ele, chiar și fișierele¹⁰ cu drepturi complete rămân inaccesibile.

6

Dacă un fișier¹⁰ nu este cu drept de scriere, este imposibil să îl ștergi?

Deschide răspunsul

Nu — ștergerea este în primul rând o operație asupra folderului¹¹ părinte: dacă ai drept de scriere și executare pe folder, poți șterge din el și fișiere¹⁰ care nu îți aparțin sau care sunt doar pentru citire. Intrarea este rândul fișierului din conținutul folderului — numele și referința lui —, iar ștergerea modifică folderul, nu fișierul (secțiunea 7).

Demonstrație reală pe Ubuntu 24.04:

chmod 444 parinte/fisier
ls -l parinte/fisier
-r--r--r-- 1 ai ai 0 oct 17 10:08 parinte/fisier
rm parinte/fisier
rm: remove write-protected regular empty file 'parinte/fisier'? y
( ștergere reușită )

Fișierul¹⁰ era -r--r--r-- — doar citire, chiar și pentru proprietar²⁰ —, dar folderul¹¹ era al meu cu drept de scriere, deci intrarea putea fi ștearsă.

Capcana: să legi ștergerea de drepturile fișierului¹⁰. Diferența contează exact la agenți¹: dacă vrei ca agentul să modifice un fișier dar să nu îl poată șterge, nu reduci drepturile fișierului — limitezi scrierea pe folderul¹¹ părinte, iar unde e nevoie folosești sticky bit³¹ pe foldere partajate.

7

De ce un fișier¹⁰ cu permisiune de citire poate fi totuși inaccesibil printr-o cale?

Deschide răspunsul

Pentru că accesul prin cale cere drept de traversare³⁴ (x) pe fiecare folder¹¹ intermediar; dacă unul dintre ele refuză, fișierul¹⁰ final devine inaccesibil chiar dacă are permisiune de citire. Calea este lista de foldere prin care treci până la fișier, iar traversarea este dreptul de a trece prin ele (secțiunea 6).

Demonstrație reală pe Ubuntu 24.04 — un folder¹¹ intermediar fără niciun drept (chmod 000), apoi restaurat:

chmod 000 /tmp/l5q/x
ls /tmp/l5q/x/y/document
ls: cannot access '/tmp/l5q/x/y/document': Permission denied
chmod 755 /tmp/l5q/x
ls /tmp/l5q/x/y/document
/tmp/l5q/x/y/document

Nimic nu s-a schimbat la fișier¹⁰ — doar folderul¹¹ intermediar și-a recăpătat dreptul de traversare³⁴, iar accesul a revenit.

Capcana: să verifici doar permisiunile fișierului¹⁰ final când „nu se citește”. Pentru constructorul de agenți¹, regula economisește depanare: verifici x pe fiecare folder¹¹ din calea pe care agentul o folosește — inclusiv cele pe care nu le-ai observat.

8

Este sudo același lucru cu utilizatorul root²⁶?

Deschide răspunsul

Nu — root²⁶ este identitatea privilegiată cu UID¹⁸ 0, iar sudo²⁷ este mecanismul care poate porni o comandă sub altă identitate, conform unei politici scrise. Root este utilizatorul tradițional cu drepturi nelimitate; sudo (superuser do) este programul¹⁴ care citește o politică și decide cine poate rula ce, sub ce identitate (secțiunea 10).

Comanda reală arată identitatea prin număr:

id root
uid=0(root) gid=0(root) groups=0(root)

Privilegiul este legat de UID¹⁸ 0, nu de numele „root²⁶” — contează numărul, nu eticheta.

Capcana: să tratezi sudo²⁷ ca pe o identitate. sudo este poarta cu politici: poate da un utilizator dreptul să ruleze o singură comandă ca root²⁶ sau ca alt utilizator de serviciu, fără parola root. Pentru constructorul de agenți¹, distincția decide designul: agentul primește un cont dedicat, iar operațiile privilegiate rare trec prin reguli sudo precise — nu prin rularea întregului agent ca root (exact confuzia din secțiunea 16).

9

Ce problemă rezolvă privilegiile Linux numite capabilities²⁹?

Deschide răspunsul

Capabilities²⁹ împart privilegiile tradiționale ale root²⁶-ului în unități mai precise, astfel încât un proces¹⁵ să poată primi un singur privilegiu necesar fără să primească toată puterea root. Capabilities sunt privilegiile root împărțite în unități distincte — de pildă legarea unui port sub 1024 (CAP_NET_BIND_SERVICE) sau ocolirea verificărilor clasice de acces la fișiere¹⁰ (CAP_DAC_OVERRIDE).

Exemplu concret: procesul¹⁵ tău poate citi propriile capabilități active din /proc/self/status. Ieșire reală pe Ubuntu 24.04, pentru un proces obișnuit fără privilegii:

grep -E 'CapEff|CapPrm' /proc/self/status
CapPrm:	0000000000000000
CapEff:	0000000000000000

Cele două rânduri arată în hexazecimal că procesul¹⁵ nu are nicio capabilitate activă — zero. Un proces căruia i s-ar acorda doar cap_net_bind_service ar avea o cifră diferită de zero, exact pentru acea abilitate.

Capcana: să vezi capabilities²⁹ ca „root²⁶ pe bucăți care se dau oricum împreună” — fiecare capabilitate este independentă și se acordă separat. Pentru constructorul de agenți¹, mecanismul permite un agent care poate, de pildă, să asculte pe un port, dar să nu poată citi fișierele¹⁰ altor utilizatori — o granularitate pe care rularea ca root nu o oferă.

10

Ce aduce un ACL²⁸ față de proprietar²⁰/grup²¹/ceilalți²²?

Deschide răspunsul

ACL²⁸ permite reguli de acces mai fine decât proprietar²⁰/grup²¹/ceilalți²²: drepturi pentru utilizatori și grupuri suplimentare³², numite explicit, peste cele trei clase clasice. ACL (Access Control List) este lista de intrări suplimentare atașată unui fișier¹⁰ sau folder¹¹, citibilă cu comanda getfacl (secțiunea 9).

Exemplu concret: fără ACL²⁸, ca să dai acces contabililor la un folder¹¹, trebuie să creezi un grup²¹ și să pui oamenii în el; cu ACL, adaugi direct o intrare pentru utilizatorul respectiv, pe acel folder, fără să schimbi grupurile. Comanda reală pe Ubuntu 24.04 arată lista:

getfacl /tmp | head -3
# file: tmp
# owner: root
# group: root

Pe /tmp nu există intrări suplimentare; pe folderele¹¹ partajate, ar apărea liniile user:nume:… și group:nume:….

Capcana: să crezi că ACL²⁸ înlocuiește modelul clasic — el se adaugă peste cele nouă litere, nu în locul lor. Pentru constructorul de agenți¹, ACL este instrumentul³ potrivit când agentul trebuie să citească anumite foldere¹¹ fără a fi membru al grupurilor existente.

11

Un subproces³⁵ are automat mai puține drepturi decât agentul¹ care l-a pornit?

Deschide răspunsul

Nu — un subproces³⁵ pornește de obicei cu o identitate derivată din procesul¹⁵-părinte: același utilizator și aceleași grupuri²¹, dacă nu există un mecanism explicit care să o schimbe. Subprocesul este procesul pornit de agent¹ — de pildă un script sau un instrument³ — iar moștenirea înseamnă că primește aceleași credențiale (secțiunile 4.3 și 13.3).

Demonstrație reală pe Ubuntu 24.04 — un subproces³⁵ rulează id -u, iar procesul¹⁵ părinte rulează același lucru:

sh -c 'id -u'
1000
id -u
1000

Aceleași cifre: subprocesul³⁵ acționează cu identitatea părintelui, deci poate atinge exact ce putea atinge și părintele — nimic mai puțin, nimic mai mult.

Capcana: să crezi că „am pornit un mic script, deci el e mai puțin periculos”. Pericolul nu scade odată cu mărimea procesului¹⁵. Pentru constructorul de agenți¹, regula este: orice subproces³⁵ pornit de agent moștenește autoritatea agentului; dacă vrei mai puțin, trebuie un mecanism explicit — alt utilizator, sudo cu politică, sau un sandbox⁵.

12

Ce înseamnă privilegiu minim³⁶ pentru un agent¹?

Deschide răspunsul

Privilegiu minim³⁶ înseamnă că procesul¹⁵ agentului¹ primește numai drepturile necesare funcțiilor sale concrete — nu toate drepturile care „ar putea fi utile”. Privilegiul minim este principiul din secțiunea 14: se pornește de la sarcină, se listează resursele necesare și se acordă exact acele drepturi, pe durata necesară.

Exemplu concret: agentul¹ care doar citește facturi primește drept de citire pe folderul¹¹ primit/ și niciun drept de scriere; agentul care pregătește fișe de plată primește scriere doar în draft/; nimic din ce nu ține de sarcină.

Capcana: să acorzi drepturi „în plus, ca să nu mai revii” — fiecare drept în plus este o pagubă posibilă în plus când agentul¹ greșește sau când datele sunt ostile⁹. Pentru constructorul de agenți, principiul transformă securitatea dintr-o listă de interdicții într-o listă scurtă de acordări explicite, verificabilă în fișa de autoritate.

13

Dacă promptul² spune „nu modifica sursele”, mai sunt utile permisiunile doar pentru citire?

Deschide răspunsul

Da — instrucțiunea din prompt² este o regulă de comportament, iar permisiunea doar pentru citire este o limită tehnică independentă, care poate refuza operația chiar dacă aplicația încearcă totuși să scrie. Promptul este textul trimis modelului; permisiunea doar pentru citire este dreptul sistemului de operare de a refuza orice scriere, indiferent de ce spune orice text.

Exemplu concret: modelul poate fi convins de un document ostil⁹ să „modifice sursele” — și va genera comanda; sistemul de operare o refuză, fiindcă procesul¹⁵ nu are drept de scriere pe folderul¹¹ surselor. Instrucțiunea a fost ignorată, limita tehnică nu a fost.

Capcana: să crezi că un prompt² bine scris înlocuiește permisiunile. Ele acționează la niveluri diferite: promptul influențează propunerea, permisiunea decide execuția. Pentru constructorul de agenți¹, asta este apărarea în profunzime din secțiunea 13: promptul spune „nu”, iar permisiunile fac ca „nu” să fie respectat și verificabil.

14

De ce contează grupurile²¹ suplimentare?

Deschide răspunsul

Grupurile²¹ suplimentare contează pentru că procesul¹⁵ poate primi acces la un obiect prin oricare dintre grupurile sale, nu numai prin grupul principal. Grupul principal este cel din gid=, iar grupurile suplimentare sunt lista din groups= — toate se compară la verificarea accesului (secțiunea 5).

Comanda reală id arată lista:

id
uid=1000(ai) gid=1000(ai) groups=1000(ai),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),114(lpadmin),125(docker),988(sambashare),1002(shared)

Un fișier¹⁰ al grupului²¹ docker este accesibil acestui utilizator prin grupul suplimentar 125, chiar dacă grupul principal este ai.

Capcana: să verifici doar grupul²¹ principal când un acces „misterios” funcționează sau eșuează — motivul poate sta în oricare grup suplimentar. Pentru constructorul de agenți¹, asta înseamnă că identitatea efectivă a agentului este suma grupurilor contului său: contul dedicat primește exact grupurile necesare, iar orice grup în plus este un drept în plus.

15

Care este ordinea cea mai bună pentru a explica o eroare de acces?

Deschide răspunsul

Ordinea cea mai bună este: identifici procesul¹⁵ și credențialele lui, apoi obiectul și calea, apoi dreptul cerut, apoi clasa sau ACL²⁸-ul relevant și eventualele reguli suplimentare — abia la final decizi ce trebuie schimbat. Credențialele sunt UID-ul¹⁸ și grupurile²¹ procesului, obiectul și calea spun ce se atinge și prin unde, dreptul cerut este ce operație (citire, scriere, execuție), iar clasa/ACL-ul este regula care s-a aplicat (secțiunea 8).

Exemplu concret: „serverul nu citește raportul” devine, în ordine: procesul¹⁵ rulează ca cont-serviciu; calea este /date/raport.md; dreptul cerut este citirea; pe fișier¹⁰, clasa „ceilalți²²” are doar r--, iar ACL²⁸-ul nu are intrare pentru serviciu. Concluzia corectă vine singură: se acordă citirea pe calea respectivă, nu se schimbă programul¹⁴.

Capcana: să începi prin a schimba permisiuni la întâmplare „ca să meargă”. Pentru constructorul de agenți¹, ordinea aceasta transformă eroarea criptică într-o verificare scurtă, pas cu pas, în care fiecare pas are un rezultat da sau nu.

21. Recapitulare — harta autorității unui proces

Dacă reții relațiile de mai jos, poți reconstrui restul fără să memorezi fiecare bit special sau fiecare comandă Linux.

Program¹⁴ ≠ proces¹⁵

Programul¹⁴ este artefactul⁷; procesul¹⁵ este execuția activă, cu PID¹⁶, stare⁴, memorie și credențiale.

Procesul¹⁵ are identitate

UID¹⁸, GID¹⁹ și grupurile²¹ relevante participă la verificările de acces.

Fișier¹⁰ ≠ folder¹¹

rwx are semnificații diferite pentru conținutul unui fișier¹⁰ și pentru structura unui folder¹¹.

Ștergerea privește folderul¹¹

Eliminarea sau redenumirea unei intrări modifică folderul¹¹ părinte, nu doar fișierul¹⁰.

rwx nu este toată securitatea

ACL²⁸, sticky/setgid, umask³⁰, capabilities²⁹, sisteme de fișiere¹⁰ doar pentru citire și izolarea pot schimba rezultatul.

Root²⁶ nu este un remediu

Privilegiul excesiv poate elimina simptomele și mări în același timp impactul unei erori.

Subproces³⁵ ≠ sandbox⁵

Un proces¹⁵-copil nu primește automat mai puține drepturi; izolarea trebuie proiectată separat.

Agentul¹ cere, sistemul de operare autorizează

Modelul și controllerul⁸ pot alege acțiunea; procesul¹⁵ încearcă operația; kernelul aplică limita tehnică.

Formula de o pagină: acțiunea unui agent¹ devine o operație reală numai printr-un proces¹⁵. Procesul are credențiale. Datele de identitate sunt comparate cu regulile obiectului și cu politicile suplimentare. Kernelul permite sau refuză operația. De aceea securitatea agentului începe și cu întrebarea „sub ce identitate rulează?”.

Ce simplifică intenționat lecția: Linux are și alte mecanisme de control — namespace-uri, seccomp, Linux Security Modules, cgroups, reguli de montare și politici ale containerelor. Nu le folosim aici ca să nu amestecăm nivelurile. Scopul Lecției 5 este să construiești corect baza: proces¹⁵ → identitate → cale/obiect → drept cerut → reguli suplimentare → rezultat. Lecțiile următoare pot adăuga mecanisme peste această hartă fără să o înlocuiască.

Vocabular esențial

Recitește definițiile după parcurgerea lecției — acum fiecare termen are context. Sunt grupate în trei familii: termenii moșteniți din Lecțiile 1–4, obiectele, procesele și identitățile din Lecția 5 și permisiunile și privilegiile. Apasă pe numărul de lângă un termen ca să ajungi la explicația lui; butonul Înapoi al browserului te duce înapoi unde citeai.

Vocabular din Lecțiile 1–4

Termen	Ce înseamnă
1 Agent	Sistem care urmărește un obiectiv, păstrează stare și alege dinamic acțiunile următoare, până la o condiție de oprire. Procesul agentului acționează cu identitatea și drepturile lui proprii. Detaliat în Lecția 1.
2 Prompt	Instrucțiunea trimisă modelului pentru a-i cere un rezultat. Influențează propunerea, nu drepturile procesului. Detaliat în Lecția 1.
3 Instrument	Capacitate pe care agentul o poate apela: o citire, o scriere, o comandă. Instrumentele sunt locul unde agentul atinge sistemul de fișiere și unde se aplică permisiunile. Detaliat în Lecția 1.
4 Stare	Informația păstrată despre sarcina curentă: progresul, încercările, rezultatele. Fără stare, agentul nu poate relua sau corecta nimic. Detaliat în Lecția 1.
5 Sandbox	Mediu izolat care limitează accesul unui proces la fișiere, rețea sau alte resurse. În laboratorul 5, folderul cu modul 0000 este o piesă dintr-un sandbox didactic. Detaliat în Lecția 1.
6 API	Interfața prin care un program cere date sau acțiuni altui program, într-un format stabilit. Instrumentele agentului sunt adesea API-uri. Detaliat în Lecția 1.
7 Artefact de model	Fișierul care împachetează ponderile și metadatele unui model antrenat — de pildă un fișier GGUF. Pe disc este un fișier ca oricare altul: permisiunile lui clasice i se aplică la fel. Detaliat în Lecția 3.
8 Controller	Componenta care coordonează bucla agentului: menține starea, alege pașii, aplică permisiunile. Procesul controllerului este cel al cărui UID contează la verificarea accesului. Detaliat în Lecția 2.
9 Prompt injection	Situația în care datele citite de agent conțin text care încearcă să se comporte ca instrucțiune. Permisiunile corecte fac ca chiar o injecție reușită să rămână fără efect. Detaliat în Lecția 2.

Obiecte, procese și identități

Termen	Ce înseamnă
10 Fișier	Obiect dintr-un sistem de fișiere care poate conține date sau reprezenta o resursă. Ca un plic: ține o scrisoare — sau poate fi gol —, dar are o adresă și un proprietar. Un fișier nu este neapărat un document: poate reprezenta și dispozitive sau conexiuni.
11 Folder	Obiect al sistemului de fișiere care asociază nume cu alte obiecte, organizându-le într-o ierarhie. Ca un dosar cu separatoare: ține rândurile, iar drepturile lui controlează cine poate adăuga sau scoate rânduri. Folderul nu este doar o „cutie” — permisiunile lui decid ștergerea și traversarea.
12 Sistem de fișiere	Structura și regulile prin care sistemul organizează fișiere și foldere pe un mediu de stocare sau într-un sistem virtual. Ca dulapul cu propriile reguli de arhivare: același plic poate sta în dulapuri cu reguli diferite. Un agent poate întâlni sisteme locale, montate din rețea sau virtuale — nu toate se poartă la fel.
13 Inode	Structura internă prin care sistemul de fișiere ține metadatele unui obiect: tipul, proprietarul, grupul, permisiunile, dimensiunea. Ca fișa de evidență a unui apartament: numele de pe ușă se poate schimba, fișa rămâne a obiectului. Numele fișierului și obiectul în sine nu sunt același lucru — de aceea ștergerea numelui e o operație pe folder.
14 Program	Cod și date pregătite pentru a putea fi executate. Ca partitura: notele sunt scrise, dar nimeni nu cântă încă. Programul nu este execuția vie — aceea este procesul.
15 Proces	Instanță aflată în execuție a unui program, cu stare, memorie, credențiale și resurse administrate de kernel. Ca orchestra care cântă partitura: acum se aude muzica și există un interpret care acționează. Procesul primește efectiv identitatea, memoria și drepturile — nu fișierul de pe disc.
16 PID	Process ID: identificatorul numeric al procesului, prin care sistemul îl numește, îl urmărește și îl controlează. Ca numărul de ordine de la urgențe: valabil cât timp ești acolo. Instrumentele de diagnostic și /proc folosesc PID-ul, iar numărul este reutilizat după terminare.
17 PPID	PID-ul procesului-părinte — al procesului care l-a pornit pe cel curent. Ca persoana de contact de urgență: spune din ce lanț de execuție vine procesul. PPID-ul nu garantează că părintele mai rulează.
18 UID	Identificatorul numeric al utilizatorului sub care rulează procesul. Ca legitimația numerotată: numele „agentbot” este o etichetă pentru oameni, kernelul lucrează cu numărul. UID-ul nu este numele de login.
19 GID	Identificatorul numeric al grupului. Ca apartenența la o asociație: mai multe identități primesc același set de drepturi prin grup. GID-ul nu este o listă de utilizatori — este numărul grupului.
20 Proprietar	Utilizatorul asociat ca proprietar al unui obiect; prima clasă de permisiuni clasice i se aplică lui. Ca persoana care figurează în actele apartamentului. Proprietarul nu primește automat și drepturile clasei de grup — clasa aplicată este una singură.
21 Grup	Clasa de identități asociată obiectului: dacă procesul se potrivește cu ea, primește drepturile clasei de grup. Ca lista invitaților la un eveniment: ești pe listă, intri pe ușa invitaților. Grupul nu este o persoană — este setul care le reunește.

Permisiuni și privilegii

Termen	Ce înseamnă
22 Ceilalți	Clasa identităților care nu sunt proprietar și nu se potrivesc cu grupul obiectului. Ca publicul general la un concert: nu ești pe listă și nu ești personal, dar regulile sălii se aplică și ție. „Ceilalți” nu este o listă numită — este tocmai restul lumii.
23 Rwx	Literele read, write, execute/search — cele trei drepturi clasice, câte trei litere pentru proprietar, grup și ceilalți. Aceleași litere au efecte diferite pe fișier și pe folder: x este execuție pe fișier și traversare pe folder. Ele nu sunt trei comenzi separate — sunt biții aceleiași măști.
24 Descriptor de fișier	Numărul mic prin care un proces se referă la un fișier, socket sau alt obiect deschis. Ca biletul de la garderobă: îl arăți și primești paltonul, chiar dacă eticheta de pe el s-a schimbat între timp. Descriptorul rămâne valid chiar dacă numele din sistem de fișiere se schimbă.
25 Semnal	Mecanism prin care kernelul sau alt proces notifică un proces despre un eveniment — de pildă cererea de oprire. Ca soneria de la ușă: anunță evenimentul, nu conține discuția. Semnalul nu este un mesaj de eroare și nu explică de ce a venit.
26 Root	Utilizatorul privilegiat tradițional, cu UID 0 — cel care poate citi și scrie fără restricțiile obișnuite. Ca cheia generală a clădirii: deschide tot, chiar din greșeală. Rularea agentului ca root extinde masiv suprafața de impact a unei erori.
27 Sudo	Mecanism și program pentru a executa o comandă sub altă identitate, conform unei politici scrise. Ca portarul care verifică lista înainte să deschidă o ușă. sudo nu este „permisiunea root” și nu face automat o acțiune sigură.
28 ACL	Access Control List: reguli suplimentare de acces pentru utilizatori și grupuri, pe lângă cele nouă litere clasice. Ca invitații nominalizați pe lângă lista generală a evenimentului. ACL-ul nu înlocuiește modelul clasic — se adaugă peste el.
29 Capability	Privilegiu Linux granular, separat de setul larg de privilegii asociate tradițional root. Ca cheile individuale ale clădirii: una deschide bariera, alta tabloul electric de pe scară, fără cheia generală. Capabilities nu sunt „root pe bucăți care vin la pachet” — fiecare se acordă separat.
30 Umask	Mască de creare care elimină anumite permisiuni din modul cerut pentru un obiect nou, când folderul părinte nu are ACL implicit. Ca filtrul unei imprimante: ceri color, iese alb-negru. Umask-ul nu limitează fișierele deja existente — acționează doar la creare.
31 Sticky bit	Regula suplimentară a folderelor partajate: intrarea poate fi ștearsă numai de proprietarul fișierului sau al folderului. Ca dulapurile cu lacăte individuale într-un hol comun: fiecare își protejează propriul obiect. Sticky bit-ul nu este un înlocuitor al permisiunilor — este o restricție pe deasupra lor.
32 Grupuri suplimentare	Lista de grupuri dincolo de grupul principal, toate comparate la fiecare verificare de acces. Ca apartenențele multiple la asociații: oricare apartenență îți dă drepturile ei. Ele nu se acumulează cu clasa proprietarului — clasa aplicată rămâne una singură.
33 Cont de serviciu	Utilizator dedicat sub care rulează un proces, fără login interactiv. Ca legitimația și uniforma de serviciu: identitatea aparține funcției, nu persoanei. Contul de serviciu nu este root și nu este contul tău personal.
34 Traversare	Dreptul de a trece printr-un folder ca parte a unei căi — litera x aplicată folderelor. Ca ușa dintre camere: deschide drumul spre un nume cunoscut, fără să îți dea lista camerei. Traversarea nu este citirea conținutului folderului — aceea cere r.
35 Subproces	Proces pornit de alt proces, care moștenește de regulă credențialele părintelui. Ca delegatul trimis de agent cu legitimația aceleiași firme. Un subproces nu este automat mai puțin privilegiat — separarea în alt PID nu este izolare.
36 Privilegiu minim	Principiul de a acorda procesului exact drepturile necesare funcțiilor lui concrete, pe durata necesară. Ca legătura cu sfoara scurtă a uneltelor: nimic care să depășească brațul sarcinii. Privilegiul minim nu este o măsură temporară — este o decizie de proiectare, scrisă în fișa de autoritate.

22. Referințe și aprofundare

Sursele de mai jos sunt documentație tehnică de referință pentru conceptele Linux folosite în lecție. Nu este necesar să le citești integral acum; sunt utile când vrei să verifici un detaliu sau să înțelegi comportamentul exact al kernelului.

• Linux man-pages — credentials(7): PID¹⁶-uri, UID¹⁸/GID¹⁹, identificatori efectivi, grupuri suplimentare³² și relațiile de proces¹⁵.
• Linux man-pages — inode(7): tipuri de fișiere¹⁰, biți de permisiune și biți speciali.
• Linux man-pages — path_resolution(7): rezolvarea căilor și verificarea permisiunilor pe foldere¹¹.
• Linux ACL — acl(5): Access Control Lists și algoritmul de verificare a accesului.
• Linux man-pages — capabilities(7): împărțirea privilegiilor root²⁶ în capabilities²⁹.
• Linux man-pages — proc_pid_status(5): câmpuri precum State, PID¹⁶, PPID¹⁷, UID¹⁸, GID¹⁹, Groups și Umask³⁰.
• Linux man-pages — open(2): deschiderea fișierelor¹⁰ și descriptori²⁴ de fișiere.
• Linux man-pages — signal(7): modelul de semnale²⁵ și comportamentul SIGTERM/SIGKILL.
• Linux kernel documentation — sistemul de fișiere /proc: informații expuse despre procese¹⁵.
• Linux man-pages — pthreads(7): relația dintre proces¹⁵ și thread și resursele partajate.
• Linux man-pages — unlink(2): ștergerea intrărilor, drepturile folderului¹¹ părinte și sticky bit³¹.
• Linux man-pages — umask(2): masca de creare și relația cu ACL²⁸-urile implicite.
• sudo(8): executarea unei comenzi ca alt utilizator conform unei politici.
• Linux man-pages — proc(5): pseudo-sistemul /proc și opțiunea hidepid.
• Linux man-pages — kill(2): regulile de permisiune pentru trimiterea semnalelor între procese¹⁵.

23. Ce urmează

Lecția 5 a explicat ce obiecte există și ce reguli aplică sistemul de operare. Acum ai vocabularul necesar pentru a privi o eroare de permisiune fără să reacționezi automat cu sudo și pentru a descrie autoritatea unui proces¹⁵ înainte să îi dai instrumente³ controlate de agent¹.

Lecția 6 — Linux și terminalul pentru constructorii de agenți¹ va transforma aceste concepte în lucru practic: căi, navigare, pipe-uri, variabile de mediu, manageri de pachete, servicii, SSH și jurnale. Acolo vei învăța să inspectezi și să manipulezi în siguranță sistemul din linia de comandă; aici ai construit modelul mental care îți spune ce înseamnă rezultatele pe care le vezi.

Podul către Lecția 6: în această lecție ai aflat de ce un proces¹⁵ are sau nu are acces. În următoarea vei învăța instrumentele³ cu care verifici acel proces, acea cale și acele permisiuni fără să ghicești.