Permisos, ACLs i gestió d’ accés granular a Linux

Als sistemes Linux, els permisos tradicionals de propietari, grup i altres (rwx) són suficients per a un gran percentatge de casos. Però hi ha entorns (particularment a servidors compartits, arxius de projectes col·laboratius, departaments amb jerarquies d’accés poc rígides, o fins i tot NFS amb múltiples clients) on el model clàssic es queda curt. És on entren les ACLs (Access Control Lists), i amb elles, un grapat de comportaments poc evidents que convé tenir ben entesos abans de desplegar-les en producció.

El límit de rwx i quan saltar-s’ho

El sistema de permisos bàsic d’ Unix és simple i predictible: un propietari, un grup, i els altres. Això cobreix bé escenaris senzills, però no és suficient quan més d’un grup necessita accés diferenciat als mateixos recursos. És habitual veure dreceres com canviar el grup de l’arxiu segons el cas o tirar de scripts de cron que corregeixen permisos. Cap d’aquests pegats escala bé ni és net.

Les ACLs estenen aquest model permetent definir permisos addicionals per usuari o grup, més enllà del trio estàndard. Es poden aplicar a arxius o directoris específics sense reorganitzar estructures de grups o trencar convencions de permisos.

El primer que cal tenir clar és que les ACLs no substitueixen els permisos tradicionals. Els complementen. I quan entren en joc, la interpretació dels permisos es complica, especialment si es combinen malament o s’hereten sense control.

setfacl i getfacl: l’essencial, però amb context

setfacl i getfacl són les eines bàsiques. Són senzilles, però no trivials. Aquí uns exemples amb implicacions reals:

setfacl -m u:joan:r-- arxiu.txt

Això afegeix una regla explícita per a l’usuari, donant-li permís de lectura. Però si arxiu.txt tenia permisos rw——- i el propietari no és el mateix, llavors no podia fer res fins que s’hi va afegir aquesta ACL. Fàcil.

El que no és tan evident és això:

setfacl -m u:joan:r-- -m u:pere:rw- arxiu.txt

Això no reemplaça ACLs anteriors per a aquests usuaris. Les modifica o les afegeix si no existeixen. I si després fas:

setfacl -x u:joan arxiu.txt

S’elimina només aquesta entrada, sense tocar les altres ni els permisos base.

Per a veure el resultat:

getfacl arxiu.txt

L’important aquí és saber llegir la sortida. La clau està en les línies de tipus mask::. Aquesta màscara defineix el màxim nivell de permisos que s’aplicaran a totes les entrades d’usuari o grup addicionals (excepte el propietari i “altres”).

Un exemple clàssic d’error: se li dona rw- a un usuari mitjançant ACL, però no es revisa la mask, que té només r–. Resultat: no pot escriure, i ningú entén per què. Sempre revisar o ajustar la màscara:

setfacl -m mask::rw- arxiu.txt

També és habitual oblidar-se de l’herència en directoris. Per a establir ACLs per defecte (per a arxius i subdirectoris creats dins), es fa servir:

setfacl -m d:u:joan:rwx /ruta/compartida

Aquesta d: inicial indica una ACL per defecte. Però atenció: no afecta els arxius ja existents. Només als nous. Per aplicar ACLs, tant efectives com per defecte:

setfacl -Rm u:joan:rwX,d:u:joan:rwX /ruta/compartida

La X és útil: aplica x només si l’ objecte és un directori o ja tenia permís d’ execució. Evita convertir arxius de text en executables per error.

Interacció amb backup i restore

Aquí hi ha diverses trampes.

Primer, no totes les eines de backup gestionen ACLs per defecte. Algunes ni tan sols les suporten, d’altres ho fan només amb opcions addicionals.

tar

L’opció –acls és obligatòria si vols que les ACLs es conservin:

tar --acls -cf backup.tar /ruta/amb/acls

I per restaurar:

tar --acls -xf backup.tar

Sense aquesta opció, tot es guarda, però les ACLs es perden.

rsync

Aquest és un cas particularment delicat. Per defecte, rsync no conserva ACLs. Perquè ho faci:

rsync -a --acls origen/ desti/

Però això només funcionarà si tots dos extrems tenen ACLs al sistema d’arxius (per exemple, ext4 amb acl muntat). Si un dels dos no el suporta o no té les ACLs actives, l’opció s’ignora sense fer soroll. Resultat: un backup, sembla que tot està bé, però els accessos no funcionen com abans.

Una forma de validar això abans de llançar-se és fer getfacl sobre alguns arxius clau després del rsync, i comparar amb els originals.

Què passa si copio arxius amb cp?

No conserva ACLs llevat que s’indiqui explícitament. El flag –preserve=all inclou ACLs si el sistema ho permet:

cp --preserve=all arxiu destino/

Això pot generar problemes en moure o reorganitzar estructures on les ACLs són part del control d’ accés. Si no es conserven, els permisos col·lapsen el model tradicional, i usuaris que abans accedien es troben amb errors. El mateix amb mv, que no copia res, però pot moure entre sistemes amb o sense suport d’ACLs.

