AFS Andrew File System

AFS: Andrew File System AFS e' un File System distribuito che permette la condivisione di file tra macchine UNIX su reti LAN e WAN utilizzando il modello Client/Server. AFS viene sviluppato, mantenuto e commercializzato dalla TRANSARC corporation AFS fu originariamente sviluppata da Transarc, ora di proprieta' di IBM. Versione open per linux www.openafs.org Si puo' scaricare la documentazione IBM originale. http://www.gentoo.it/doc/openafs-guida-it.html per l’installazione . Questo prodotto non e' un applicativo, bensi' un prodotto che integra il sistema operativo a livello di kernel; esso infatti modifica la struttura interna del file system di Unix. Per questo motivo e' necessaria una particolare installazione che talvolta comporta la ricostruzione del kernel della macchina e la sostituzione di alcuni comandi che interagiscono con il file system e il logging.

Che cosa e' AFS?  AFS e' basato su un file system distribuito "The Andrew FileSystem". "Andrew" era il nome del progetto di ricerca al CMU, in onore al fondatore dell'universita'. Quando Transarc si formo' e AFS divenne un prodotto commerciale, "Andrew" fu abbandonato per indicare che AFS era andato piu' lontano del progetto di ricerca ed era diventato un file system di qualita' supportato. D'altra parte, c'erano un discreto numero di celle esistenti che avevno il loro filesystem montato come /afs. Al tempo, cambiare la radice del filesystem non fu una cosa banale. Cosi' per evitare di dover modificare i vecchi siti rimoniando i filesystem, AFS rimase con il nome e con la radice originale. Che cosa e' una cella AFS?  Un cella AFS e' un insieme di servers legati da una stessa entita' amministrativa e presentano un filesystem singolo. Tipicamente una cella AFS e' un isieme di hosts che usano lo stesso nome di dominio Internet (ad esempio, gentoo.org). Gli utenti effettuano il login nelle workstations AFS le quali richiedono informazioni e files dai servers della cella per conto degli utenti. Gli utenti non sanno e non vogliono sapere in quale server e' localizzato il/i files a cui vogliono accedere. Loro non avranno mai informazioni se un server si trova in un'altra stanza, poiche' ogni volume puo' essere replicato e spostato da un server all'altro senza che un utente se ne accorga. I files rimangono sempre accessibili. Quali sono i vantaggi dell'utilizzo di AFS?  I punti di forza principali di AFS sono: utilizzo della cache su disco (dal lato client, tipicamente da 100M a 1GB), sicurezza (AFS si basa su Kerberos 4, access control lists), semplicita' di indirizzamento (si utilizza solo un filesystem), scalabilita' (si aggiungono servers aggiuntivi alla cella al bisogno), utilizzo di protocolli di comunicazione.

Caratteristiche principali Si tratta di un File System con controllo selettivo di accesso ai files La sicurezza di AFS è basata su Kerberos Nato con il consolidamento della prima versione di Kerberos (V4) Non è ancora migrato verso la nuova versione (V5: una versione più flessibile e ricca di opzioni)

Architettura del sistema Le funzioni di autenticazione sono affidate ad un processo kaserver Kaserver: ricopre il ruolo di Kerberos Server e Ticket Granter (quindi funziona come il KDC di Kerberos)

Architettura del sistema (II) Le funzioni di autorizzazione sono legate ad un processo ptserver. Ptserver: gestisce degli identificativi numerici, “AFS Userid”, messi in corrispondenza degli identificativi Kerberos Tali identificativi regolano le autorizzazioni per l’accesso selettivo ai files

Meccanismo di funzionamento Al momento dell’autenticazione presso il servizio AFS il processo client ottiene un “Token AFS”. Il Token AFS contiene la session key necessaria per ottenere il servizio da tutti i file server della cella Contiene anche: Tempo di validità del token Informazioni dell’utente

Due tipi di token Una volta ottenuto un token, questo viene mantenuto in memoria dal processo Cache Manager che gira su ogni macchina client Il Cache Manager presenta tale token quando occorre una richiesta di accesso a file Esistono due modalità vincolare il token alla sessione di lavoro

(“Unix UserID”, “AFS UserID”)=(x,y) Token basato su UnixID Nel primo caso è possibile associare il token allo userid Unix In tal caso l’utente dopo l’autenticazione AFS, viene generata la seguente corrispondenza (“Unix UserID”, “AFS UserID”)=(x,y) Tutti i processi con Unix_UserID= x potranno godere dei privilegi di accesso concessi ai profili AFS_UserID=y

Svantaggi Se l’utente root esegue il comando: su username Acquista i diritti di accesso dell’utente username che non è detto gli spettino

Token basato su PAG Il secondo tipo di token è legato all’utilizzo di una shell speciale: “pagsh” PAG= Process Autentication Group Il PAG è un numero che serve ad identificare l’utente che lavora in una pagshell concreta. Se l’autenticazione avviene all’interno di una pag_shell il token AFS viene associato al particolare PAG Ogni invocazione del comando pagsh crea un nuovo PAG

Toke basato su PAG Tutti i processi lanciati all’interno di una pag-shell ereditano direttamente il token AFS legato a quel PAG qualunque sia lo UnixID dell’utente Il comando suid non determina cambiamenti rispetto ai privilegi acquisiti nello spazio AFS

