Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
-dei file descriptor il cui significato emergerà più avanti, il puntatore
-\var{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga per
-i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
-fornite dal VFS per i file. Si sono riportate in
-tab.~\ref{tab:file_file_operations} le più significative.
+dei file descriptor il cui significato emergerà più avanti (vedi
+sez.~\ref{sec:file_unix_interface}), il puntatore \var{f\_op} ad una struttura
+\kstruct{file\_operation}. Questa è l'analoga per i file di
+\kstruct{inode\_operation}, e definisce le operazioni generiche fornite dal
+VFS per i file. Si sono riportate in tab.~\ref{tab:file_file_operations} le
+più significative.
\begin{table}[htb]
\centering
\end{figure}
Se si va ad esaminare con maggiore dettaglio la strutturazione
-dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
+dell'informazione all'interno del filesystem \acr{ext2}, tralasciando i
dettagli relativi al funzionamento del filesystem stesso come la
strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
gestione possiamo esemplificare la situazione con uno schema come quello
\itindend{inode}
-\subsection{Alcuni dettagli sul filesystem \textsl{ext2} e successori}
+\subsection{Alcuni dettagli sul filesystem \acr{ext2} e successori}
\label{sec:file_ext2}
Benché non esista ``il'' filesystem di Linux, dato che esiste un supporto
\textit{journaling} con il passaggio ad \acr{ext3}, che probabilmente è ancora
il filesystem più diffuso, ed una serie di ulteriori miglioramenti con il
successivo \acr{ext4}. In futuro è previsto che questo debba essere sostituito
-da un filesystem completamente diverso, \acr{btrfs}, che dovrebbe diventare il
+da un filesystem completamente diverso, \acr{Btrfs}, che dovrebbe diventare il
filesystem standard di Linux, ma questo al momento è ancora in fase di
sviluppo.\footnote{si fa riferimento al momento dell'ultima revisione di
questo paragrafo, l'inizio del 2012.}
implementare nomi per i file anche molto lunghi (fino a 1024 caratteri) senza
sprecare spazio disco.
-Con l'introduzione del filesystem \textit{ext3} sono state introdotte diverse
-modifiche strutturali, la principale di queste è quella che \textit{ext3} è un
+Con l'introduzione del filesystem \acr{ext3} sono state introdotte diverse
+modifiche strutturali, la principale di queste è quella che \acr{ext3} è un
filesystem \textit{journaled}, è cioè in grado di eseguire una registrazione
delle operazioni di scrittura su un giornale (uno speciale file interno) in
modo da poter garantire il ripristino della coerenza dei dati del
della corrente o di crollo del sistema che abbia causato una interruzione
della scrittura dei dati sul disco.
-Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare
+Oltre a questo \acr{ext3} introduce ulteriori modifiche volte a migliorare
sia le prestazioni che la semplicità di gestione del filesystem, in
particolare per le directory si è passato all'uso di alberi binari con
indicizzazione tramite \textit{hash} al posto delle \textit{linked list} che
distribuzioni più recenti) la risoluzione dei nomi attraverso un collegamento
simbolico può fallire per una serie di restrizione di sicurezza aggiuntive
imposte dal meccanismo (si consulti sez.~\ref{sec:procadv_security_misc} per i
-dettagli del meccanismo).
+dettagli).
Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
\func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per
\textit{stream} sulla prima voce contenuta nella directory.
Si tenga presente che comunque la funzione opera associando il
-\textit{directory stream} ad un opportuno file descriptor sottostante, sul
-quale vengono compiute le operazioni. Questo viene sempre aperto impostando il
-flag di \textit{close-on-exec} (si ricordi quanto detto in
-sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso di
-esecuzione di un altro programma.
-
-Nel caso in cui sia necessario conoscere il \textit{file descriptor} associato
-ad un \textit{directory stream} si può usare la funzione
+\textit{directory stream} ad un opportuno file descriptor (vedi
+sez.~\ref{sec:file_fd}) sottostante, sul quale vengono compiute le
+operazioni. Questo viene sempre aperto impostando il flag di
+\textit{close-on-exec} (si ricordi quanto detto in sez.~\ref{sec:proc_exec}),
+così da evitare che resti aperto in caso di esecuzione di un altro programma.
+
+Nel caso in cui sia necessario conoscere il file descriptor associato ad un
+\textit{directory stream} si può usare la funzione
\funcd{dirfd},\footnote{questa funzione è una estensione introdotta con BSD
4.3-Reno ed è presente in Linux con le libc5 (a partire dalla versione
5.1.2) e con la \acr{glibc} ma non presente in POSIX fino alla revisione
sez.~\ref{sec:file_stat}) per determinarlo. I suoi possibili valori sono
riportati in tab.~\ref{tab:file_dtype_macro}. Si tenga presente che questo
valore è disponibile solo per i filesystem che ne supportano la restituzione
-(fra questi i più noti sono \textsl{btrfs}, \textsl{ext2}, \textsl{ext3}, e
-\textsl{ext4}), per gli altri si otterrà sempre il valore
+(fra questi i più noti sono \acr{Btrfs}, \acr{ext2}, \acr{ext3}, e
+\acr{ext4}), per gli altri si otterrà sempre il valore
\const{DT\_UNKNOWN}.\footnote{inoltre fino alla versione 2.1 della
\acr{glibc}, pur essendo il campo \var{d\_type} presente, il suo uso non era
implementato, e veniva restituito comunque il valore \const{DT\_UNKNOWN}.}
\cmd{-t}) mostra i tempi dei file secondo lo schema riportato nell'ultima
colonna di tab.~\ref{tab:file_file_times}. Si noti anche come in
tab.~\ref{tab:file_file_times} non venga riportato il \textsl{tempo di
- creazione} di un file. In un sistema unix-like infatti questo tempo
-tradizionalmente non esiste, e non è previsto dall'interfaccia classica, ma è
-usato da altri sistemi operativi (in particolare Windows) per cui in tutti i
-filesystem più recenti ne viene supportata la registrazione, ed a partire dal
-kernel 4.11 è divento possibile anche ottenerne la lettura con la nuova
-\textit{system call} \func{statx} (che tratteremo in
-sez.~\ref{sec:file_openat}).
+ creazione} di un file; in un sistema unix-like infatti questo non esiste, e
+non è previsto dall'interfaccia classica, ma essendo usato da altri sistemi
+operativi (in particolare Windows) in tutti i filesystem più recenti ne viene
+supportata la registrazione, ed a partire dal kernel 4.11 è diventato
+possibile anche ottenerne la lettura con la nuova \textit{system call}
+\func{statx} (che tratteremo in sez.~\ref{sec:file_openat}).
L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
difetto progettuale di Unix, questo infatti comporta la necessità di
\end{figure}
-Oltre ad \func{utimes} su Linux sono presenti altre due funzioni per la
-manipolazione dei tempi dei file,\footnote{le due funzioni non sono definite
- in nessuno standard, ma sono presenti, oltre che su Linux, anche su BSD;
- sono accessibili definendo \macro{\_DEFAULT\_SOURCE} dalla \acr{glibc} 2.19
- o \macro{\_GNU\_SOURCE} prima.} la prima è \funcd{futimes} e consente di
-effettuare la modifica utilizzando un file già aperto, il suo prototipo è:
+% Oltre ad \func{utimes} su Linux sono presenti altre due funzioni per la
+% manipolazione dei tempi dei file,\footnote{le due funzioni non sono definite
+% in nessuno standard, ma sono presenti, oltre che su Linux, anche su BSD;
+% sono accessibili definendo \macro{\_DEFAULT\_SOURCE} dalla \acr{glibc} 2.19
+% o \macro{\_GNU\_SOURCE} prima.} la prima è \funcd{futimes} e consente di
+% effettuare la modifica utilizzando un file già aperto, il suo prototipo è:
+
+% \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.}
+% }
+
+% {La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+% caso \var{errno} assumerà uno gli stessi valori di \func{utimes} ed inoltre:
+% \begin{errlist}
+% \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
+% \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
+% \end{errlist}}
+% \end{funcproto}
+
+% La seconda funzione, introdotta a partire dal kernel 2.6.22, è
+% \funcd{lutimes}, e consente rispettivamente di modificare i tempi di un
+% collegamento simbolico; il suo prototipo è:
+
+% \begin{funcproto}{
+% \fhead{sys/time.h}
+% \fdecl{int lutimes(const char *filename, const struct timeval tv[2])}
+% \fdesc{Cambia i tempi di un collegamento simbolico.}
+% }
+
+% {La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+% caso \var{errno} assumerà uno gli stessi valori di \func{utimes}, con in più:
+% \begin{errlist}
+% \item[\errcode{ENOSYS}] la funzione non è supportata.
+% \end{errlist}}
+% \end{funcproto}
+
+% Le due funzioni hanno lo stesso comportamento di \texttt{utimes} e richiedono
+% gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
+% si può indicare il file su cui operare se questo è già aperto facendo
+% riferimento al suo file descriptor, mentre con \func{lutimes}, nel caso in cui
+% \param{filename} sia un collegamento simbolico, saranno modificati i suoi
+% tempi invece di quelli del file a cui esso punta.
+
+Oltre ad \func{utimes} su Linux sono presenti altre due funzioni,\footnote{le
+ due funzioni non sono definite in nessuno standard, ma sono presenti, oltre
+ che su Linux, anche su BSD; sono accessibili definendo
+ \macro{\_DEFAULT\_SOURCE} dalla \acr{glibc} 2.19 o \macro{\_GNU\_SOURCE}
+ prima.} \funcd{futimes} e \funcd{lutimes}, che consentono rispettivamente
+di effettuare la modifica utilizzando un file già aperto o di eseguirla
+direttamente su un collegamento simbolico. I relativi prototipi sono:
\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.}
-}
-
-{La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà uno gli stessi valori di \func{utimes} ed inoltre:
- \begin{errlist}
- \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
- \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
- \end{errlist}}
-\end{funcproto}
-
-La seconda funzione, introdotta a partire dal kernel 2.6.22, è
-\funcd{lutimes}, e consente rispettivamente di modificare i tempi di un
-collegamento simbolico; il suo prototipo è:
-
-\begin{funcproto}{
-\fhead{sys/time.h}
\fdecl{int lutimes(const char *filename, const struct timeval tv[2])}
\fdesc{Cambia i tempi di un collegamento simbolico.}
}
-{La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà uno gli stessi valori di \func{utimes}, con in più:
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno gli stessi valori di \func{utimes}, con in più
+ per \func{futimes}:
\begin{errlist}
- \item[\errcode{ENOSYS}] la funzione non è supportata.
- \end{errlist}}
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
+ \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile per
+ \func{futimes} o la funzione non è supportata per \func{lutimes}.
+ \end{errlist}}
\end{funcproto}
Le due funzioni hanno lo stesso comportamento di \texttt{utimes} e richiedono
gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
si può indicare il file su cui operare se questo è già aperto facendo
-riferimento al suo file descriptor, mentre con \func{lutimes}, nel caso in cui
-\param{filename} sia un collegamento simbolico, saranno modificati i suoi
+riferimento al suo file descriptor, mentre con \func{lutimes} nel caso in
+cui \param{filename} sia un collegamento simbolico saranno modificati i suoi
tempi invece di quelli del file a cui esso punta.
Nonostante il kernel nelle versioni più recenti supporti, come accennato,
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 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.
+filesystem standard.\footnote{per filesystem standard si intende un filesystem
+ che implementi le 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}
\begin{figure}[htb]
\centering
- \includegraphics[width=6cm]{img/fileperm}
+ \includegraphics[width=8cm]{img/fileperm}
\caption{Lo schema dei bit utilizzati per specificare i permessi di un file
contenuti nel campo \var{st\_mode} di \struct{stat}.}
\label{fig:file_perm_bit}
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 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 una seconda volta
-in tab.~\ref{tab:file_bit_perm}.
-
\begin{table}[htb]
\centering
\footnotesize
\label{tab:file_bit_perm}
\end{table}
+
+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 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 una seconda volta
+in tab.~\ref{tab:file_bit_perm}.
+
I permessi vengono usati in maniera diversa dalle varie funzioni, e a seconda
che si riferiscano a dei file, dei collegamenti simbolici o delle directory;
qui ci limiteremo ad un riassunto delle regole generali, entrando nei dettagli
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). 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 infatti viene solo modificato il
+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 infatti viene solo modificato il
contenuto della directory, rimuovendo la voce che ad esso fa riferimento. Lo
stesso vale per poter rinominare o spostare il file in altra directory, in
entrambi i casi occorrerà il permesso di scrittura sulle directory che si
tratteremo insieme alle altre \textit{at-functions} in
sez.~\ref{sec:file_openat}.
+
Del tutto analoghe a \func{access} sono le due funzioni \funcm{euidaccess} e
\funcm{eaccess} che ripetono lo stesso controllo usando però gli
identificatori del gruppo effettivo, verificando quindi le effettive capacità
anche gli stessi valori e restituiscono gli stessi risultati e gli stessi
codici di errore.
-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:
+Le due funzioni non sono previste da nessuno standard, ed utilizzabili solo
+avendo definito \macro{\_GNU\_SOURCE}; inoltre qualora le si vogliano
+utilizzare per verificare che un processo abbia i permessi per accedere ad un
+file prima di farlo effettivamente, ci si esporrebbe ad una \textit{race
+ condition}, dato che i permessi potrebbero cambiare nell'intervallo fra il
+controllo e l'accesso effettivo. Per questo motivo in questo caso è molto più
+semplice e sicuro tentare direttamente l'accesso, e trattare opportunamente
+l'eventuale fallimento per mancanza di permessi.
+
+Per cambiare i permessi di un file sono invece disponibili due funzioni di
+sistema \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente usando il
+\textit{pathname} di un file o se questo è già aperto sul relativo file
+descriptor; i loro prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
Entrambe le funzioni utilizzano come secondo argomento \param{mode}, una
variabile dell'apposito tipo primitivo \type{mode\_t} (vedi
-tab.~\ref{tab:intro_primitive_types}) utilizzato per specificare i permessi
-sui file.
+tab.~\ref{tab:intro_primitive_types}), che è una maschera binaria da
+utilizzare per specificare i permessi sui file.
\begin{table}[!htb]
\centering
\label{tab:file_permission_const}
\end{table}
-Le costanti con cui specificare i singoli bit di \param{mode} sono riportate
-in tab.~\ref{tab:file_permission_const}, e corrispondono agli stessi valori
-usati per \var{st\_mode} in tab.~\ref{tab:file_mode_flags}. Il valore
-di \param{mode} può essere ottenuto combinando fra loro con un OR binario le
-costanti simboliche relative ai vari bit, o specificato direttamente, come per
-l'omonimo comando di shell, con un valore numerico (la shell lo vuole in
-ottale, dato che i bit dei permessi sono divisibili in gruppi di tre), che si
-può calcolare direttamente usando lo schema di utilizzo dei bit illustrato in
+Si sono riportate in tab.~\ref{tab:file_permission_const} le costanti con cui
+indicare i singoli bit di \param{mode}; si noti come corrispondano agli stessi
+valori usati per \var{st\_mode} già visti in tab.~\ref{tab:file_mode_flags}.
+Il valore di \param{mode} può essere ottenuto combinando fra loro con un OR
+binario le costanti simboliche relative ai vari bit, o specificato
+direttamente, come per l'omonimo comando di shell \texttt{chmod}, con un
+valore numerico (con la shell in genere lo si scrive in ottale, dato che i bit
+dei permessi sono divisibili in gruppi di tre), che si può calcolare
+direttamente usando lo schema di utilizzo dei bit illustrato in
fig.~\ref{fig:file_perm_bit}.
Ad esempio i permessi standard assegnati ai nuovi file (lettura e scrittura
per il proprietario, sola lettura per il gruppo e gli altri) sono
-corrispondenti al valore ottale $0644$, un programma invece avrebbe anche il
-bit di esecuzione attivo, con un valore di $0755$, se si volesse attivare il
-bit \acr{suid} il valore da fornire sarebbe $4755$.
+corrispondenti al valore ottale \texttt{0644}, un programma invece avrebbe
+anche il bit di esecuzione attivo, con un valore ottale di \texttt{0755}, se
+infine si volesse attivare anche il bit \acr{suid} il valore ottale da fornire
+sarebbe \texttt{4755}.
Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha
comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle
funzioni infatti è possibile solo se l'\ids{UID} effettivo del processo
-corrisponde a quello del proprietario del file o dell'amministratore,
-altrimenti esse falliranno con un errore di \errcode{EPERM}.
+chiamante corrisponde a quello del proprietario del file o se il processo ha i
+privilegi di amministratore,\footnote{per la precisione la capacità
+ \const{CAP\_FOWNER}, vedi sez.~\ref{sec:proc_capabilities}.} in caso
+contrario esse falliranno con un errore di \errcode{EPERM}.
Ma oltre a questa regola generale, di immediata comprensione, esistono delle
limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file,
quando l'\ids{UID} effettivo del processo è zero.
\end{enumerate*}
-Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
- \textsl{ext3}, \textsl{ext4}, \textsl{ReiserFS}) supportano questa
- caratteristica, che è mutuata da BSD.} è inoltre prevista un'ulteriore
-misura di sicurezza, volta a scongiurare l'abuso dei bit \acr{suid} e
-\acr{sgid}; essa consiste nel cancellare automaticamente questi bit dai
-permessi di un file qualora un processo che non appartenga
+Per alcuni filesystem\footnote{i filesystem più comuni (\acr{ext2},
+ \acr{ext3}, \acr{ext4}, \acr{XFS}, \acr{Btrfs}) supportano
+ questa caratteristica, che è mutuata da BSD.} è inoltre prevista
+un'ulteriore misura di sicurezza, volta a scongiurare l'abuso dei bit
+\acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi
+bit dai permessi di un file qualora un processo che non appartenga
all'amministratore\footnote{per la precisione un processo che non dispone
della capacità \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.}
effettui una scrittura. In questo modo anche se un utente malizioso scopre un
semantica BSD. Linux invece segue normalmente quella che viene chiamata
semantica SVr4: di norma un nuovo file viene creato, seguendo la prima
opzione, con il \ids{GID} del processo, se però la directory in cui viene
-creato ha il bit \acr{sgid} impostato allora viene usata la seconda
-opzione. L'adozione di questa semantica però può essere controllata,
+creato ha il bit \acr{sgid} dei permessi impostato allora viene usata la
+seconda opzione. L'adozione di questa semantica però può essere controllata,
all'interno di alcuni filesystem,\footnote{con il kernel 2.6.25 questi erano
- \acr{ext2}, \acr{ext3}, \acr{ext4}, e XFS.} con l'uso dell'opzione di
+ \acr{ext2}, \acr{ext3}, \acr{ext4}, e \acr{XFS}.} con l'uso dell'opzione di
montaggio \texttt{grpid}, che se attivata fa passare all'uso della semantica
BSD.
stata creata una nuova \textit{system call} per \func{chown} che seguisse i
collegamenti simbolici.} La funzione \func{fchown} opera su un file aperto,
essa è mutuata da BSD, ma non è nello standard POSIX. Un'altra estensione
-rispetto allo standard POSIX è che specificando -1 come valore
-per \param{owner} e \param{group} i valori restano immutati.
+rispetto allo standard POSIX è che specificando $-1$ come valore per
+\param{owner} e \param{group} i valori restano immutati.
Quando queste funzioni sono chiamate con successo da un processo senza i
privilegi di amministratore entrambi i bit \acr{suid} e \acr{sgid} vengono
Per risolvere questo problema alcuni sistemi unix-like (e fra questi anche
Linux) hanno introdotto un meccanismo generico, detto \textit{Extended
Attributes} che consente di associare delle informazioni ulteriori ai
-singoli file.\footnote{essi ad esempio vengono usati per le ACL, che
- tratteremo in sez.~\ref{sec:file_ACL} e le \textit{file capabilities}, che
- vedremo in sez.~\ref{sec:proc_capabilities}.} Gli \textsl{attributi estesi}
-non sono altro che delle coppie nome/valore che sono associate permanentemente
-ad un oggetto sul filesystem, analoghi di quello che sono le variabili di
-ambiente (vedi sez.~\ref{sec:proc_environ}) per un processo.
+singoli file; ad esempio vengono usati per la gestione delle ACL, che
+tratteremo in sez.~\ref{sec:file_ACL} e per le \textit{file capabilities}, che
+vedremo in sez.~\ref{sec:proc_capabilities}. Gli \textsl{attributi estesi}
+(abbreviati in \textsl{xattr}) non sono altro che delle coppie nome/valore che
+sono associate permanentemente ad un oggetto sul filesystem, analoghi di
+quello che sono le variabili di ambiente (vedi sez.~\ref{sec:proc_environ})
+per un processo.
Altri sistemi (come Solaris, MacOS e Windows) hanno adottato un meccanismo
diverso in cui ad un file sono associati diversi flussi di dati, su cui
Si tenga presente che non tutti i filesystem supportano gli \textit{Extended
Attributes}; al momento della scrittura di queste dispense essi sono
-presenti solo sui vari \textsl{extN}, \textsl{ReiserFS}, \textsl{JFS},
-\textsl{XFS} e \textsl{Btrfs}.\footnote{l'elenco è aggiornato a Luglio 2011.}
-Inoltre a seconda della implementazione ci possono essere dei limiti sulla
-quantità di attributi che si possono utilizzare.\footnote{ad esempio nel caso
- di \textsl{ext2} ed \textsl{ext3} è richiesto che essi siano contenuti
+presenti solo sui vari \acr{extN}, \acr{ReiserFS}, \acr{JFS},
+\acr{XFS}, \acr{Btrfs}, \acr{Lustre} e \acr{OCFS2}. Inoltre a
+seconda della implementazione ci possono essere dei limiti sulla quantità di
+attributi che si possono utilizzare.\footnote{ad esempio nel caso di
+ \acr{ext2} ed \acr{ext3} è richiesto che essi siano contenuti
all'interno di un singolo blocco, pertanto con dimensioni massime pari a
1024, 2048 o 4096 byte a seconda delle dimensioni di quest'ultimo impostate
- in fase di creazione del filesystem, mentre con \textsl{XFS} non ci sono
- limiti ed i dati vengono memorizzati in maniera diversa (nell'\textit{inode}
- stesso, in un blocco a parte, o in una struttura ad albero dedicata) per
- mantenerne la scalabilità.} Infine lo spazio utilizzato per mantenere gli
-attributi estesi viene tenuto in conto per il calcolo delle quote di utente e
-gruppo proprietari del file.
+ in fase di creazione del filesystem, mentre con \textsl{XFS} e
+ \textsl{Btrfs} non ci sono limiti ed i dati vengono memorizzati in maniera
+ diversa (nell'\textit{inode} stesso, in un blocco a parte, o in una
+ struttura ad albero dedicata) per mantenerne la scalabilità; lasciamo i
+ dettagli dei vari filesystem alla documentazione accessibile con \texttt{man
+ xattr}.} Infine lo spazio utilizzato per mantenere gli attributi estesi
+viene tenuto in conto per il calcolo delle quote di utente e gruppo
+proprietari del file.
Come meccanismo per mantenere informazioni aggiuntive associate al singolo
file, gli \textit{Extended Attributes} possono avere usi anche molto diversi
specificato nella forma \texttt{namespace.attribute}, dove \texttt{namespace}
fa riferimento alla classe a cui l'attributo appartiene, mentre
\texttt{attribute} è il nome ad esso assegnato. In tale forma il nome di un
-attributo esteso deve essere univoco. Al momento\footnote{della scrittura di
- questa sezione, kernel 2.6.23, ottobre 2007.} sono state definite le quattro
-classi di attributi riportate in tab.~\ref{tab:extended_attribute_class}.
+attributo esteso deve essere univoco. Al momento sono state definite le
+quattro classi di attributi riportate in
+tab.~\ref{tab:extended_attribute_class}.
\begin{table}[htb]
\centering
di meccanismi evoluti di controllo di accesso come
\textit{SELinux} o le \textit{capabilities} dei
file di sez.~\ref{sec:proc_capabilities}.\\
- \texttt{system} & Gli \textit{extended security attributes}: sono usati
+ \texttt{system} & Gli \textit{extended system attributes}: sono usati
dal kernel per memorizzare dati di sistema associati ai
file come le ACL (vedi sez.~\ref{sec:file_ACL}) o le
\textit{capabilities} (vedi
sez.~\ref{sec:proc_capabilities}).\\
\texttt{trusted}& I \textit{trusted extended attributes}: vengono
- utilizzati per poter realizzare in user space
+ utilizzati per poter realizzare in \textit{user space}
meccanismi che consentano di mantenere delle
informazioni sui file che non devono essere accessibili
ai processi ordinari.\\
Dato che uno degli usi degli \textit{Extended Attributes} è di impiegarli per
-realizzare delle estensioni (come le ACL, \textit{SELinux}, ecc.) al
-tradizionale meccanismo dei controlli di accesso di Unix, l'accesso ai loro
+realizzare delle estensioni al tradizionale meccanismo dei controlli di
+accesso di Unix (come le ACL, \textit{SELinux}, ecc.), l'accesso ai loro
valori viene regolato in maniera diversa a seconda sia della loro classe che
di quali, fra le estensioni che li utilizzano, sono poste in uso. In
particolare, per ciascuna delle classi riportate in
modulo di sicurezza che si sta utilizzando al momento (ciascuno avrà le
sue). Se non è stato caricato nessun modulo di sicurezza l'accesso in
lettura sarà consentito a tutti i processi, mentre quello in scrittura solo
- ai processi con privilegi amministrativi dotati della capacità
- \const{CAP\_SYS\_ADMIN}.
+ ai processi con privilegi amministrativi (per la precisione dotati della
+ capacità \const{CAP\_SYS\_ADMIN}, vedi sez.~\ref{sec:proc_capabilities}).
\item[\texttt{system}] Anche l'accesso agli \textit{extended system
attributes} dipende dalle politiche di accesso che il kernel realizza
ai processi che hanno la capacità di eseguire una ricerca sul file (cioè
hanno il permesso di lettura sulla directory che contiene il file) ed in
scrittura al proprietario del file o ai processi dotati della capacità
- \const{CAP\_FOWNER}.\footnote{vale a dire una politica di accesso analoga a
- quella impiegata per gli ordinari permessi dei file.}
+ \const{CAP\_FOWNER}, vale a dire una politica di accesso analoga a quella
+ impiegata per gli ordinari permessi dei file.
\item[\texttt{trusted}] L'accesso ai \textit{trusted extended attributes}, sia
per la lettura che per la scrittura, è consentito soltanto ai processi con
privilegi amministrativi dotati della capacità \const{CAP\_SYS\_ADMIN}. In
- questo modo si possono utilizzare questi attributi per realizzare in user
- space dei meccanismi di controllo che accedono ad informazioni non
- disponibili ai processi ordinari.
+ questo modo si possono utilizzare questi attributi per realizzare in
+ \textit{user space} dei meccanismi di controllo che accedono ad informazioni
+ non disponibili ai processi ordinari.
\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
regolato dai normali permessi dei file: occorre avere il permesso di lettura
due casi hanno a che fare con il contenuto del file, e nella discussione
relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
capace di indicare una qualche forma sensata di utilizzo degli stessi per
- collegamenti simbolici o file di dispositivo, e neanche per le \textit{fifo} o i
- socket. Per questo motivo essi sono stati completamente disabilitati per
- tutto ciò che non sia un file regolare o una directory.\footnote{si può
- verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
- dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
- ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi
- di scrittura completi su directory come \texttt{/tmp}. Per questo motivo,
- per evitare eventuali abusi, se una directory ha lo \textit{sticky bit}
- attivo sarà consentito scrivere i suoi \textit{extended user attributes}
- soltanto se si è proprietari della stessa, o si hanno i privilegi
- amministrativi della capacità \const{CAP\_FOWNER}.
+ collegamenti simbolici o file di dispositivo, e neanche per le \textit{fifo}
+ o i socket.
+
+ Per questo motivo essi sono stati completamente disabilitati per tutto ciò
+ che non sia un file regolare o una directory.\footnote{si può verificare la
+ semantica adottata consultando il file \texttt{fs/xattr.c} dei sorgenti
+ del kernel.} Inoltre per le directory è stata introdotta una ulteriore
+ restrizione, dovuta di nuovo alla presenza ordinaria di permessi di
+ scrittura completi su directory come \texttt{/tmp}. Per questo motivo, per
+ evitare eventuali abusi, se una directory ha lo \textit{sticky bit} attivo
+ sarà consentito scrivere i suoi \textit{extended user attributes} soltanto
+ se si è proprietari della stessa, o si hanno i privilegi amministrativi
+ della capacità \const{CAP\_FOWNER}.
\end{basedescript}
Le funzioni per la gestione degli attributi estesi, come altre funzioni di
indicato comprensivo di prefisso del \textit{namespace} cui appartiene (uno
dei valori di tab.~\ref{tab:extended_attribute_class}) nella forma
\texttt{namespace.attributename}, come stringa terminata da un carattere NUL.
-Il suo valore verrà restituito nel buffer puntato dall'argomento \param{value}
-per una dimensione massima di \param{size} byte;\footnote{gli attributi estesi
- possono essere costituiti arbitrariamente da dati testuali o binari.} se
-quest'ultima non è sufficiente si avrà un errore di \errcode{ERANGE}.
+Il valore dell'attributo richiesto verrà restituito nel buffer puntato
+dall'argomento \param{value} per una dimensione massima di \param{size} byte
+(gli attributi estesi possono essere costituiti arbitrariamente da dati
+testuali o binari); se quest'ultima non è sufficiente si avrà un errore di
+\errcode{ERANGE}.
Per evitare di dover indovinare la dimensione di un attributo per tentativi si
può eseguire una interrogazione utilizzando un valore nullo per \param{size};
in questo caso non verrà letto nessun dato, ma verrà restituito come valore di
ritorno della funzione chiamata la dimensione totale dell'attributo esteso
richiesto, che si potrà usare come stima per allocare un buffer di dimensioni
-sufficienti.\footnote{si parla di stima perché anche se le funzioni
- restituiscono la dimensione esatta dell'attributo al momento in cui sono
- eseguite, questa potrebbe essere modificata in qualunque momento da un
- successivo accesso eseguito da un altro processo.}
+sufficienti.
-Un secondo gruppo di funzioni è quello che consente di impostare il valore di
-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:
+Si tenga conto che questa è comunque una stima perché anche se le funzioni
+restituiscono la dimensione esatta dell'attributo al momento in cui sono
+eseguite, questa potrebbe essere modificata in qualunque momento da un
+successivo accesso eseguito da un altro processo, pertanto si verifichi sempre
+il valore di ritorno ed il codice di errore della funzione usata, senza dare
+per scontato che essa abbia sempre successo.
+
+Un secondo gruppo di funzioni sono quelle che consentono di impostare il
+valore di un attributo esteso, le funzioni sono \funcd{setxattr},
+\funcd{lsetxattr} e \funcd{fsetxattr} e consentono di operare rispettivamente
+su un file, su un collegamento simbolico o utilizzando un file descriptor; i
+rispettivi prototipi sono:
\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)}
+\fdecl{int setxattr(const char *path, const char *name, const void *value,\\
+ \phantom{int setxattr(}size\_t size, int flags)}
+\fdecl{int lsetxattr(const char *path, const char *name, const void *value,\\
+ \phantom{int lsetxattr(}size\_t size, int flags)}
+\fdecl{int fsetxattr(int filedes, const char *name, const void *value,\\
+ \phantom{int fsetxattr(}size\_t size, int flags)}
\fdesc{Impostano il valore di un attributo esteso.}
}
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
-analoghe che leggono gli attributi estesi. Il secondo argomento \param{name}
-deve indicare, anche in questo caso con gli stessi criteri appena visti per le
-analoghe \func{getxattr}, \func{lgetxattr} e \func{fgetxattr}, il nome
-(completo di suffisso) dell'attributo su cui si vuole operare.
-
-Il valore che verrà assegnato all'attributo dovrà essere preparato nel buffer
-puntato da \param{value}, e la sua dimensione totale (in byte) sarà indicata
-dall'argomento \param{size}. Infine l'argomento \param{flag} consente di
-controllare le modalità di sovrascrittura dell'attributo esteso, esso può
-prendere due valori: con \constd{XATTR\_REPLACE} si richiede che l'attributo
-esista, nel qual caso verrà sovrascritto, altrimenti si avrà errore, mentre
-con \constd{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual
-caso verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
-modificato. Utilizzando per \param{flag} un valore nullo l'attributo verrà
-modificato se è già presente, o creato se non c'è.
+Le tre funzioni prendono come primo argomento un valore adeguato al loro scopo
+(un \textit{pathname} le prime due, un file descriptor la terza), usato in
+maniera del tutto identica a quanto visto in precedenza per le analoghe che
+leggono gli attributi estesi.
+
+Il secondo argomento, \param{name}, deve indicare, anche in questo caso con
+gli stessi criteri appena visti per le analoghe \func{getxattr},
+\func{lgetxattr} e \func{fgetxattr}, il nome (completo di suffisso)
+dell'attributo su cui si vuole operare. Il valore che verrà assegnato
+all'attributo dovrà essere preparato nel buffer puntato da \param{value}, e la
+sua dimensione totale (in byte) dovrà essere indicata dall'argomento
+\param{size}.
+
+Infine l'argomento \param{flag} consente di controllare le modalità di
+sovrascrittura dell'attributo esteso, esso può prendere due valori: con
+\constd{XATTR\_REPLACE} si richiede che l'attributo esista, nel qual caso
+verrà sovrascritto ed altrimenti si avrà errore; con \constd{XATTR\_CREATE} si
+richiede che l'attributo non esista, nel qual caso verrà creato, altrimenti si
+avrà errore ed il valore attuale non sarà modificato. Utilizzando per
+\param{flag} un valore nullo l'attributo verrà modificato se è già presente, o
+creato se non c'è.
Le funzioni finora illustrate permettono di leggere o scrivere gli attributi
-estesi, ma sarebbe altrettanto utile poter vedere quali sono gli attributi
-presenti; a questo provvedono le funzioni di sistema \funcd{listxattr},
-\funcd{llistxattr} e \funcd{flistxattr} i cui prototipi sono:
+estesi presenti su un file, ma sarebbe altrettanto utile poter sapere quali
+sono questi attributi; per questo sono disponibili le ulteriori tre funzioni
+di sistema \funcd{listxattr}, \funcd{llistxattr} e \funcd{flistxattr} i cui
+prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
-rispondere in maniera adeguata a situazioni che richiedono una gestione
+rispondere in maniera adeguata a situazioni che richiedono una gestione più
complessa dei permessi di accesso.\footnote{già un requisito come quello di
dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non
si può soddisfare in maniera semplice.}
compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che le ACL
devono essere attivate esplicitamente montando il filesystem\footnote{che deve
supportarle, ma questo è ormai vero per praticamente tutti i filesystem più
- comuni, con l'eccezione di NFS per il quale esiste però un supporto
- sperimentale.} su cui le si vogliono utilizzare con l'opzione \texttt{acl}
-attiva. Dato che si tratta di una estensione è infatti opportuno utilizzarle
-soltanto laddove siano necessarie.
+ comuni, con l'eccezione di NFS per il quale esiste però il supporto per le
+ versioni NFSv2 e NFSv3 del protocollo, con NFSv4 esistono invece delle ACL
+ native che hanno una semantica diversa, su di esse possono mappare le ACL
+ POSIX, ma l'inverso è possibile solo in forma incompleta.} su cui le si
+vogliono utilizzare con l'opzione \texttt{acl} attiva. Dato che si tratta di
+una estensione è infatti opportuno utilizzarle soltanto laddove siano
+necessarie.
Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
-costituita da un \textsl{tipo}, da un eventuale
-\textsl{qualificatore},\footnote{deve essere presente soltanto per le voci di
- tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi.
-Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
-permessi di accesso, detta \textit{access ACL}. Inoltre per le directory si
-può impostare una ACL aggiuntiva, detta ``\textit{Default ACL}'', che serve ad
-indicare quale dovrà essere la ACL assegnata di default nella creazione di un
-file all'interno della directory stessa. Come avviene per i permessi le ACL
-possono essere impostate solo del proprietario del file, o da un processo con
-la capacità \const{CAP\_FOWNER}.
+costituita da un \textsl{tipo}, da un eventuale \textsl{qualificatore} (deve
+essere presente soltanto per le voci di tipo \const{ACL\_USER} e
+\const{ACL\_GROUP}) e da un insieme di permessi. Ad ogni oggetto sul
+filesystem si può associare una ACL che ne governa i permessi di accesso,
+detta \textit{access ACL}. Inoltre per le directory si può impostare una ACL
+aggiuntiva, detta ``\textit{Default ACL}'', che serve ad indicare quale dovrà
+essere la ACL assegnata di default nella creazione di un file all'interno
+della directory stessa. Come avviene per i permessi le ACL possono essere
+impostate solo del proprietario del file, o da un processo con la capacità
+\const{CAP\_FOWNER}.
\begin{table}[htb]
\centering
Una ACL può poi contenere un numero arbitrario di voci di tipo
\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
permessi assegnati all'utente e al gruppo indicato dal relativo qualificatore.
-Ovviamente ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
+Ovviamente ciascuna di queste voci dovrà fare riferimento a un utente o a un
gruppo diverso, e non corrispondenti a quelli proprietari del file. Inoltre se
in una ACL esiste una voce di uno di questi due tipi, è obbligatoria anche la
presenza di una ed una sola voce di tipo \const{ACL\_MASK}, che negli altri
vengono sempre utilizzati gli identificatori del gruppo \textit{effective} del
processo, ma in caso di presenza di una ACL sul file, i passi attraverso i
quali viene stabilito se il processo ha il diritto di accesso sono i seguenti:
-\begin{enumerate}
+\begin{enumerate*}
\item Se l'\ids{UID} del processo è nullo (se cioè si è l'amministratore)
l'accesso è sempre garantito senza nessun controllo.\footnote{più
precisamente se si devono avere le capacità \const{CAP\_DAC\_OVERRIDE} per
\end{itemize*}
\item Se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
l'accesso è consentito, altrimenti l'accesso è negato.
-\end{enumerate}
+\end{enumerate*}
I passi di controllo vengono eseguiti esattamente in questa sequenza, e la
decisione viene presa non appena viene trovata una corrispondenza con gli
\const{ACL\_GROUP\_OBJ}).
Per la gestione delle ACL lo standard \textit{POSIX 1003.1e Draft 17} ha
-previsto delle apposite funzioni ed tutta una serie di tipi di dati
-dedicati;\footnote{fino a definire un tipo di dato e delle costanti apposite
- per identificare i permessi standard di lettura, scrittura ed esecuzione.}
-tutte le operazioni devono essere effettuate attraverso tramite questi tipi di
-dati, che incapsulano tutte le informazioni contenute nelle ACL. La prima di
-queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
-è:
+previsto delle apposite funzioni ed tutta una serie di tipi di dati dedicati,
+arrivando fino a definire un tipo di dato e delle costanti apposite per
+identificare i permessi standard di lettura, scrittura ed esecuzione. Tutte
+le operazioni devono essere effettuate attraverso tramite questi tipi di dati,
+che incapsulano tutte le informazioni contenute nelle ACL.
+
+La prima di queste funzioni che prendiamo in esame (si ricordi che come per
+tutte le altre per poterla usare occorre invocare il compilatore con l'opzione
+\texttt{-l acl}) è \funcd{acl\_init}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
in caso di fallimento verrà restituito un puntatore nullo di tipo
``\code{(acl\_t) NULL}'' e si dovrà, in questa come in tutte le funzioni
seguenti che restituiscono un oggetto di tipo \type{acl\_t}, confrontare il
-valore di ritorno della funzione con \val{NULL}.\footnote{a voler essere
- estremamente pignoli si dovrebbe usare ``\code{(acl\_t) NULL}'', ma è
- sufficiente fare un confronto direttamente con \val{NULL} essendo cura del
- compilatore fare le conversioni necessarie.}
+valore di ritorno della funzione con \val{NULL} (anche se, a voler essere
+estremamente pignoli, si dovrebbe usare ``\code{(acl\_t) NULL}'', ma è
+sufficiente fare un confronto direttamente con \val{NULL} essendo cura del
+compilatore fare le conversioni necessarie).
Una volta che si siano completate le operazioni sui dati di una ACL la memoria
allocata per un oggetto \type{acl\_t} dovrà essere liberata esplicitamente
Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
della ACL correntemente associata ad un file, che può essere identificato
tramite un file descriptor usando \func{acl\_get\_fd} o con un
-\textit{pathname} usando \func{acl\_get\_file}. Nel caso di quest'ultima
-funzione, che può richiedere anche la ACL relativa ad una directory, il
-secondo argomento \param{type} consente di specificare se si vuole ottenere la
-ACL di default o quella di accesso. Questo argomento deve essere di tipo
-\typed{acl\_type\_t} e può assumere solo i due valori riportati in
-tab.~\ref{tab:acl_type}.
+\textit{pathname} usando \func{acl\_get\_file}.
+
+Nel caso di quest'ultima funzione, che può richiedere anche la ACL relativa ad
+una directory, il secondo argomento \param{type} consente di specificare se si
+vuole ottenere la ACL di default o quella di accesso. Questo argomento deve
+essere di tipo \typed{acl\_type\_t} e può assumere solo i due valori riportati
+in tab.~\ref{tab:acl_type}.
\begin{table}[htb]
\centering
verrà restituita una ACL vuota.
Infine si potrà creare una ACL direttamente dalla sua rappresentazione
-testuale con la funzione \funcd{acl\_from\_text}, il cui prototipo è:
+testuale con la funzione \funcd{acl\_from\_text}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
la rappresentazione testuale della ACL che si vuole creare, la memoria
necessaria viene automaticamente allocata ed in caso di successo viene
restituito come valore di ritorno un oggetto di tipo \type{acl\_t} con il
-contenuto della stessa, che come per le precedenti funzioni, dovrà essere
+contenuto della stessa, che, come per le precedenti funzioni, dovrà essere
disallocato esplicitamente al termine del suo utilizzo.
La rappresentazione testuale di una ACL è quella usata anche dai comandi
\end{Example}
dove il tipo può essere uno fra \texttt{user}, \texttt{group}, \texttt{other}
e \texttt{mask}. Il qualificatore è presente solo per \texttt{user} e
-\texttt{group} e indica l'utente o il gruppo a cui la voce si riferisce; i
-permessi sono espressi con una tripletta di lettere analoga a quella usata per
-i permessi dei file.\footnote{vale a dire ``\texttt{r}'' per il permesso di
- lettura, ``\texttt{w}'' per il permesso di scrittura, ``\texttt{x}'' per il
- permesso di esecuzione (scritti in quest'ordine) e ``\texttt{-}'' per
- l'assenza del permesso.}
+\texttt{group} ed indica l'utente o il gruppo a cui la voce si riferisce,
+mentre i permessi sono espressi con una tripletta di lettere analoga a quella
+usata per i permessi dei file, vale a dire ``\texttt{r}'' per il permesso di
+lettura, ``\texttt{w}'' per il permesso di scrittura, ``\texttt{x}'' per il
+permesso di esecuzione (scritti in quest'ordine) e ``\texttt{-}'' per
+l'assenza del permesso.
Un possibile esempio di rappresentazione della ACL di un file ordinario a cui,
oltre ai permessi ordinari, si è aggiunto un altro utente con un accesso in
group::r--
other::r--
user:piccardi:r--
+group:gapil:r--
\end{Example}
Va precisato che i due tipi \texttt{user} e \texttt{group} sono usati
-rispettivamente per indicare delle voci relative ad utenti e
-gruppi,\footnote{cioè per voci di tipo \const{ACL\_USER\_OBJ} e
- \const{ACL\_USER} per \texttt{user} e \const{ACL\_GROUP\_OBJ} e
- \const{ACL\_GROUP} per \texttt{group}.} applicate sia a quelli proprietari
-del file che a quelli generici; quelle dei proprietari si riconoscono per
-l'assenza di un qualificatore, ed in genere si scrivono per prima delle altre.
-Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
-questa forma si possono anche inserire dei commenti precedendoli con il
-carattere ``\texttt{\#}''.
+rispettivamente per indicare delle voci relative ad utenti e gruppi (cioè per
+voci di tipo \const{ACL\_USER\_OBJ} e \const{ACL\_USER} per \texttt{user} e
+\const{ACL\_GROUP\_OBJ} e \const{ACL\_GROUP} per \texttt{group}) applicate sia
+a quelli proprietari del file che a quelli generici. Quelle dei proprietari si
+riconoscono per l'assenza di un qualificatore, ed in genere si scrivono per
+prima delle altre. Il significato delle voci di tipo \texttt{mask} e
+\texttt{mark} è evidente. Usando questa forma estesa si possono anche inserire
+dei commenti nel testo precedendoli con il carattere ``\texttt{\#}''.
La forma breve prevede invece la scrittura delle singole voci su una riga,
separate da virgole; come specificatori del tipo di voce si possono usare le
testuale della ACL in caso di successo e \var{NULL} per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \item[\errcode{EINVAL}] o \param{acl} non è un puntatore ad una ACL o la ACL
+ che esso indica non è valida o non può esser tradotta in forma testuale.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
\end{errlist}
}
\end{funcproto}
-La funzione restituisce il puntatore ad una stringa terminata da NUL
-contenente la rappresentazione in forma estesa della ACL passata come
+La funzione restituisce il puntatore ad una stringa, terminata da un NUL,
+contenente la rappresentazione testuale in forma estesa della ACL passata come
argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
-essere liberata, quando non più necessaria, con \func{acl\_free}. Se
-nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
-intera in questa verrà restituita (come \textit{value result argument}) la
-dimensione della stringa con la rappresentazione testuale, non comprendente il
-carattere nullo finale.
+essere liberata, quando non più necessaria, con \func{acl\_free}. Se
+nell'argomento \param{len\_p} si passa come valore il puntatore ad una
+variabile intera, in questa verrà restituita (come \textit{value result
+ argument}) la dimensione della stringa con la rappresentazione testuale, non
+comprendente il carattere nullo finale.
La seconda funzione, che permette di controllare con una gran dovizia di
particolari la generazione della stringa contenente la rappresentazione
\hline
\hline
\constd{TEXT\_ABBREVIATE} & Stampa le voci in forma abbreviata.\\
- \constd{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
- \ids{UID} e \ids{GID}.\\
+ \constd{TEXT\_NUMERIC\_IDS} & Non effettua la risoluzione di
+ \ids{UID} e \ids{GID} lasciando i valori
+ numerici.\\
\constd{TEXT\_SOME\_EFFECTIVE}&Per ciascuna voce che contiene permessi che
vengono eliminati dalla \const{ACL\_MASK}
viene generato un commento con i permessi
}
\end{funcproto}
-Ottenuta con \func{acl\_size} la dimensione per il buffer di una ACL lo si
-potrà allocare direttamente con \func{malloc}. La rappresentazione binaria di
-una ACL si potrà invece ottenere con la funzione \funcd{acl\_copy\_ext}, il
-cui prototipo è:
+Ottenuta con \func{acl\_size} la dimensione del buffer necessaria per potervi
+memorizzare una ACL questo dovrà potrà essere allocato direttamente con
+\func{malloc}, ed a questo punto vi si potrà salvare la rappresentazione
+binaria della precedente ACL utilizzando la funzione \funcd{acl\_copy\_ext},
+il cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
della ACL in caso di successo e $-1$ per un errore, nel qual caso
\var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
- \param{size} è negativo o nullo.
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida, o
+ \param{acl} non è un puntatore ad una ACL o \param{size} è negativo o
+ nullo.
\item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
- dimensione della rappresentazione della ACL.
+ dimensione della rappresentazione binaria della ACL.
\end{errlist}
}
\end{funcproto}
La funzione scriverà la rappresentazione binaria della ACL indicata da
-\param{acl} sul buffer di dimensione \param{size}
-all'indirizzo \param{buf\_p}, restituendo la dimensione della stessa come
-valore di ritorno. Qualora la dimensione della rappresentazione ecceda il
-valore di \param{size} la funzione fallirà con un errore di
-\errcode{ERANGE}. La funzione non ha nessun effetto sulla ACL indicata
-da \param{acl}.
+\param{acl} sul buffer di dimensione \param{size} all'indirizzo
+\param{buf\_p}, restituendo la dimensione della stessa come valore di
+ritorno. Qualora la dimensione della rappresentazione ecceda il valore di
+\param{size} la funzione fallirà con un errore di \errcode{ERANGE}. La
+funzione non ha nessun effetto sulla ACL indicata da \param{acl}.
Viceversa se si vuole ripristinare una ACL a partire da una rappresentazione
binaria si potrà usare la funzione \funcd{acl\_copy\_int}, il cui prototipo è:
Una volta che si disponga della ACL desiderata, questa potrà essere impostata
su un file o una directory. Per impostare una ACL sono disponibili due
-funzioni; la prima è \funcd{acl\_set\_file}, che opera sia su file che su
-directory, ed il cui prototipo è:
+funzioni: \funcd{acl\_set\_file}, che opera sia su file che su directory
+usando un \textit{pathname}, e \funcd{acl\_set\_file} che opera solo su file
+usando un file descriptor; i rispettivi prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
\fhead{sys/acl.h}
\fdecl{int acl\_set\_file(const char *path, acl\_type\_t type, acl\_t acl)}
\fdesc{Imposta una ACL su un file o una directory.}
+\fdecl{int acl\_set\_fd(int fd, acl\_t acl)}
+\fdesc{Imposta una ACL su un file descriptor.}
}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+{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{EACCES}] o un generico errore di accesso a \param{path} o il
valore di \param{type} specifica una ACL il cui tipo non può essere
assegnato a \param{path}.
\item[\errcode{EINVAL}] o \param{acl} non è una ACL valida, o \param{type}
- ha un valore non corretto.
+ ha un valore non corretto per \func{acl\_set\_file} o o ha più voci di
+ quante se ne possono assegnare al file per \func{acl\_set\_fd}.
\item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
dati aggiuntivi della ACL.
\item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
contenuto in un filesystem che non supporta le ACL.
\end{errlist}
- ed inoltre \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR},
- \errval{EPERM}, \errval{EROFS} nel loro significato generico.}
+ ed inoltre nel loro significato generico \errval{EPERM}, \errval{EROFS} per
+ entrambe, \errval{EBADF} per \func{acl\_set\_fd}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{ENOTDIR} per \func{acl\_set\_file}.}
\end{funcproto}
-La funzione consente di assegnare la ACL contenuta in \param{acl} al file o
-alla directory indicate dal \textit{pathname} \param{path}, mentre
-con \param{type} si indica il tipo di ACL utilizzando le costanti di
-tab.~\ref{tab:acl_type}, ma si tenga presente che le ACL di default possono
-essere solo impostate qualora \param{path} indichi una directory. Inoltre
-perché la funzione abbia successo la ACL dovrà essere valida, e contenere
-tutti le voci necessarie, unica eccezione è quella in cui si specifica una ACL
-vuota per cancellare la ACL di default associata a
-\param{path}.\footnote{questo però è una estensione della implementazione delle
- ACL di Linux, la bozza di standard POSIX.1e prevedeva l'uso della apposita
- funzione \funcd{acl\_delete\_def\_file}, che prende come unico argomento il
- \textit{pathname} della directory di cui si vuole cancellare l'ACL di
- default, per i dettagli si ricorra alla pagina di manuale.} La seconda
-funzione che consente di impostare una ACL è \funcd{acl\_set\_fd}, ed il suo
-prototipo è:
-
-\begin{funcproto}{
-\fhead{sys/types.h}
-\fhead{sys/acl.h}
-\fdecl{int acl\_set\_fd(int fd, acl\_t acl)}
-\fdesc{Imposta una ACL su un file descriptor.}
-}
-
-{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}] o \param{acl} non è una ACL valida, o ha più voci di
- quante se ne possono assegnare al file indicato da \param{fd}.
- \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per contenere i
- dati aggiuntivi della ACL.
- \item[\errcode{ENOTSUP}] si è cercato di impostare una ACL su un file
- contenuto in un filesystem che non supporta le ACL.
- \end{errlist}
- ed inoltre \errval{EBADF}, \errval{EPERM}, \errval{EROFS} nel loro
- significato generico.
-}
-\end{funcproto}
-
-La funzione è del tutto è analoga a \func{acl\_set\_file} ma opera
-esclusivamente sui file identificati tramite un file descriptor. Non dovendo
-avere a che fare con directory (e con la conseguente possibilità di avere una
-ACL di default) la funzione non necessita che si specifichi il tipo di ACL,
-che sarà sempre di accesso, e prende come unico argomento, a parte il file
+Con \func{acl\_set\_file} si assegna la ACL contenuta in \param{acl} al file o
+alla directory indicate da \param{path}, con \param{type} che indica il tipo
+di ACL con le costanti di tab.~\ref{tab:acl_type}; si tenga presente però che
+le ACL di default possono essere solo impostate qualora \param{path} indichi
+una directory. Inoltre perché la funzione abbia successo la ACL dovrà essere
+valida, e contenere tutti le voci necessarie, con l'eccezione si specifica una
+ACL vuota per cancellare la ACL di default associata a \param{path}, valida
+solo in caso di directory.\footnote{questo però è una estensione della
+ implementazione delle ACL di Linux, la bozza di standard POSIX.1e prevedeva
+ l'uso della apposita funzione \funcd{acl\_delete\_def\_file}, che prende
+ come unico argomento il \textit{pathname} della directory di cui si vuole
+ cancellare l'ACL di default, per i dettagli si ricorra alla pagina di
+ manuale.}
+
+La seconda funzione, \func{acl\_set\_fd}, è del tutto è analoga alla prima, ma
+non dovendo avere a che fare con directory (e la conseguente possibilità di
+avere una ACL di default) non necessita che si specifichi il tipo di ACL, che
+sarà sempre di accesso, e prende come unico argomento, a parte il file
descriptor, la ACL da impostare.
Le funzioni viste finora operano a livello di una intera ACL, eseguendo in una
funzioni però sono alquanto macchinose da utilizzare per cui è molto più
semplice operare direttamente sulla rappresentazione testuale. Questo è il
motivo per non tratteremo nei dettagli dette funzioni, fornendone solo una
-descrizione sommaria; chi fosse interessato potrà ricorrere alle pagine di
+descrizione sommaria; chi fosse interessato può ricorrere alle pagine di
manuale.
Se si vuole operare direttamente sui contenuti di un oggetto di tipo
prima funzione si potrà poi ripetere la lettura per ottenere i puntatori alle
singole voci successive alla prima.
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{\codesamplewidth}
+ \includecodesample{listati/mygetfacl.c}
+ \end{minipage}
+ \normalsize
+ \caption{Corpo principale del programma \texttt{mygetfacl.c}.}
+ \label{fig:proc_mygetfacl}
+\end{figure}
+
Una volta ottenuti detti puntatori si potrà operare sui contenuti delle
singole voci: con le funzioni \funcm{acl\_get\_tag\_type},
\funcm{acl\_get\_qualifier}, \funcm{acl\_get\_permset} si potranno leggere
si è distribuito il programma \texttt{mygetfacl.c}, che consente di leggere le
ACL di un file, passato come argomento.
-\begin{figure}[!htb]
- \footnotesize \centering
- \begin{minipage}[c]{\codesamplewidth}
- \includecodesample{listati/mygetfacl.c}
- \end{minipage}
- \normalsize
- \caption{Corpo principale del programma \texttt{mygetfacl.c}.}
- \label{fig:proc_mygetfacl}
-\end{figure}
-
La sezione principale del programma, da cui si è rimossa la sezione sulla
gestione delle opzioni, è riportata in fig.~\ref{fig:proc_mygetfacl}. Il
programma richiede un unico argomento (\texttt{\small 16-20}) che indica il
\textit{inode}) da parte di utenti e gruppi.
Dato che la funzionalità ha senso solo per i filesystem su cui si mantengono i
-dati degli utenti\footnote{in genere la si attiva sul filesystem che contiene
- le \textit{home} degli utenti, dato che non avrebbe senso per i file di
- sistema che in genere appartengono all'amministratore.} essa deve essere
-attivata esplicitamente. Questo si fa, per tutti i filesystem che le
-supportano, tramite due distinte opzioni di montaggio, \texttt{usrquota} e
-\texttt{grpquota} che abilitano le quote rispettivamente per gli utenti e per
-i gruppi. Così è possibile usare le limitazioni sulle quote o sugli utenti o
+dati degli utenti essa deve essere attivata esplicitamente.\footnote{in genere
+ la si attiva sul filesystem che contiene le \textit{home} degli utenti, dato
+ che non avrebbe senso per i file di sistema che in genere appartengono
+ all'amministratore.} Questo si fa, per tutti i filesystem che le supportano,
+tramite due distinte opzioni di montaggio, \texttt{usrquota} e
+\texttt{grpquota}, che abilitano le quote rispettivamente per gli utenti e per
+i gruppi. Così è possibile usare le limitazioni delle quote o sugli utenti o
sui gruppi o su entrambi.
+Dal kernel 4.1, ed inizialmente solo per il filesystem XFS, sono diventate
+disponibili un terzo tipo di quote, dette \textit{project quota}, che
+consentono di applicare delle quote ad un ``\textsl{progetto}'', identificato
+come ramo di albero sotto una directory, per il quale possono essere imposti
+dei limiti (di nuovo in termini di spazio disco o \textit{inode}) per i file
+che ne fanno parte. Si può così porre dei limiti sul contenuto di un ramo di
+albero.
+
Il meccanismo prevede che per ciascun filesystem che supporta le quote disco
-(i vari \textit{extN}, \textit{btrfs}, \textit{XFS}, \textit{JFS},
-\textit{ReiserFS}) il kernel provveda sia a mantenere aggiornati i dati
-relativi al consumo delle risorse da parte degli utenti e dei gruppi, che a
-far rispettare i limiti imposti dal sistema, con la generazione di un errore
-di \errcode{EDQUOT} per tutte le operazioni sui file che porterebbero ad un
+(i vari \acr{extN}, \acr{Btrfs}, \acr{XFS}, \acr{JFS}, \acr{ReiserFS}) il
+kernel provveda sia a mantenere aggiornati i dati relativi al consumo delle
+risorse da parte degli utenti e dei gruppi (e del progetto), che a far
+rispettare i limiti imposti dal sistema, con la generazione di un errore di
+\errcode{EDQUOT} per tutte le operazioni sui file che porterebbero ad un
superamento degli stessi. Si tenga presente che questi due compiti sono
separati, il primo si attiva al montaggio del filesystem con il supporto per
le quote, il secondo deve essere abilitato esplicitamente.
riservati nella directory radice del filesystem su cui si sono attivate le
quote, uno per le quote utente e l'altro per le quote gruppo.\footnote{la cosa
vale per tutti i filesystem tranne \textit{XFS} che mantiene i dati
- internamente.} Con la versione 2 del supporto delle quote, che da anni è
+ internamente, compresi quelli per le \textit{project quota}, che pertanto,
+ essendo questo l'unico filesyste che le supporta, non hanno un file ad esse
+ riservato.} Con la versione 2 del supporto delle quote, che da anni è
l'unica rimasta in uso, questi file sono \texttt{aquota.user} e
\texttt{aquota.group}, in precedenza erano \texttt{quota.user} e
\texttt{quota.group}.
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EACCES}] si è richiesto \const{Q\_QUOTAON}, ma il file delle
- quote indicato da \param{addr} non esiste o non è un file ordinario.
+ quote indicato da \param{addr} esiste ma non è un file ordinario o no sta
+ su \param{dev}.
\item[\errcode{EBUSY}] si è richiesto \const{Q\_QUOTAON}, ma le quote sono
già attive.
- \item[\errcode{EFAULT}] \param{addr} non è un puntatore valido.
+ \item[\errcode{EFAULT}] \param{addr} o \param{dev} non sono un puntatori
+ validi.
\item[\errcode{EINVAL}] o \param{cmd} non è un comando valido,
o il dispositivo \param{dev} non esiste.
\item[\errcode{EIO}] errore di lettura/scrittura sul file delle quote.
% TODO rivedere gli errori
La funzione richiede che il filesystem sul quale si vuole operare, che deve
-essere specificato con il nome del relativo file di dispositivo
-nell'argomento \param{dev}, sia montato con il supporto delle quote
-abilitato. Per le operazioni che lo richiedono inoltre si dovrà indicare con
-l'argomento \param{id} l'utente o il gruppo (specificati rispettivamente per
-\ids{UID} e \ids{GID}) su cui si vuole operare, o altri dati relativi
-all'operazione. Alcune operazioni più complesse usano infine
-l'argomento \param{addr} per indicare un indirizzo ad un area di memoria il
-cui utilizzo dipende dall'operazione stessa.
+essere specificato con il nome del relativo file di dispositivo nell'argomento
+\param{dev}, sia montato con il supporto delle quote abilitato. Per le
+operazioni che lo richiedono inoltre si dovrà indicare con l'argomento
+\param{id} l'utente o il gruppo o il progetto (specificati rispettivamente per
+\ids{UID}, \ids{GID} o identificativo) su cui si vuole operare,\footnote{nel
+ caso di \textit{project quota} gli identificativi vengono associati alla
+ directory base del progetto nel file \file{/etc/projects}, ed impostati con
+ \cmd{xfs\_quota}, l'argomento è di natura sistemistica e va al di là dello
+ scopo di questo testo.} o altri dati relativi all'operazione. Alcune
+operazioni più complesse usano infine l'argomento \param{addr} per indicare un
+indirizzo ad un area di memoria il cui utilizzo dipende dall'operazione
+stessa.
La funzione prevede la possibilità di eseguire una serie operazioni sulle
quote molto diverse fra loro, la scelta viene effettuata tramite il primo
}
La macro consente di specificare, oltre al tipo di operazione, da indicare con
-l'argomento \param{subcmd} se questa deve applicarsi alle quote utente o alle
-quote gruppo. Questo viene indicato dall'argomento \param{type} che deve
-essere sempre definito ed assegnato ad uno fra i due valori \const{USRQUOTA} o
-\const{GRPQUOTA}.
+l'argomento \param{subcmd}, se questa deve applicarsi alle quote utente o alle
+quote gruppo o alle quote progetto. Questo viene indicato dall'argomento
+\param{type} che deve essere sempre definito ed assegnato ad uno fra i valori
+\const{USRQUOTA}, \const{GRPQUOTA} e \const{PRJQUOTA}.
\begin{table}[htb]
\centering
prestazioni migliori in conseguenza di un minore frazionamento dei dati e di
indici più corti.}
-Come accennato realizzazione delle quote disco ha visto diverse revisioni, con
-modifiche sia del formato delle stesse che dei nomi dei file utilizzate. Per
-questo alcune operazioni di gestione (in particolare \const{Q\_QUOTAON} e
-\const{Q\_GETFMT}) e possono fare riferimento a queste versioni, che vengono
-identificate tramite le costanti di tab.~\ref{tab:quotactl_id_format}.
+Come accennato la realizzazione delle quote disco ha visto diverse revisioni,
+con modifiche sia del formato delle stesse che dei nomi dei file
+utilizzati. Per questo alcune operazioni di gestione (in particolare
+\const{Q\_QUOTAON} e \const{Q\_GETFMT}) e possono fare riferimento a queste
+versioni, che vengono identificate tramite le costanti di
+tab.~\ref{tab:quotactl_id_format}.
\begin{table}[htb]
\centering
% LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm RT
% LocalWords: fffffeff CapEff getcap scheduling lookup dqinfo SETINFO GETFMT
% LocalWords: NEWNS unshare nice NUMA ioctl journaling close XOPEN fdopendir
-% LocalWords: btrfs mkostemp extN ReiserFS JFS Posix usrquota grpquota EDQUOT
+% LocalWords: Btrfs mkostemp extN ReiserFS JFS Posix usrquota grpquota EDQUOT
% LocalWords: aquota quotacheck limit grace period quotactl cmd caddr addr dqb
% LocalWords: QUOTAON ENODEV ENOPKG ENOTBLK GETQUOTA SETQUOTA SETUSE SETQLIM
% LocalWords: forced allowed sendmail SYSLOG WAKE ALARM CLOCK BOOTTIME dqstats
% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev FDCWD functions
% LocalWords: faccessat grpid lacl AppArmor capsetp mygetfacl table Tb MSK
% LocalWords: LAZYTIME submount peer protected hardlink symlinks silly RDWR
+% LocalWords: renames unreachable CLOEXEC mkstemps mkostemps suffixlen Aug
+% LocalWords: prefissoXXXXXXsuffisso nell'I fstatat statx sull' drwxrwxrwt
+% LocalWords: Disalloca
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
-% LocalWords: renames unreachable CLOEXEC mkstemps mkostemps suffixlen Aug
-% LocalWords: prefissoXXXXXXsuffisso nell'I fstatat statx sull' drwxrwxrwt
-% LocalWords: Disalloca
projects / gapil.git / blobdiff