ACLs i NFS

Aquí entrem en terreny relliscós.

NFSv3 no suporta ACLs de forma nativa. Pots forçar alguns comportaments en combinació amb POSIX ACLs si el servidor i el client estan correctament configurats, però és inconsistent.

NFSv4 sí que els suporta, però té el seu propi model d’ACLs (tipus Windows NTFS), i no és compatible 1:1 amb les POSIX ACLs. Fins i tot a NFSv4, el que veus amb getfacl pot no ser el que realment interpreta el servidor.

Això implica que si treballes amb exportacions NFS i estàs fent servir ACLs per a gestionar accessos fins, cal:

• Validar que el servidor exporta el sistema d’ arxius amb suport ACL.
• Validar que el client munta amb suport ACL (i ho interpreta bé).
• Provar accessos amb usuaris reals, no assumir res basat només en permisos visibles.

A la pràctica, és millor evitar confiar en ACLs per a sistemes compartits per NFS tret que controlis ambdós extrems completament.

Herència, màscares i regles per defecte: errors persistents

Un dels errors més repetits és suposar que una ACL aplicada a un directori afecta tots els seus continguts. Ja ho hem dit, però ho repetim perquè és important. Cal diferenciar:

• ACL efectiva: el que aplica ara mateix a l’ arxiu.
• ACL per defecte: el que heretaran els nous objectes creats dins d’ un directori.

No són el mateix. L’ideal, quan es configura una jerarquia amb ACLs, és aplicar ambdues de forma recursiva des del començament:

setfacl -Rm u:joan:rwX,d:u:joan:rwX /data/projecte

I si hi ha molts usuaris, fer servir grups específics és més net:

setfacl -Rm g:analistes:rwX,d:g:analistes:rwX /data/projecte

Això evita haver d’afegir cada usuari un per un, i permet controlar accessos mitjançant la membresia de grups. Però compte amb la màscara (mask::) com vam comentar abans: si es defineix sense pensar, pot anul·lar permisos sense que es noti.

Quan evitar les ACLs?

Tot i que permeten una granularitat útil, no sempre són la millor solució.

• En entorns on l’ equip de suport no està familiaritzat amb elles.
• En sistemes on es fa backup amb eines que no les gestionen bé.
• On NFSv3 està en ús i els accessos han de ser consistents.
• Quan els problemes d’ accés es poden resoldre amb un redisseny mínim de grups i propietaris.

Les ACLs afegeixen una capa més de complexitat, i si no es documenten o s’auditen amb regularitat, poden esdevenir una font d’errors difícils de trobar.

Monitorització, scripting útil i revisions d’ integritat amb ACLs

Un dels punts menys tractats a la documentació formal sobre les ACLs és com mantenir-les sota control al llarg del temps. Una cosa és configurar ACLs de forma puntual, una altra de molt diferent és mantenir una estructura de permisos coherent, comprensible i recuperable en sistemes on aquestes llistes es fan servir activament. Aquí van algunes estratègies que poden ser pràctiques quan les ACLs ja són part del model operatiu.

1. Snapshot d’ACLs: auditoria i control de canvis

Quan es treballa amb estructures d’ arxius compartides en equip, convé guardar un estat conegut de les ACLs. No només per a la seva feina, també per restaurar permisos si algú els toca sense saber ben bé què està fent.

Una forma ràpida i efectiva:

cd /data/projectes
find . -type f -exec getfacl --absolute-names {} \; > /root/backup_acls_$(date +%F).txt

Per a directoris també:

find . -type d -exec getfacl --absolute-names {} \; >> /root/backup_acls_$(date +%F).txt

Aquest arxiu és llegible i pot ser restaurat amb alguna cosa com:

setfacl --restore=backup_acls_2025-08-05.txt

Això és útil si algú fa un chmod -R per error, o si es perd l’accés fi per copiar/moure estructures sense conservar ACLs. Val tant per a recuperació com per comparar versions amb diff.

2. Automatització de la verificació d’ACLs

Quan hi ha requisits de seguretat o traçabilitat, convé tenir un script que validi que certes rutes tinguin les ACLs mínimes esperades. Exemple: assegurar que tots els arxius sota /data/comptabilitat permetin lectura només al grup finances.

#!/bin/bash
 
ruta="/data/contabilitat"
grup="finances"
perm="r--"
 
find "$ruta" -type f | while read -r f; do
    acl=$(getfacl -cp "$f" | grep "^group:$grup:")
    if [[ "$acl" != "group:$grupo:$perm" ]]; then
        echo "Arxiu amb ACL incorrecta: $f"
    fi
done

Es pot estendre per detectar màscares restrictives, entrades que falten o permisos excessius.

3. Restauració programada d’ACLs

