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

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

Utilizzo client

klog –principal username

• Permette di autenticarsi come un qualunque utente del servizio AFS

tokens

• Visualizza lo stato di autenticazione

Utilizzo clientConsideriamo de utenti: palumbo e carlosSiano entrambi utenti AFS, solo il primo è un reale utente del sistema

operativo:[palumbo@localhost~] iduid=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~] klogPassword:

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~] tokensToken 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~] iduid=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~] klogToken held by Cache Manager:User’s (AFS ID 7021) tokens for afs@Italia[palumbo@localhost~] klog andrei –cell infn.itToken held by Cache Manager:User’s (AFS ID 7021) tokens for afs@ItaliaUser’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_nameDistrugge il token acquisito per la cella specificata

Gestione delle utenzeGli 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 ptserverComandi 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

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:– (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/secretAccess list for /afs/project/secret isNormal 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 esempioSupponiamo 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/commonAccess list for /afs/project/common isNormal rights: gruppo1 rlidwka gruppo2 rlidwka

system:authuser rlNegative rights:

ruggero idwka