klog –principal username Utilizzo client klog –principal username Permette di autenticarsi come un qualunque utente del servizio AFS tokens Visualizza lo stato di autenticazione

Utilizzo client Consideriamo de utenti: palumbo e carlos Siano entrambi utenti AFS, solo il primo è un reale utente del sistema operativo: [palumbo@localhost~] id uid=7023 (palumbo) gid=20053 (bb) groups=20053 (bb) Accedendo al sistema come palumbo utilizziamo il comando klog per autenticarci presso il servizio AFS: [palumbo@localhost~] klog Password: Dopo aver digitato la password si ottiene il token AFS per l’utente palumbo

Utilizzo client In questo caso, trovandoci all’esterno din una pagsh il token AFS viene associato allo UnixID Digitando il comando tokens: [palumbo@localhost~] tokens Token held by Cache Manager: User’s (AFS ID 7021) tokens for afs@Italia Italia rappresenta una cella del filesystem AFS

Utilizzo client Volendo dall’utente palumbo accedere al servizio AFS come altro utente: [palumbo@localhost~] klog carlos [palumbo@localhost~] tokens Token held by Cache Manager: User’s (AFS ID 838) tokens for afs@Italia Bisogna notare che si può possedere un solo token AFS per cella

PAGSH Digitando il comando: [palumbo@localhost~] pagsh [palumbo@localhost~] id uid=7023 (palumbo) gid=20053 (bb) groups=33868, 34776, 20053 (bb) Ci sono due nuovi gruppi che non appartengono a quelli del sistema operativo Tali identificativi sono utilizzati per associare i token presi in questa shell ai processi in esecuzione nella shell stessa

PAGSH [palumbo@localhost~] klog Token held by Cache Manager: User’s (AFS ID 7021) tokens for afs@Italia [palumbo@localhost~] klog andrei –cell infn.it User’s (AFS ID 23355) tokens for afs@infn.it Come si vede dall’output del comando è possibile avere token relativi a celle diverse [palumbo@localhost~] unlog –cell cell_name Distrugge il token acquisito per la cella specificata

Gestione delle utenze Gli AFS UserID e gli AFS GroupID che permettono di raggruppare logicamente gli UserId sono contenuti in un database PDB= AFS Protection Data Base Il PDB viene gestito dal processo ptserver Comandi appositi permettono di: aggiungere e rimuovere gruppi e utenti rinominare gruppi e utenti Aggiungere utenti ad un gruppo Esistono utenze speciali: Il gruppo system:authuser hai id -102 e comprende tutti gli utenti dotati in un momento di un token AFS non scaduto

“PDBuid-permessi” “PDBgid-permessi” Protezione dei files Ogni directory all’interno dell’albero /afs possiede una ACL (Access Control List) Un ACL è strutturata secondo una serie di permessi: “PDBuid-permessi” “PDBgid-permessi” In fase di autorizzazione si ricerca l’ID dell’utente nella ACL interessata

Permessi Esistono 7 permessi: Permessi sulle directories (l,i,d,a) riguardano le operazioni su directories (r,w,k) si riferiscono ai files contenuti in esse Permessi sulle directories l lookup: consente di effettuare ls, cd , controllare l’ACL sulla directory i insert: consente di creare nuovi file, directories d delete: consente di rimuovere o rinominare nuovi file, directories a administer: consente di modificare l’ACL r read: consente di leggere il contenuto dei files w write: consente di modificare i files k lock: consente di eseguire programmi che effettuano chiamate flock su i files

Permessi Unix e Permessi AFS Per le directory i permessi Unix sono ignorati Per i file: I bit per i gruppi e il proprietario vengono ignorati I bit di user vengono considerati con delle eccezioni Se i permessi unix sono assenti quelli AFS non contano Se i permessi unix sonpo presenti si va a controllare quelli AFS prima di concedere l’accesso

Manipolazione delle ACL Il comando utilizzato è fs Verranno discussi i comandi: fs setaccess: modificare un ACL fs listaccess: visualizzare un ACL fs copyacl: copiare un ACL da una directory su un’altra

Un esempio Considerimo due directory: /afs/project/secret /afs/project/common Vogliamo dare tutti i permessi sulla prima directory solo a gruppo1 Vogliamo dare tutti i permessi sulla seconda directory a gruppo1 e gruppo2 Vogliamo dare solo sulla directory i permessi di lettura ai restanti utenti

Un esempio # fs sa /afs/project/secret gruppo1 all –clear # fs sa /afs/project/common gruppo1 all \ gruppo2 all system:authuser read Verifichiamo i permessi: # fs la /afs/project/secret Access list for /afs/project/secret is Normal rights: gruppo1 rlidwka

Un esempio Verifichiamo i permessi: # fs la /afs/project/common Access list for /afs/project/common is Normal rights: gruppo1 rlidwka gruppo2 rlidwka system:authuser rl

Un esempio Supponiamo ora di voler escludere l’utente ruggero del gruppo2 dal poter modificare i file della cartella common: # fs sa /afs/project/common –negative ruggero idwka Verifichiamo i permessi: # fs la /afs/project/common Access list for /afs/project/common is Normal rights: gruppo1 rlidwka gruppo2 rlidwka system:authuser rl Negative rights: ruggero idwka