non sono presenti su un classico filesystem di tipo Unix; le principali sono
le seguenti:
\begin{itemize}
-\item i \textit{file attributes} consentono di modificare il comportamento del
- kernel quando agisce su gruppi di file. Possono essere impostati su file e
- directory e in quest'ultimo caso i nuovi file creati nella directory
- ereditano i suoi attributi.
+\item gli attributi estesi (vedi sez.~\ref{sec:file_xattr}) che consentono di
+ estendere le informazioni salvabili come metadati e le ACL (vedi
+ sez.~\ref{sec:file_ACL}) che consentono di estendere il modello tradizionale
+ dei permessi sui file.
\item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
montaggio. La semantica BSD comporta che i file in una directory sono creati
con lo stesso identificatore di gruppo della directory che li contiene. La
dell'\textit{inode} (evitando letture multiple e spreco di spazio), non
tutti i nomi però possono essere gestiti così per limiti di spazio (il
limite è 60 caratteri).
-\item vengono supportati i file immutabili (che possono solo essere letti) per
- la protezione di file di configurazione sensibili, o file
- \textit{append-only} che possono essere aperti in scrittura solo per
- aggiungere dati (caratteristica utilizzabile per la protezione dei file di
- log).
+\item vengono supportati \itindex{file~attributes} i cosiddetti \textit{file
+ attributes} che attivano comportamenti specifici per i file su cui vengono
+ attivati come marcarli come immutabili (che possono cioè essere soltanto
+ letti) per la protezione di file di configurazione sensibili, o come
+ \textit{append-only} (che possono essere aperti in scrittura solo per
+ aggiungere dati) per la protezione dei file di log.
\end{itemize}
La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD: un
cui \param{filename} sia un collegamento simbolico saranno modificati i suoi
tempi invece di quelli del file a cui esso punta.
-Nonostante il kernel, come accennato, supporti risoluzioni dei tempi dei file
-fino al nanosecondo, le funzioni fin qui esaminate non consentono di impostare
-valori con questa precisione. Per questo sono state introdotte due nuove
-funzioni, \funcd{futimens} e \func{utimensat}, in grado di eseguire questo
-compito; i rispettivi prototipi sono:
+Nonostante il kernel nelle versioni più recenti supporti, come accennato,
+risoluzioni dei tempi dei file fino al nanosecondo, le funzioni fin qui
+esaminate non consentono di impostare valori con questa precisione. Per questo
+sono state introdotte due nuove funzioni di sistema, \funcd{futimens} e
+\funcd{utimensat}, in grado di eseguire questo compito; i rispettivi prototipi
+sono:
\begin{funcproto}{
\fhead{sys/time.h}
timespec times[2], int flags)}
\fdesc{Cambia i tempi di un file.}
}
+
{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EBADF}] da fare
+ \item[\errcode{EACCES}] si è richiesta l'impostazione del tempo corrente ma
+ non si ha il permesso di scrittura sul file, o non si è proprietari del
+ file o non si hanno i privilegi di amministratore; oppure il file è
+ immutabile (vedi sez.~\ref{sec:file_perm_overview}).
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor valido (solo
+ \func{futimens}), oppure \param{dirfd} non è \const{AT\_FDCWD} o un file
+ descriptor valido (solo \func{utimensat}).
+ \item[\errcode{EFAULT}] \param{times} non è un puntatore valido (per
+ entrambe), oppure \param{dirfd} è \const{AT\_FDCWD} ma \param{pathname} è
+ \var{NULL} o non è un puntatore valido (solo \func{utimensat}).
+ \item[\errcode{EINVAL}] si sono usati dei valori non corretti per i tempi
+ di \param{times} (per entrambe), oppure è si usato un valore non valido
+ per \param{flags}, oppure \param{pathname} è \var{NULL}, \param{dirfd} non
+ è \const{AT\_FDCWD} e \param{flags} contiene \const{AT\_SYMLINK\_NOFOLLOW}
+ (solo \func{utimensat}).
+ \item[\errcode{EPERM}] si è richiesto un cambiamento nei tempi non al tempo
+ corrente, ma non si è proprietari del file o non si hanno i privilegi di
+ amministratore; oppure il file è \itindex{file~attributes} immutabile o
+ \textit{append-only} (vedi sez.~\ref{sec:file_perm_overview}).
+ \item[\errcode{ESRCH}] non c'è il permesso di attraversamento per una delle
+ componenti di \param{pathname} (solo \func{utimensat})
\end{errlist}
- ed inoltre nel loro significato generico.}
+ ed inoltre per entrambe \errval{EROFS} e per \func{utimensat}
+ \errval{ELOOP}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel
+ loro significato generico.}
\end{funcproto}
Entrambe le funzioni utilizzano per indicare i valori dei tempi un
-vettore \param{times} di due strutture \struct{timespec} che permette di
-specificare un valore di tempo con una precisione fino al nanosecondo, la cui
-definizione è riportata in fig.~\ref{fig:sys_timespec_struct}.
+vettore \param{times} di due strutture \struct{timespec}, la cui definizione è
+riportata in fig.~\ref{fig:sys_timespec_struct}, che permette di specificare
+un valore dei tempi con una precisione fino al nanosecondo.
\begin{figure}[!htb]
\footnotesize \centering
\var{tv\_nsec} il corrispondente valore di \var{tv\_sec} viene ignorato.
Queste due funzioni sono una estensione definita nella revisione POSIX.1-2008
-dello standard POSIX; sono state introdotte a partire dal kernel 2.6.22, e
-supportate dalla \acr{glibc} a partire dalla versione 2.6.\footnote{in
- precedenza, a partire dal kernel 2.6.16, era stata introdotta la funzione
- \funcm{futimesat} seguendo una bozza della revisione dello standard poi
- modificata, questa funzione, sostituita da \func{utimensat}, è stata
- dichiarata obsoleta, non è supportata da nessuno standard e non deve essere
- più utilizzata: pertanto non la tratteremo.} La prima è sostanzialmente una
-estensione di \func{futimes} che consente di specificare i tempi con
-precisione maggiore, la seconda supporta invece, rispetto ad \func{utimes},
-una sintassi più complessa che, come vedremo in sez.~\ref{sec:file_openat}
-consente una indicazione sicura dei \itindsub{pathname}{relativo}
-\textit{pathname relativi} specificando la directory da usare come riferimento
-in \param{dirfd} e la possibilità di usare per \param{flags} il valore
-\const{AT\_SYMLINK\_NOFOLLOW} per indicare alla funzione di non dereferenziare
-i collegamenti simbolici; si rimanda pertanto la spiegazione del significato
-degli argomenti aggiuntivi alla trattazione generica delle varie funzioni che
-usano la stessa sintassi, effettuata in sez.~\ref{sec:file_openat}.
+dello standard POSIX, in Linux sono state introdotte a partire dal kernel
+2.6.22,\footnote{si tenga presente però che per kernel precedenti il 2.6.26 le
+ due funzioni sono difettose nel rispetto di alcuni requisiti minori dello
+ standard e nel controllo della correttezza dei tempi, per i dettagli dei
+ quali si rimanda alla pagina di manuale.} e supportate dalla \acr{glibc} a
+partire dalla versione 2.6.\footnote{in precedenza, a partire dal kernel
+ 2.6.16, era stata introdotta una \textit{system call} \funcm{futimesat}
+ seguendo una bozza della revisione dello standard poi modificata; questa
+ funzione, sostituita da \func{utimensat}, è stata dichiarata obsoleta, non è
+ supportata da nessuno standard e non deve essere più utilizzata: pertanto
+ non ne parleremo.} La prima è sostanzialmente una estensione di
+\func{futimes} che consente di specificare i tempi con precisione maggiore, la
+seconda supporta invece, rispetto ad \func{utimes}, una sintassi più complessa
+che consente una indicazione sicura del file su cui operare specificando la
+directory su cui si trova tramite il file descriptor \param{dirfd} ed il suo
+nome come \itindsub{pathname}{relativo} \textit{pathname relativo}
+in \param{pathname}.\footnote{su Linux solo \func{utimensat} è una
+ \textit{system call} e \func{futimens} è una funzione di libreria, infatti
+ se \param{pathname} è \var{NULL} \param{dirfd} viene considerato un file
+ descriptor ordinario e il cambiamento del tempo applicato al file
+ sottostante, qualunque esso sia, per cui \code{futimens(fd, times}) è del
+ tutto equivalente a \code{utimensat(fd, NULL, times, 0)}.}
+
+Torneremo su questa sintassi e sulla sua motivazione in
+sez.~\ref{sec:file_openat}, quando tratteremo tutte le altre funzioni (le
+cosiddette funzioni \textit{at}) che la utilizzano; essa prevede comunque
+anche la presenza dell'argomento \param{flags} con cui attivare flag di
+controllo che modificano il comportamento della funzione, nel caso specifico
+l'unico valore consentito è \const{AT\_SYMLINK\_NOFOLLOW} che indica alla
+funzione di non dereferenziare i collegamenti simbolici, cosa che le permette
+di riprodurre le funzionalità di \func{lutimes}.
+
+
\section{Il controllo di accesso ai file}
Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
del controllo di accesso ai file, che viene implementato per qualunque
filesystem standard.\footnote{per standard si intende che implementa le
- caratteristiche previste dallo standard POSIX; in Linux sono disponibili
- anche una serie di altri filesystem, come quelli di Windows e del Mac, che
- non supportano queste caratteristiche.} In questa sezione ne esamineremo i
-concetti essenziali e le funzioni usate per gestirne i vari aspetti.
+ caratteristiche previste dallo standard POSIX; in Linux sono utilizzabili
+ anche filesystem di altri sistemi operativi, che non supportano queste
+ caratteristiche.} In questa sezione ne esamineremo i concetti essenziali e
+le funzioni usate per gestirne i vari aspetti.
\subsection{I permessi per l'accesso ai file}
\label{sec:file_perm_overview}
-Ad ogni file Linux associa sempre l'utente che ne è proprietario (il
-cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo
-degli identificatori di utente e gruppo (\ids{UID} e \ids{GID}). Questi valori
-sono accessibili da programma tramite la funzione \func{stat}, e sono
-mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura
-\struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo
- per filesystem di tipo Unix, ad esempio non è vero per il filesystem vfat di
- Windows, che non fornisce nessun supporto per l'accesso multiutente, e per
- il quale i permessi vengono assegnati in maniera fissa con un opzione in
- fase di montaggio.}
+Ad ogni file Linux associa sempre, oltre ad un insieme di permessi, l'utente
+che ne è proprietario (il cosiddetto \textit{owner}) ed un gruppo di
+appartenenza, indicati dagli identificatori di utente e gruppo (\ids{UID} e
+\ids{GID}) di cui abbiamo già parlato in
+sez.~\ref{sec:proc_access_id}.\footnote{questo è vero solo per filesystem di
+ tipo Unix, ad esempio non è vero per il filesystem VFAT di Windows, che non
+ fornisce nessun supporto per l'accesso multiutente, e per il quale queste
+ proprietà vengono assegnate in maniera fissa con opportune opzioni di
+ montaggio.} Anche questi sono mantenuti \index{itinode} sull'\textit{inode}
+insieme alle altre proprietà e sono accessibili da programma tramite la
+funzione \func{stat} (trattata in sez.~\ref{sec:file_stat}), che restituisce
+l'utente proprietario nel campo \var{st\_uid} ed il gruppo proprietario nel
+campo \var{st\_gid} della omonima struttura \struct{stat}.
Il controllo di accesso ai file segue un modello abbastanza semplice che
prevede tre permessi fondamentali strutturati su tre livelli di accesso.
\itindex{Access~Control~List~(ACL)} \textit{Access Control List} che sono
state aggiunte ai filesystem standard con opportune estensioni (vedi
sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di controllo ancora più
- sofisticati come il \textit{mandatory access control} di SE-Linux.} ma nella
-maggior parte dei casi il meccanismo standard è più che sufficiente a
-soddisfare tutte le necessità più comuni. I tre permessi di base associati ad
-ogni file sono:
+ sofisticati come il \itindex{Mandatory~Access~Control~(MAC)}
+ \textit{mandatory access control} di SE-Linux e delle altre estesioni come
+ \textit{Smack} o.} ma nella maggior parte dei casi il meccanismo standard è
+più che sufficiente a soddisfare tutte le necessità più comuni. I tre
+permessi di base associati ad ogni file sono:
\begin{itemize*}
\item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
\textit{read}).
\itindex{sgid~bit} \textit{sgid bit}, e \itindex{sticky~bit} \textit{sticky
bit}) sono usati per indicare alcune caratteristiche più complesse del
meccanismo del controllo di accesso su cui torneremo in seguito (in
-sez.~\ref{sec:file_special_perm}); lo schema di allocazione dei bit è
-riportato in fig.~\ref{fig:file_perm_bit}.
-
-Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
-memorizzati \itindex{inode} nell'\textit{inode}; in particolare essi sono
-contenuti in alcuni bit del campo \var{st\_mode} della struttura \struct{stat}
+sez.~\ref{sec:file_special_perm}), lo schema di allocazione dei bit è
+riportato in fig.~\ref{fig:file_perm_bit}. Come tutte le altre proprietà di
+una file anche i permessi sono memorizzati \itindex{inode}
+nell'\textit{inode}, e come accennato in sez.~\ref{sec:file_types} essi sono
+contenuti in una parte del campo \var{st\_mode} della struttura \struct{stat}
(si veda di nuovo fig.~\ref{fig:file_stat_struct}).
In genere ci si riferisce ai tre livelli dei privilegi usando le lettere
\texttt{u} (per \textit{user}), \texttt{g} (per \textit{group}) e \texttt{o}
(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
insieme si usa la lettera \texttt{a} (per \textit{all}). Si tenga ben presente
-questa distinzione dato che in certi casi, mutuando la terminologia in uso nel
-VMS, si parla dei permessi base come di permessi per \textit{owner},
-\textit{group} ed \textit{all}, le cui iniziali possono dar luogo a
-confusione. Le costanti che permettono di accedere al valore numerico di
-questi bit nel campo \var{st\_mode} sono riportate in
+questa distinzione dato che in certi casi, mutuando la terminologia in uso a
+suo tempo nel VMS, si parla dei permessi base come di permessi per
+\textit{owner}, \textit{group} ed \textit{all}, le cui iniziali possono dar
+luogo a confusione. Le costanti che permettono di accedere al valore numerico
+di questi bit nel campo \var{st\_mode}, già viste in
+tab.~\ref{tab:file_mode_flags}, sono riportate per chiarezza in
tab.~\ref{tab:file_bit_perm}.
\begin{table}[htb]
\textit{pathname} occorre il permesso di esecuzione in ciascuna delle
directory che compongono il \textit{pathname}; lo stesso vale per aprire un
file nella directory corrente (per la quale appunto serve il diritto di
-esecuzione).
-
-Per una directory infatti il permesso di esecuzione significa che essa può
-essere attraversata nella risoluzione del \textit{pathname}, ed è distinto dal
-permesso di lettura che invece implica che si può leggere il contenuto della
-directory.
+esecuzione). Per una directory infatti il permesso di esecuzione significa che
+essa può essere attraversata nella risoluzione del \textit{pathname}, e per
+questo viene anche chiamato permesso di attraversamento. Esso è sempre
+distinto dal permesso di lettura che invece implica che si può leggere il
+contenuto della directory.
Questo significa che se si ha il permesso di esecuzione senza permesso di
-lettura si potrà lo stesso aprire un file in una directory (se si hanno i
-permessi opportuni per il medesimo) ma non si potrà vederlo con \cmd{ls}
-(mentre per crearlo occorrerà anche il permesso di scrittura per la
-directory).
+lettura si potrà lo stesso aprire un file all'interno di una una directory (se
+si hanno i permessi adeguati per il medesimo) ma non si potrà vederlo con
+\cmd{ls} mancando il permesso di leggere il contenuto della directory. Per
+crearlo o rinominarlo o cancellarlo invece occorrerà avere anche il permesso
+di scrittura per la directory.
Avere il permesso di lettura per un file consente di aprirlo con le opzioni
(si veda quanto riportato in tab.~\ref{tab:file_open_flags}) di sola lettura o
esecuzione e di quello di scrittura per la directory di destinazione; gli
stessi permessi occorrono per cancellare un file da una directory (si ricordi
che questo non implica necessariamente la rimozione del contenuto del file dal
-disco), non è necessario nessun tipo di permesso per il file stesso (infatti
-esso non viene toccato, viene solo modificato il contenuto della directory,
-rimuovendo la voce che ad esso fa riferimento).
+disco). Per la cancellazione non è necessario nessun tipo di permesso per il
+file stesso dato che, come illustrato in sez.~\ref{sec:link_symlink_rename}
+esso non viene toccato, nella cancellazione viene solo modificato il contenuto
+della directory, rimuovendo la voce che ad esso fa riferimento.
Per poter eseguire un file (che sia un programma compilato od uno script di
-shell, od un altro tipo di file eseguibile riconosciuto dal kernel), occorre
-avere il permesso di esecuzione, inoltre solo i file regolari possono essere
-eseguiti.
+shell, od un altro tipo di file eseguibile riconosciuto dal kernel), occorre,
+oltre al permesso di lettura per accedere al contenuto, avere anche il
+permesso di esecuzione. Inoltre solo i file regolari possono essere eseguiti.
I permessi per un collegamento simbolico sono ignorati, contano quelli del
file a cui fa riferimento; per questo in genere il comando \cmd{ls} riporta
proprietario del file (nel qual caso si dice che il processo è proprietario
del file) allora:
\begin{itemize*}
- \item se il relativo\footnote{per relativo si intende il bit di user-read se
- il processo vuole accedere in lettura, quello di user-write per
- l'accesso in scrittura, ecc.} bit dei permessi d'accesso dell'utente è
- impostato, l'accesso è consentito
- \item altrimenti l'accesso è negato
+ \item se il relativo\footnote{per relativo si intende il bit di
+ \textit{user-read} se il processo vuole accedere in lettura, quello di
+ \textit{user-write} per l'accesso in scrittura, ecc.} bit dei permessi
+ d'accesso dell'utente è impostato, l'accesso è consentito;
+ \item altrimenti l'accesso è negato.
\end{itemize*}
\item Se il \ids{GID} effettivo del processo o uno dei \ids{GID} supplementari
dei processi corrispondono al \ids{GID} del file allora:
\begin{itemize*}
\item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
- consentito,
- \item altrimenti l'accesso è negato
+ consentito;
+ \item altrimenti l'accesso è negato.
\end{itemize*}
\item Se il bit dei permessi d'accesso per tutti gli altri è impostato,
l'accesso è consentito, altrimenti l'accesso è negato.
processo appartiene ad un gruppo appropriato, in questo caso i permessi per
tutti gli altri non vengono controllati.
+\itindbeg{file~attributes}
+A questi che sono i permessi ordinari si aggiungono, per i filesystem che
+supportano questa estensione, due permessi speciali mantenuti nei cosiddetti
+\textit{file attributes}, che si possono leggere ed impostare con i comandi
+\cmd{lsattr} e \cmd{chattr}.\footnote{per l'utilizzo di questo comando e le
+ spiegazioni riguardo gli altri \textit{file attributes} si rimanda alla
+ sezione 1.4.4 di \cite{AGL}.}
+
+Il primo è il cosiddetto attributo di immutabilità (\textit{immutable},
+identificato dalla lettera \texttt{i}) che impedisce ogni modifica al file,
+\textit{inode} compreso. Questo significa non solo che non se ne può cambiare
+il contenuto, ma neanche nessuno dei metadati, ed in particolare non si può
+cancellare, rinominare, modificare nei permessi o nei tempi, o creare
+\textit{hard link} verso di esso.
+
+Il secondo è il cosiddetto attributo di \textit{append-only}, (identificato
+dalla lettera \texttt{a}) che consente soltanto la scrittura del file in coda
+al file. Il file cioè può essere soltanto esteso, ma i suoi metadati, a parte
+i tempi che può però possono essere impostati al valore corrente, non possono
+essere modificati, quindi di nuovo non si potrà cancellare, rinominare, o
+modificare nei permessi.
+
+Entrambi questi attributi attivano queste proprietà a livello di filesytem,
+per cui a differenza dei permessi ordinari esse varranno per qualunque utente
+compreso l'amministratore. L'amministratore è l'unico che può attivare o
+disattivare questi attributi,\footnote{più precisamente un processo con la
+ \itindex{capabilities} capacità \const{CAP\_LINUX\_IMMUTABLE}.} e potendo
+rimuoverli è comunque capace di tornare in grado di eseguire qualunque
+operazione.
+\itindbeg{file~attributes}
+
+
\subsection{I bit dei permessi speciali}
\label{sec:file_special_perm}
2.4).\\
\const{CAP\_LINUX\_IMMUTABLE}& La capacità di impostare sui file gli
attributi \textit{immutable} e
- \itindex{append~mode} \textit{append only} (se
- supportati).\\
+ \itindex{append~mode} \textit{append-only} (vedi
+ sez.~\ref{sec:file_perm_overview}) se
+ supportati.\\
\const{CAP\_MKNOD} & La capacità di creare
\index{file!di~dispositivo} file di dispositivo
con \func{mknod} (vedi
projects / gapil.git / commitdiff