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
specifica di Linux che usa la omonima \textit{system call} e non è
portabile.}
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/mount.h}
\fdecl{mount(const char *source, const char *target, const char
*filesystemtype, \\
``\textsl{smontarlo}'' usando la funzione di sistema \funcd{umount}, il cui
prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/mount.h}
\fdecl{umount(const char *target)}
\fdesc{Smonta un filesystem.}
consente un maggior controllo delle operazioni, come forzare lo smontaggio di
un filesystem anche quando questo risulti occupato; il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/mount.h}
\fdecl{umount2(const char *target, int flags)}
\fdesc{Smonta un filesystem.}
diretta informazioni riguardo al filesystem su cui si trova un certo file,
sono \funcd{statfs} e \funcd{fstatfs}, i cui prototipi sono:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/vfs.h}
\fdecl{int statfs(const char *path, struct statfs *buf)}
\fdecl{int fstatfs(int fd, struct statfs *buf)}
viene denominato ``\textsl{collegamento diretto}'' (o \textit{hard link}), si
deve usare la funzione di sistema \funcd{link}, il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{unistd.h}
\fdecl{int link(const char *oldpath, const char *newpath)}
\fdesc{Crea un nuovo collegamento diretto (\textit{hard link}).}
sistema che permette di creare un nuovo collegamento simbolico è
\funcd{symlink}, ed il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{unistd.h}
\fdecl{int symlink(const char *oldpath, const char *newpath)}
\fdesc{Crea un nuovo collegamento simbolico (\textit{symbolic link}).}
esso fa riferimento. Quando si vuole leggere il contenuto di un collegamento
simbolico si usa la funzione di sistema \funcd{readlink}, il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{unistd.h}
\fdecl{int readlink(const char *path, char *buff, size\_t size)}
\fdesc{Legge il contenuto di un collegamento simbolico.}
nome come si può notare ha poco a che fare con il concetto di rimozione, è
\funcd{unlink}, ed il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{unistd.h}
\fdecl{int unlink(const char *pathname)}
\fdesc{Cancella un file.}
unix-like \funcd{remove} è equivalente ad usare in maniera trasparente
\func{unlink} per i file ed \func{rmdir} per le directory; il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{stdio.h}
\fdecl{int remove(const char *pathname)}
\fdesc{Cancella un file o una directory.}
ma si applica solo per i file, lo standard POSIX estende la funzione anche
alle directory.} il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{stdio.h}
\fdecl{int rename(const char *oldpath, const char *newpath)}
\fdesc{Rinomina un file o una directory.}
numero di file è molto grande.} La funzione di sistema usata per creare una
directory è \funcd{mkdir}, ed il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/stat.h}
\fhead{sys/types.h}
\fdecl{int mkdir(const char *dirname, mode\_t mode)}
necessaria una specifica funzione di sistema, \funcd{rmdir}, il suo prototipo
è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/stat.h}
\fdecl{int rmdir(const char *dirname)}
\fdesc{Cancella una directory.}
cap.~\ref{cha:files_std_interface}. La prima funzione di questa interfaccia è
\funcd{opendir}, il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/types.h}
\fhead{dirent.h}
\fdecl{DIR *opendir(const char *dirname)}
\texttt{\macro{\_POSIX\_C\_SOURCE} >= 200809L} o
\texttt{\macro{\_XOPEN\_SOURCE} >= 700}.} il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/types.h}
\fhead{dirent.h}
\fdecl{int dirfd(DIR *dir)}
\texttt{\macro{\_POSIX\_C\_SOURCE} >= 200809L} o \texttt{\_XOPEN\_SOURCE >=
700} .} il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/types.h}
\fhead{dirent.h}
\fdecl{DIR *fdopendir(int fd)}
contenuto della directory viene effettuata attraverso la funzione
\funcd{readdir}, il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/types.h}
\fhead{dirent.h}
\fdecl{struct dirent *readdir(DIR *dir)}
può essere utilizzata anche con i \itindex{thread} \textit{thread}, il suo
prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/types.h}
\fhead{dirent.h}
\fdecl{int readdir\_r(DIR *dir, struct dirent *entry, struct dirent **result)}
una delle macro \macro{\_XOPEN\_SOURCE}, \macro{\_BSD\_SOURCE} o
\macro{\_SVID\_SOURCE}.} il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{dirent.h}
\fdecl{void seekdir(DIR *dir, off\_t offset)}
\fdesc{Cambia la posizione all'interno di un \textit{directory stream}.}
tipo \type{off\_t}, sostituito a partire dalla versione 2.1.2 da \ctyp{long}
per conformità a POSIX.1-2001.}
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{dirent.h}
\fdecl{long telldir(DIR *dir)}
\fdesc{Ritorna la posizione corrente in un \textit{directory stream}.}
stream}, ed il file descriptor ad esso associato, con la funzione
\funcd{closedir}, il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/types.h}
\fhead{dirent.h}
\fdecl{int closedir(DIR *dir)}
\acr{libc4} e richiede siano definite le macro \macro{\_BSD\_SOURCE} o
\macro{\_SVID\_SOURCE}.} ed il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{dirent.h}
\fdecl{int scandir(const char *dir, struct dirent ***namelist, \\
\phantom{int scandir(}int(*filter)(const struct dirent *), \\
\param{compar}, sono disponibili due funzioni predefinite, \funcd{alphasort} e
\funcd{versionsort}, i cui prototipi sono:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{dirent.h}
\fdecl{int alphasort(const void *a, const void *b)}
\fdecl{int versionsort(const void *a, const void *b)}
il filesystem \texttt{/proc} da \procfile{/proc/self/cwd}.} il cui prototipo
è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{unistd.h}
\fdecl{char *getcwd(char *buffer, size\_t size)}
\fdesc{Legge il \textit{pathname} della directory di lavoro corrente.}
\funcd{chdir}, equivalente del comando di shell \cmd{cd}, il cui nome sta
appunto per \textit{change directory}, il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{unistd.h}
\fdecl{int chdir(const char *pathname)}
\fdesc{Cambia la directory di lavoro per \textit{pathname}.}
come per le directory, delle funzioni apposite. La prima di queste è la
funzione di sistema \funcd{mknod}, il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/stat.h}
\fhead{fcntl.h}
\funcd{tmpnam},\footnote{la funzione è stata deprecata nella revisione
POSIX.1-2008 dello standard POSIX.} il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{stdio.h}
\fdecl{char *tmpnam(char *string)}
\fdesc{Genera un nome univoco per un file temporaneo.}
Una funzione simile, \funcd{tempnam}, permette di specificare un prefisso per
il file esplicitamente, il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{stdio.h}
\fdecl{char *tempnam(const char *dir, const char *pfx)}
\fdesc{Genera un nome univoco per un file temporaneo.}
POSIX definisce la funzione \funcd{tmpfile}, che permette di ottenere in
maniera sicura l'accesso ad un file temporaneo, il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{stdio.h}
\fdecl{FILE *tmpfile(void)}
\fdesc{Apre un file temporaneo in lettura/scrittura.}
unico. La prima delle due è analoga a \func{tmpnam} e genera un nome casuale,
il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{stlib.h}
\fdecl{char *mktemp(char *template)}
\fdesc{Genera un nome univoco per un file temporaneo.}
\func{tmpfile}, ma restituisce un file descriptor invece di un nome; il suo
prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{stlib.h}
\fdecl{int mkstemp(char *template)}
\fdesc{Apre un file temporaneo.}
nella versione 2.7 delle librerie e richiede che sia definita la macro
\macro{\_GNU\_SOURCE}.} il cui prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{stlib.h}
\fdecl{int mkostemp(char *template, int flags)}
\fdesc{Apre un file temporaneo.}
funzione è stata introdotta nella \acr{glibc} a partire dalla versione
2.1.91 ed inserita nello standard POSIX.1-2008.} il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{stlib.h}
\fdecl{char *mkdtemp(char *template)}
\fdesc{Crea una directory temporanea.}
dimensione si possono usare le due funzioni di sistema \funcd{truncate} e
\funcd{ftruncate}, i cui prototipi sono:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{unistd.h}
\fdecl{int ftruncate(int fd, off\_t length))}
\fdecl{int truncate(const char *file\_name, off\_t length)}
esplicitamente usando la funzione di sistema \funcd{utime}, il cui prototipo
è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{utime.h}
\fdecl{int utime(const char *filename, struct utimbuf *times)}
\fdesc{Modifica i tempi di ultimo accesso ed ultima modifica di un file.}
di sistema, \funcd{utimes}, che consente di specificare tempi con maggior
precisione; il suo prototipo è:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/time.h}
\fdecl{int utimes(const char *filename, struct timeval times[2])}
\fdesc{Modifica i tempi di ultimo accesso e ultima modifica di un file.}
aperto o di eseguirla direttamente su un collegamento simbolico. I relativi
prototipi sono:
-\begin{funcproto}{
+\begin{funcproto}{
\fhead{sys/time.h}
\fdecl{int futimes(int fd, const struct timeval tv[2])}
\fdesc{Cambia i tempi di un file già aperto.}
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}{
+\begin{funcproto}{
\fhead{sys/time.h}
\fdecl{futimens(int fd, const struct timespec times[2])}
\fdesc{Cambia i tempi di un file già aperto.}
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.
-Esistono varie estensioni a questo modello,\footnote{come le \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:
+Esistono varie estensioni a questo modello,\footnote{come le
+ \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 \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
-\cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o} (per
-\textit{other}), inoltre se si vuole indicare tutti i raggruppamenti insieme
-si usa la lettera \cmd{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 tab.~\ref{tab:file_bit_perm}.
+\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 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]
\centering
\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
I passi attraverso i quali viene stabilito se il processo possiede il diritto
di accesso sono i seguenti:
-\begin{enumerate}
+\begin{enumerate*}
\item Se l'\ids{UID} effettivo del processo è zero (corrispondente
all'amministratore) l'accesso è sempre garantito senza nessun ulteriore
controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
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.
-\end{enumerate}
+\end{enumerate*}
Si tenga presente che questi passi vengono eseguiti esattamente in
quest'ordine. Questo vuol dire che se un processo è il proprietario di un file,
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}
sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
Per far questo si può usare la funzione \funcd{access}, il cui prototipo è:
-\begin{prototype}{unistd.h}
-{int access(const char *pathname, int mode)}
-Verifica i permessi di accesso.
-
-\bodydesc{La funzione ritorna 0 se l'accesso è consentito, -1 se l'accesso non
- è consentito ed in caso di errore; nel qual caso la variabile \var{errno}
- assumerà i valori:
+\begin{funcproto}{
+\fhead{unistd.h}
+\fdecl{int access(const char *pathname, int mode)}
+\fdesc{Verifica i permessi di accesso.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] il valore di \param{mode} non è valido.
\item[\errcode{EACCES}] l'accesso al file non è consentito, o non si ha il
un filesystem montato in sola lettura.
\end{errlist}
ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT},
- \errval{ENOTDIR}, \errval{ELOOP}, \errval{EIO}.}
-\end{prototype}
+ \errval{ENOTDIR}, \errval{ELOOP}, \errval{EIO}
+ nel loro significato generico.}
+\end{funcproto}
La funzione verifica i permessi di accesso, indicati da \param{mode}, per il
file indicato da \param{pathname}. I valori possibili per l'argomento
Per cambiare i permessi di un file il sistema mette ad disposizione due
funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un
filename e su un file descriptor, i loro prototipi sono:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/stat.h}
-
- \funcdecl{int chmod(const char *path, mode\_t mode)} Cambia i permessi del
- file indicato da \param{path} al valore indicato da \param{mode}.
-
- \funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa
- il file descriptor \param{fd} per indicare il file.
-
- \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per
- un errore, in caso di errore \var{errno} può assumere i valori:
+
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/stat.h}
+\fdecl{int chmod(const char *path, mode\_t mode)}
+\fdesc{Cambia i permessi del file indicato da \param{path} al valore indicato
+ da \param{mode}.}
+\fdecl{int fchmod(int fd, mode\_t mode)}
+\fdesc{Analoga alla precedente, ma usa il file descriptor \param{fd} per
+ indicare il file.}
+
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
proprietario del file o non è zero.
- \item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
+ \item[\errcode{EROFS}] il file è su un filesystem in sola lettura.
\end{errlist}
- ed inoltre \errval{EIO}; \func{chmod} restituisce anche \errval{EFAULT},
+ ed inoltre per entrambe \errval{EIO}, per \func{chmod} \errval{EFAULT},
\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR},
- \errval{EACCES}, \errval{ELOOP}; \func{fchmod} anche \errval{EBADF}.}
-\end{functions}
+ \errval{EACCES}, \errval{ELOOP}, per \func{fchmod} \errval{EBADF}
+ nel loro significato generico.}
+\end{funcproto}
+
Entrambe le funzioni utilizzano come secondo argomento \param{mode}, una
variabile dell'apposito tipo primitivo \type{mode\_t} (vedi
La funzione che permette di impostare il valore di questa maschera di
controllo è \funcd{umask}, ed il suo prototipo è:
-\begin{prototype}{stat.h}
-{mode\_t umask(mode\_t mask)}
-Imposta la maschera dei permessi dei bit al valore specificato da \param{mask}
-(di cui vengono presi solo i 9 bit meno significativi).
-
- \bodydesc{La funzione ritorna il precedente valore della maschera. È una
- delle poche funzioni che non restituisce codici di errore.}
-\end{prototype}
+\begin{funcproto}{
+\fhead{stat.h}
+\fdecl{mode\_t umask(mode\_t mask)}
+\fdesc{Imposta la maschera dei permessi.}
+}
+
+{La funzione ritorna ritorna il precedente valore della maschera, non sono
+ previste condizioni di errore.}
+\end{funcproto}
-In genere si usa questa maschera per impostare un valore predefinito che
-escluda preventivamente alcuni permessi (usualmente quello di scrittura per il
-gruppo e gli altri, corrispondente ad un valore per \param{mask} pari a
-$022$). In questo modo è possibile cancellare automaticamente i permessi non
-voluti. Di norma questo valore viene impostato una volta per tutte al login a
-$022$, e gli utenti non hanno motivi per modificarlo.
+La funzione imposta maschera dei permessi dei bit al valore specificato
+da \param{mask} (di cui vengono presi solo i 9 bit meno significativi). In
+genere si usa questa maschera per impostare un valore predefinito che escluda
+preventivamente alcuni permessi (usualmente quello di scrittura per il gruppo
+e gli altri, corrispondente ad un valore per \param{mask} pari a $022$). In
+questo modo è possibile cancellare automaticamente i permessi non voluti. Di
+norma questo valore viene impostato una volta per tutte al login a $022$, e
+gli utenti non hanno motivi per modificarlo.
\itindend{umask}
Come avviene nel caso dei permessi il sistema fornisce anche delle funzioni,
\funcd{chown}, \funcd{fchown} e \funcd{lchown}, che permettono di cambiare sia
l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{sys/stat.h}
-
- \funcdecl{int chown(const char *path, uid\_t owner, gid\_t group)}
- \funcdecl{int fchown(int fd, uid\_t owner, gid\_t group)}
- \funcdecl{int lchown(const char *path, uid\_t owner, gid\_t group)}
- Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
- specificati dalle variabili \param{owner} e \param{group}.
-
- \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un
- errore, nel qual caso caso \var{errno} assumerà i valori:
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{sys/stat.h}
+\fdecl{int chown(const char *path, uid\_t owner, gid\_t group)}
+\fdecl{int fchown(int fd, uid\_t owner, gid\_t group)}
+\fdecl{int lchown(const char *path, uid\_t owner, gid\_t group)}
+\fdesc{Cambiano proprietario e gruppo proprietario di un file.}
+}
+
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del
proprietario del file o non è zero, o utente e gruppo non sono validi
\end{errlist}
- Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e
- \errval{EIO}; \func{chown} restituisce anche \errval{EFAULT},
- \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR},
- \errval{EACCES}, \errval{ELOOP}; \func{fchown} anche \errval{EBADF}.}
-\end{functions}
+ ed inoltre per tutte \errval{EROFS} e \errval{EIO}, per \func{chown}
+ \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM},
+ \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP}, per \func{fchown}
+ \errval{EBADF} nel loro significato generico.}
+\end{funcproto}
-Con Linux solo l'amministratore\footnote{o in generale un processo con la
+Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
+specificati dalle variabili \param{owner} e \param{group}. Con Linux solo
+l'amministratore\footnote{o in generale un processo con la
\itindex{capabilities} capacità \const{CAP\_CHOWN}, vedi
sez.~\ref{sec:proc_capabilities}.} può cambiare il proprietario di un file;
in questo viene seguita la semantica usata da BSD che non consente agli utenti
\funcd{getxattr}, \funcd{lgetxattr} e \funcd{fgetxattr}, che consentono
rispettivamente di richiedere gli attributi relativi a un file, a un
collegamento simbolico e ad un file descriptor; i rispettivi prototipi sono:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{attr/xattr.h}
-
- \funcdecl{ssize\_t getxattr(const char *path, const char *name, void
- *value, size\_t size)}
- \funcdecl{ssize\_t lgetxattr(const char *path, const char *name, void
- *value, size\_t size)}
-
- \funcdecl{ssize\_t fgetxattr(int filedes, const char *name, void *value,
- size\_t size)}
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{attr/xattr.h}
+\fdecl{ssize\_t getxattr(const char *path, const char *name, void *value,
+ size\_t size)}
+\fdecl{ssize\_t lgetxattr(const char *path, const char *name, void *value,
+ size\_t size)}
+\fdecl{ssize\_t fgetxattr(int filedes, const char *name, void *value,
+ size\_t size)}
+\fdesc{Leggono il valore di un attributo esteso.}
+}
- Le funzioni leggono il valore di un attributo esteso.
-
- \bodydesc{Le funzioni restituiscono un intero positivo che indica la
- dimensione dell'attributo richiesto in caso di successo, e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+{Le funzioni ritornano un intero positivo che indica la dimensione
+ dell'attributo richiesto in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ENOATTR}] l'attributo richiesto non esiste.
\item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
\item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
filesystem o sono disabilitati.
\end{errlist}
- e tutti gli errori di \func{stat}, come \errcode{EPERM} se non si hanno i
- permessi di accesso all'attributo. }
-\end{functions}
+ ed inoltre tutti gli errori delle analoghe della famiglia \func{stat} con lo
+ stesso significato ed in particolare \errcode{EPERM} se non si hanno i
+ permessi di accesso all'attributo.}
+\end{funcproto}
Le funzioni \func{getxattr} e \func{lgetxattr} prendono come primo argomento
un \textit{pathname} che indica il file di cui si vuole richiedere un
un attributo esteso, queste sono \funcd{setxattr}, \funcd{lsetxattr} e
\funcd{fsetxattr}, e consentono di operare rispettivamente su un file, su un
collegamento simbolico o specificando un file descriptor; i loro prototipi sono:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{attr/xattr.h}
-
- \funcdecl{int setxattr(const char *path, const char *name, const void
- *value, size\_t size, int flags)}
- \funcdecl{int lsetxattr(const char *path, const char *name, const void
- *value, size\_t size, int flags)}
-
- \funcdecl{int fsetxattr(int filedes, const char *name, const void *value,
- size\_t size, int flags)}
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{attr/xattr.h}
+\fdecl{int setxattr(const char *path, const char *name, const void *value,
+ size\_t size, int flags)}
+\fdecl{int lsetxattr(const char *path, const char *name, const void *value,
+ size\_t size, int flags)}
+\fdecl{int fsetxattr(int filedes, const char *name, const void *value, size\_t
+ size, int flags)}
+\fdesc{Impostano il valore di un attributo esteso.}
+}
- Impostano il valore di un attributo esteso.
-
- \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+{Le funzioni ritornano un $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{ENOATTR}] si è usato il flag \const{XATTR\_REPLACE} e
l'attributo richiesto non esiste.
\item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
filesystem o sono disabilitati.
\end{errlist}
- Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
- ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
- all'attributo.
-}
-\end{functions}
+ ed inoltre tutti gli errori delle analoghe della famiglia \func{stat} con lo
+ stesso significato ed in particolare \errcode{EPERM} se non si hanno i
+ permessi di accesso all'attributo.}
+\end{funcproto}
Le tre funzioni prendono come primo argomento un valore adeguato al loro
scopo, usato in maniera del tutto identica a quanto visto in precedenza per le
estesi, ma sarebbe altrettanto utile poter vedere quali sono gli attributi
presenti; a questo provvedono le funzioni \funcd{listxattr},
\funcd{llistxattr} e \funcd{flistxattr} i cui prototipi sono:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{attr/xattr.h}
-
- \funcdecl{ssize\_t listxattr(const char *path, char *list, size\_t size)}
-
- \funcdecl{ssize\_t llistxattr(const char *path, char *list, size\_t size)}
- \funcdecl{ssize\_t flistxattr(int filedes, char *list, size\_t size)}
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{attr/xattr.h}
+\fdecl{ssize\_t listxattr(const char *path, char *list, size\_t size)}
+\fdecl{ssize\_t llistxattr(const char *path, char *list, size\_t size)}
+\fdecl{ssize\_t flistxattr(int filedes, char *list, size\_t size)}
+\fdesc{Leggono la lista degli attributi estesi di un file.}
+}
- Leggono la lista degli attributi estesi di un file.
-
- \bodydesc{Le funzioni restituiscono un intero positivo che indica la
- dimensione della lista in caso di successo, e $-1$ in caso di errore, nel
- qual caso \var{errno} assumerà i valori:
+{Le funzioni ritornano un intero positivo che indica la dimensione della lista
+ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà
+ uno dei valori:
\begin{errlist}
\item[\errcode{ERANGE}] la dimensione \param{size} del buffer \param{value}
non è sufficiente per contenere il risultato.
\item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
filesystem o sono disabilitati.
\end{errlist}
- Oltre a questi potranno essere restituiti tutti gli errori di \func{stat},
- ed in particolare \errcode{EPERM} se non si hanno i permessi di accesso
- all'attributo.
-}
-\end{functions}
+ ed inoltre tutti gli errori delle analoghe della famiglia \func{stat} con lo
+ stesso significato ed in particolare \errcode{EPERM} se non si hanno i
+ permessi di accesso all'attributo.}
+\end{funcproto}
Come per le precedenti le tre funzioni leggono gli attributi rispettivamente
di un file, un collegamento simbolico o specificando un file descriptor, da
Infine per rimuovere semplicemente un attributo esteso, si ha a disposizione
un ultimo gruppo di funzioni: \funcd{removexattr}, \funcd{lremovexattr} e
\funcd{fremovexattr}; i rispettivi prototipi sono:
-\begin{functions}
- \headdecl{sys/types.h}
- \headdecl{attr/xattr.h}
-
- \funcdecl{int removexattr(const char *path, const char *name)}
-
- \funcdecl{int lremovexattr(const char *path, const char *name)}
-
- \funcdecl{int fremovexattr(int filedes, const char *name)}
+\begin{funcproto}{
+\fhead{sys/types.h}
+\fhead{attr/xattr.h}
+\fdecl{int removexattr(const char *path, const char *name)}
+\fdecl{int lremovexattr(const char *path, const char *name)}
+\fdecl{int fremovexattr(int filedes, const char *name)}
+\fdesc{Rimuovono un attributo esteso di un file.}
+}
- Rimuovono un attributo esteso di un file.
-
- \bodydesc{Le funzioni restituiscono 0 in caso di successo, e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà i valori:
+{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{ENOATTR}] l'attributo richiesto non esiste.
\item[\errcode{ENOTSUP}] gli attributi estesi non sono supportati dal
filesystem o sono disabilitati.
\end{errlist}
- ed inoltre tutti gli errori di \func{stat}.
-}
-\end{functions}
+ ed inoltre tutti gli errori delle analoghe della famiglia \func{stat} con lo
+ stesso significato ed in particolare \errcode{EPERM} se non si hanno i
+ permessi di accesso all'attributo.}
+\end{funcproto}
Le tre funzioni rimuovono l'attributo esteso indicato dall'argomento
\param{name} rispettivamente di un file, un collegamento simbolico o
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
-
% TODO: trattare la funzione setns e i namespace file descriptors (vedi
% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0
% LocalWords: subtree SILENT log unbindable BUSY EAGAIN EXPIRE DETACH NOFOLLOW
% LocalWords: lazy encfs sshfs setfsent getfsent getfsfile getfsspec endfsent
% LocalWords: setmntent getmntent addmntent endmntent hasmntopt such offsetof
+% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
-% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev
projects / gapil.git / blobdiff