En entorns on els usuaris modifiquen sense voler els permisos (per exemple, carpetes compartides editades per aplicacions de tercers), pot tenir sentit reimposar ACLs periòdicament. Una solució no elegant, però funcional, és aplicar l’R cada nit des de cron amb un script de referència.

Exemple:

#!/bin/bash
BASE="/data/comercial"
setfacl -Rm g:vendes:rwX,d:g:vendes:rwX "$BASE"

Això evita sorpreses, sobretot quan es barregen serveis SMB/NFS i muntatges des de Windows, on els canvis de permisos es propaguen de vegades sense lògica clara.

ACLs i eines inesperades

Hi ha eines que poden fer malbé les ACLs sense voler. No perquè siguin agressives, sinó perquè simplement ignoren que existeixen.

rsnapshot, duplicity, rclone

• rsnapshot fa servir rsync per sota. Només respecta les ACLs si se li passa –acls a la configuració. Si no, les ignora.
• duplicity històricament no guarda ACLs. Si el backup es fa amb aquesta eina, cal assumir pèrdua de control de permisos fins.
• rclone, segons el backend, pot o no mantenir ACLs. En molts sistemes remots com S3, ni tan sols tenen un model ACL equivalent, per la qual cosa es perd tota la granularitat.

Conclusió: si els permisos són part del model de seguretat, no facis servir eines de backup que els ignorin.

Revisió i neteja d’ ACLs excessives

Un cop s’ha fet servir l’estructura completa, és habitual que els arxius acumulin entrades innecessàries. Hi ha arxius que no necessiten permisos fins, o que hereten entrades redundants que després dificulten la lectura de l’estat actual.

Per netejar entrades sense perdre funcionalitat, es pot fer servir setfacl –remove-all i després aplicar només les necessàries.

Una altra opció és revisar arxius amb ACLs actives no estàndard:

find /data/proyecto -type f -exec getfacl --omit-header {} \; | grep -E "user:|group:" | cut -d: -f2 | sort | uniq -c | sort -nr

Això dona una idea de quins usuaris o grups tenen moltes entrades ACL sobre arxius. Si hi ha centenars d’arxius amb entrades per a un usuari que ja no treballa al projecte, és moment de fer neteja.

Com evitar que ACLs ocultin errors de permisos

És molt fàcil que un arxiu sembli tenir accés denegat per “culpa del sistema”, quan en realitat hi ha una ACL amb màscara restrictiva o una herència inesperada. Per a evitar això, una pauta molt útil:

• Quan un usuari no pot accedir, no assumir que és pels permisos visibles (ls -l).
• Fer servir getfacl a l’ arxiu i a tots els directoris pares fins a l’ arrel del volum.
• Validar el resultat combinat: si el directori té una ACL per defecte i l’arxiu en té una altra, i hi ha una màscara que retalla permisos, cal veure la interacció completa.

De vegades el problema ni tan sols és a l’arxiu, sinó en un directori intermedi sense permís d’execució per a aquest usuari.

Quan les ACLs resolen problemes, i quan no

Sí que convé fer servir ACLs quan:

• Hi ha un conjunt d’ arxius que han de ser accessibles per diferents grups de treball, amb permisos diferents, sense replicar l’ estructura.
• Es necessita una solució ràpida per a donar accés temporal a un usuari sense tocar grups globals.
• Les aplicacions generen arxius sota una estructura compartida i l’umask no és suficient per a imposar els permisos adequats.
• Hi ha un sistema multiusuari en què els canvis de grup constants són un risc operatiu.

No convé fer servir ACLs quan:

• L’ equip d’ operacions no té coneixement bàsic per interpretar getfacl.
• Les eines de suport no les conserven, i restaurar permisos manualment és inviable.
• La solució es pot reestructurar amb un grup addicional i un chmod -R ben planejat.
• Hi ha auditories o normatives que exigeixen traçabilitat clara de permisos i no es disposa de scripts per documentar i validar ACLs.

Recomanacions operatives

• Muntar sempre els sistemes d’ arxius amb acl activat si es faran servir. A ext4, per exemple, tot i que és habitual que ja hi sigui, confirmar-ho amb mount | grep acl.
• Embolcalls de backup/restauració que considerin ACLs com a part de l’estructura.
• Documentar les regles d’ accés a arxius README dins dels propis directoris controlats. No substitueix una política formal, però redueix la fricció.
• Validar les ACLs després de rsync, resta, mv i altres moviments massius.
• Evitar ACLs sobre estructures d’ arxius que se sincronitzen entre servidors amb eines que no les entenen.

Conclusió

Les ACLs no són complexes, però sí que tenen més estats intermedis que el sistema de permisos clàssic. El que cal no és més teoria, sinó integrar-les bé al model d’operacions i saber quines eines les entenen i quines no. Si es documenten, s’ auditen i es restauren correctament, resolen problemes reals sense introduir-ne de nous. Si s’apliquen sense pensar, poden ser una trampa difícil de detectar. Com gairebé tot en l’administració de sistemes, la diferència està en els detalls que es validen i els que s’assumeixen.