successivo \acr{ext4}. In futuro è previsto che questo debba essere sostituito
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 di
+sviluppo.\footnote{si fa riferimento al momento dell'ultima revisione di
questo paragrafo, l'inizio del 2012.}
Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
filesystem e ciascuno ha i suoi, pertanto si rimanda alla documentazione della
pagina di manuale di questo comando e dei singoli filesystem.
-Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
-disponibile nella directory specificata come \textit{mount point}, il
+Dopo l'esecuzione della funzione il contenuto del filesystem viene reso
+disponibile nella directory specificata come \textit{mount point} ed il
precedente contenuto di detta directory viene mascherato dal contenuto della
directory radice del filesystem montato. Fino ai kernel della serie 2.2.x non
era possibile montare un filesystem se un \textit{mount point} era già in uso,
In realtà quella di montare un filesystem è solo una delle operazioni che si
possono effettuare con \func{mount}, la funzione infatti è dedicata a tutte le
operazioni relative alla gestione del montaggio dei filesystem e dei
-\textit{mount-point}. Ad esempio fin dalle sue origini poteva essere
+\textit{mount point}. Ad esempio fin dalle sue origini poteva essere
utilizzata per effettuare il rimontaggio di un filesystem con opzioni diverse,
ed a partire dal kernel 2.4.x è divenuto possibile usarla per spostare
atomicamente un \textit{mount point} da una directory ad un'altra, per montare
lo stesso filesystem in diversi \textit{mount point}, per montare una
-directory su un'altra (il cosiddetto \textit{bind-mount}).
+directory su un'altra (il cosiddetto \textit{bind mount}).
\itindend{mount~point}
in base al contenuto di \param{mountflags}, la scelta viene effettuata
controllando nell'ordine:
\begin{enumerate*}
-\item se è presente il flag \const{MS\_REMOUNT} nel qual caso verrà eseguito
+\item se è presente il flag \const{MS\_REMOUNT}, nel qual caso verrà eseguito
il rimontaggio del filesystem, con le nuove opzioni indicate da \param{data}
e dagli altri flag di \param{mountflags};
-\item se è presente il flag \const{MS\_BIND} nel qual caso verrà eseguito un
- \textit{bind-mount} (argometo che tratteremo più avanti);
+\item se è presente il flag \const{MS\_BIND}, nel qual caso verrà eseguito un
+ \textit{bind mount} (argomento che tratteremo più avanti);
\item se è presente uno fra \const{MS\_SHARED}, \const{MS\_PRIVATE},
- \const{MS\_SLAVE}, \const{MS\_UNBINDABLE} nel qual caso viene cambiata la
+ \const{MS\_SLAVE}, \const{MS\_UNBINDABLE}, nel qual caso verrà cambiata la
modalità di propagazione del montaggio (detti valori sono mutualmente
esclusivi).
-\item se è presente \const{MS\_MOVE}, nel qual caso viene effettuato uno
- spostamento del \textit{mount-point};
+\item se è presente \const{MS\_MOVE}, nel qual caso verrà effettuato uno
+ spostamento del \textit{mount point};
\item se nessuno dei precedenti è presente si tratta di una ordinaria
operazione di montaggio di un filesystem.
\end{enumerate*}
l'effetto di alcuni di questi flag possono cambiare se usati in combinazione
con gli altri che vengono prima nella sequenza (è quanto avviene ad esempio
per \const{MS\_BIND} usato con \const{MS\_REMOUNT}). Tratteremo questi
-\textit{mount flags} speciali per primi, tornando sugli altri più avanti.
+\textit{mount flags} speciali per primi, nell'ordine appena illustrato,
+tornando sugli altri più avanti.
Usando il flag \constd{MS\_REMOUNT} si richiede a \func{mount} di rimontare un
filesystem già montato cambiandone le opzioni di montaggio in maniera atomica
-(non è cioè necessario smontare e rimontare il filsystem per effettuare il
-cambiamento). In questo modo si possono modificare le opzioni del filesystem
-anche se questo è in uso. Gli argomenti \param{source} e \param{target} devono
-essere gli stessi usati per il montaggio originale, mentre sia \param{data}
-che \param{mountflags} conterranno le nuove opzioni, \param{filesystemtype}
-viene ignorato. Perché l'operazione abbia successo occorre comunque che il
-cambiamento sia possibile (ad esempio non sarà possibile rimontare in sola
-lettura un filesystem su cui sono aperti file per la lettura/scrittura).
+(non è cioè necessario smontare e rimontare il filesystem per effettuare il
+cambiamento). Questa operazione consente di modificare le opzioni del
+filesystem anche se questo è in uso. Gli argomenti \param{source} e
+\param{target} devono essere gli stessi usati per il montaggio originale,
+mentre sia \param{data} che \param{mountflags} conterranno le nuove opzioni,
+\param{filesystemtype} viene ignorato. Perché l'operazione abbia successo
+occorre comunque che il cambiamento sia possibile (ad esempio non sarà
+possibile rimontare in sola lettura un filesystem su cui sono aperti file per
+la lettura/scrittura).
Qualunque opzione specifica del filesystem indicata con \param{data} può
essere modificata (ma si dovranno rielencare tutte quelle volute), mentre con
\const{MS\_NODEV}, \const{MS\_NODIRATIME}, \const{MS\_NOEXEC},
\const{MS\_NOSUID}, \const{MS\_RELATIME}, \const{MS\_RDONLY},
\const{MS\_STRICTATIME} e \const{MS\_SYNCHRONOUS}. Inoltre dal kernel 3.17 il
-comportamento relativo alle opzioni che operano sul tempo di ultimo accesso
-(vedi sez.~\ref{sec:file_file_times}) è cambiato e se non si è indicato
-nessuno dei vari \texttt{MS\_*ATIME} vengono mantenute le impostazioni
-esistenti anziché forzare l'uso di \const{MS\_RELATIME}.
+comportamento relativo alle opzioni che operano sui tempi di ultimo accesso
+dei file (vedi sez.~\ref{sec:file_file_times}) è cambiato e se non si è
+indicato nessuno dei vari \texttt{MS\_*ATIME} vengono mantenute le
+impostazioni esistenti anziché forzare l'uso di \const{MS\_RELATIME}.
\itindbeg{bind~mount}
che indicherà la directory su cui verrà effettuato il \textit{bind mount}. Gli
argomenti \param{filesystemtype} e \param{data} vengono ignorati.
-In sostanza quello che avviene è che in corrispondenza del \textit{pathname}
-indicato da \param{target} viene montato l'\textit{inode} di \param{source},
-così che la porzione di albero dei file presente sotto \param{source} diventi
-visibile allo stesso modo sotto \param{target}. Trattandosi esattamente dei
-dati dello stesso filesystem, ogni modifica fatta in uno qualunque dei due
-rami di albero sarà visibile nell'altro, visto che entrambi faranno
-riferimento agli stessi \textit{inode}.
+Quello che avviene con questa operazione è che in corrispondenza del
+\textit{pathname} indicato da \param{target} viene montato l'\textit{inode} di
+\param{source}, così che la porzione di albero dei file presente sotto
+\param{source} diventi visibile allo stesso modo sotto
+\param{target}. Trattandosi esattamente dei dati dello stesso filesystem, ogni
+modifica fatta in uno qualunque dei due rami di albero sarà visibile
+nell'altro, visto che entrambi faranno riferimento agli stessi \textit{inode}.
Dal punto di vista del VFS l'operazione è analoga al montaggio di un
filesystem proprio nel fatto che anche in questo caso si inserisce in
quest'ultima si fosse effettuato un altro montaggio. In tal caso infatti nella
porzione di albero sotto \param{source} si troverebbe il contenuto del nuovo
filesystem (o di un altro \textit{bind mount}) mentre sotto \param{target} ci
-sarebbe il contenuto presente nel filesystem originale.\footnote{questo evita
- anche il problema dei \textit{loop} di fig.~\ref{fig:file_link_loop}, dato
- che se anche si montasse su \param{target} una directory in cui essa è
- contenuta, il cerchio non potrebbe chiudersi perché ritornati a
- \param{target} dentro il \textit{bind mount} vi si troverebbe solo il
- contenuto originale e non si potrebbe tornare indietro.}
+sarebbe il contenuto presente nel filesystem originale.
L'unico altro \textit{mount flag} usabile direttamente con \const{MS\_BIND} è
\const{MS\_REC} che consente di eseguire una operazione di \textit{bind mount}
-ricorsiva, in cui nel nuovo \textit{mount point} vengono montati
-ricorsivamente anche tutti gli eventuali \textit{bind mount} presenti al di
-sotto della directory di origine.
+ricorsiva, in cui sotto \param{target} vengono montati ricorsivamente anche
+tutti gli eventuali ulteriori \textit{bind mount} già presenti sotto
+\param{source}.
-E' però possibile, a partire dal kernel 2.6.26 usare questo flag insieme a
+E' però possibile, a partire dal kernel 2.6.26, usare questo flag insieme a
\const{MS\_REMOUNT}, nel qual caso consente di effettuare una modifica delle
opzioni di montaggio del \textit{bind mount} ed in particolare effettuare il
cosiddetto \textit{read-only bind mount} in cui viene onorata anche la
presenza aggiuntiva del flag \const{MS\_RDONLY}. In questo modo si ottiene che
l'accesso ai file sotto \param{target} sia effettuabile esclusivamente in sola
-lettura, senza dover cambiare le opzione del \textit{mount-point} originale.
+lettura, mantenendo il normale accesso in lettura/scrittura sotto
+\param{source}.
Il supporto per il \textit{bind mount} consente di superare i limiti presenti
per gli \textit{hard link} (di cui parleremo in
sez.~\ref{sec:link_symlink_rename}) con la possibilità di fare riferimento
alla porzione dell'albero dei file di un filesystem presente a partire da una
-certa directory, utilizzando una qualunque altra directory, anche se questa
-sta su un filesystem diverso. Si può così fornire una alternativa all'uso dei
-collegamenti simbolici (di cui parleremo in
+certa directory utilizzando una qualunque altra directory, anche se questa sta
+su un filesystem diverso.\footnote{e non c'è neanche il problema di non esser
+ più in grado di cancellare un \textit{hard link} ad una directory sullo
+ stesso filesystem (vedi sez.~\ref{sec:link_symlink_rename}), per cui su
+ Linux questi non sono possibili, dato che in questo caso per la rimozione
+ del collegamento basta smontare \param{target}.} Si può così fornire una
+alternativa all'uso dei collegamenti simbolici (di cui parleremo in
sez.~\ref{sec:link_symlink_rename}) che funziona correttamente anche
all'intero di un \textit{chroot} (argomento su cui torneremo in
sez.~\ref{sec:file_chroot}).
I quattro flag \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
\const{MS\_UNBINDABLE} sono stati introdotti a partire dal kernel 2.6.15 per
realizzare l'infrastruttura dei cosiddetti \textit{shared subtree}, che
-estendono le funzionalità dei \textit{bind mount} per rendere possibile
-propagare automaticamente o meno le eventuali operazioni di montaggio eseguite
-al di sotto di un \textit{bind mount} a tutti gli altri \textit{mount-point}
-
-
-consentendo di impostare le
-politiche di propagazione di ulteriori eventuali operazione di montaggio
-effettuate al di sotto di un \textit{bind-mount}.
-
-L'uso di uno di questi \textit{mount flag}, che si ricordi sono esclusivi fra
-loro, è compatibile solo con In tutti gli altri casi \func{mount} fallirà con
-un errore di \errval{EINVAL}.
+estendono le funzionalità dei \textit{bind mount}. La funzionalità nasce
+dalle esigenze di poter utilizzare a pieno le funzionalità di isolamento
+fornite dal kernel per i processi (i \textit{namespace}, che tratteremo in
+sez.~\ref{sec:process_namespaces}) in particolare per quanto riguarda la
+possibilità di far avere ad un processo una visione ristretta dei filesystem
+montati (il \textit{mount namespace}), ma l'applicazione è comunque rilevante
+anche con un classico \textit{chroot} (vedi sez.~\ref{sec:file_chroot}).
+
+\itindbeg{submount}
+
+Abbiamo visto come nella modalità ordinaria in cui si esegue un
+\textit{bind mount} sotto \param{target} compaia lo stesso ramo di albero dei
+file presente sotto \param{source}, ma limitato a quanto presente nel
+filesystem di \param{source}; i risultati di un eventuale
+``\textit{submount}'' effettuato all'interno di \param{source} non saranno
+visibili. Ed anche se quelli presenti al momento dell'uso di \const{MS\_BIND}
+possono essere riottenuti usando \const{MS\_REC}, ogni eventuale
+``\textit{submount}'' successivo (che avvenga sotto \param{source} o sotto
+\param{target}) resterà ``\textsl{privato}'' al ramo di albero su cui è
+avvenuto.
+
+\itindend{submount}
+\itindbeg{mount peer group}
+
+Ci sono casi però in cui può risultare utile che eventuali
+``\textit{submount}'' siano visibili sui rami di albero presenti al di sotto
+di tutte le directory coinvolte in un \textit{bind mount}, anche se effettuati
+in un secondo tempo. Per poter ottenere questa funzionalità i
+\textit{bind mount} sono stati estesi introducendo i \textit{mount peer
+ group}, che consentono di raggrupparli in modo da poter inviare a ciascuno
+di essi tutti gli eventi relativi a montaggi o smontaggi effettuati al loro
+interno ed avere sempre una propagazione degli stessi che li renda coerenti.
+
+Quando si effettua un montaggio ordinario, o si esegue un \textit{bind mount},
+di default non viene utilizzato nessun \textit{mount peer group} ed il
+\textit{mount point} viene classificato come ``\textsl{privato}'', nel senso
+che abbiamo appena visto. Si può però marcare un \textit{mount point} come
+``\textsl{condiviso}'', ed in questo modo esso verrà associato ad un
+\textit{mount peer group} insieme a tutti gli altri ulteriori \textit{mount
+ point} per i quali sia stato eseguito un \textit{bind mount}. Questo fa sì
+che tutte le volte che si effettua un montaggio o uno smontaggio all'interno
+di uno qualunque dei \textit{mount point} del gruppo, questo venga propagato
+anche su tutti gli altri e sotto tutti sia visibile sempre lo stesso ramo di
+albero dei file.
+
+A completare l'infrastruttura degli \textit{shared subtree} sono state
+previste due ulteriori funzionalità: la prima è quella di marcare un
+\textit{mount point} come ``\textit{slave}'', in tal caso le operazioni di
+montaggio e smontaggio effettuate al suo interno non verranno più propagate
+agli altri membri del \textit{mount peer group} di cui fa parte, ma continuerà
+a ricevere quelle eseguite negli altri membri.
+
+La seconda funzionalità è quella di marcare un \textit{mount point} come
+``\textit{unbindable}''; questo anzitutto impedirà che possa essere usato come
+sorgente di un \textit{bind mount} ed inoltre lo renderà privato, con la
+conseguenza che quando è presente all'interno di altri \textit{bind mount},
+all'interno di questi si vedrà solo il contenuto originale e non quello
+risultante da eventuali ulteriori montaggi effettuati al suo interno.
+
+\itindend{mount peer group}
+
+I \textit{mount flag} che controllano le operazioni relative agli
+\textit{shared subtree} sono descritti nella lista seguente. Si ricordi che
+sono mutuamente esclusivi, e compatibili solo con l'uso degli ulteriori flag
+\const{MS\_REC} (che applica ricorsivamente l'operazione a tutti gli eventuali
+\textit{mount point} sottostanti) e \const{MS\_SILENT}; in tutti gli altri
+casi \func{mount} fallirà con un errore di \errval{EINVAL}. L'unico altro
+argomento che deve essere specificato quando li si usano è \param{target};
+\param{source}, \param{data} e \param{filesystem} sono ignorati.
\begin{basedescript}{\desclabelwidth{1.9cm}\desclabelstyle{\nextlinelabel}}
-\item[\constd{MS\_PRIVATE}] Marca un \textit{mount point} come privato. In
- questo caso \param{target} dovrà fare riferimento al \textit{mount point}
- che si intende marcare, e tutti gli altri argomenti verranno ignorati.
-
- Di default, finché non lo si marca altrimenti con una delle altre opzioni
- dell'interfaccia come \textit{shared subtree}, ogni \textit{mount point} è
- privato. Ogni \textit{bind mount} ottenuto da un \textit{mount point} di
- tipo \textit{private} si comporta come descritto nella trattazione di
- \const{MS\_BIND}. Si usa questo flag principalmente per revocare gli effetti
- delle altre opzioni e riportare il comportamento a quello ordinario.
+\item[\constd{MS\_PRIVATE}] Marca un \textit{mount point} come \textit{private
+ mount}. Di default, finché non lo si marca altrimenti con una delle altre
+ opzioni dell'interfaccia, ogni \textit{mount point} è privato. Ogni
+ \textit{bind mount} ottenuto da un \textit{mount point} privato si comporta
+ come descritto nella trattazione di \const{MS\_BIND}. Si usa questo flag
+ principalmente per revocare gli effetti delle altre opzioni e riportare il
+ comportamento a quello ordinario.
\item[\constd{MS\_SHARED}] Marca un \textit{mount point} come \textit{shared
- mount}. In questo caso \param{target} dovrà fare riferimento al
- \textit{mount point} che si intende marcare, e tutti gli altri argomenti
- verranno ignorati.
-
- Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
- effettuati da un \textit{mount point} marcato da essa siano di tipo
- \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro
- ogni ulteriore operazione di montaggio o smontaggio che avviene su una
- directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e
- smontaggio effettuate al di sotto di un qualunque \textit{mount point} così
- marcato verranno ``\textsl{propagate}'' a tutti i \textit{mount point} della
- stessa condivisione, e la sezione di albero di file vista al di sotto di
- ciascuno di essi sarà sempre identica.
+ mount}. Lo scopo dell'opzione è ottenere che tutti i successivi
+ \textit{bind mount} ottenuti da un \textit{mount point} così marcato siano
+ di tipo \textit{shared} e vengano inseriti nello stesso \textit{mount peer
+ group} in modo da ``\textsl{condivere}'' ogni ulteriore operazione di
+ montaggio o smontaggio. Con questa opzione le operazioni di montaggio e
+ smontaggio effettuate al di sotto di uno \textit{shared mount} vengono
+ automaticamente ``\textsl{propagate}'' a tutti gli altri membri del
+ \textit{mount peer group} di cui fa parte, in modo che la sezione di albero
+ dei file visibile al di sotto di ciascuno di essi sia sempre la stessa.
\item[\constd{MS\_SLAVE}] Marca un \textit{mount point} come \textit{slave
- mount}. In questo caso \param{target} dovrà fare riferimento al
- \textit{mount point} che si intende marcare, e tutti gli altri argomenti
- verranno ignorati.
-
- Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
- effettuati da un \textit{mount point} marcato da essa siano di tipo
- \textit{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di
- montaggio o smontaggio che avviene su una directory al di sotto del
- \textit{mount point} originale. Le operazioni di montaggio e smontaggio in
- questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
- originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
- essi potranno eseguire al loro interno ulteriori montaggi che non saranno
- propagati né negli altri né nel \textit{mount point} originale.
+ mount}. Se il \textit{mount point} è parte di un \textit{mount peer group}
+ esso diventerà di tipo \textit{slave}: le operazioni di montaggio e
+ smontaggio al suo interno non verranno più propagate agli altri membri del
+ gruppo, ma continuerà a ricevere quelle eseguite negli altri membri. Se non
+ esistono altri membri nel gruppo il \textit{mount point} diventerà privato,
+ negli altri casi non subirà nessun cambiamento.
\item[\constd{MS\_UNBINDABLE}] Marca un \textit{mount point} come
- \textit{unbindable mount}. In questo caso \param{target} dovrà fare
- riferimento al \textit{mount point} che si intende marcare, e tutti gli
- altri argomenti verranno ignorati.
-
- Un \textit{mount point} marcato in questo modo disabilita la capacità di
- eseguire dei \textit{bind mount} del suo contenuto. Si comporta cioè come
- allo stesso modo di un \textit{mount point} ordinario di tipo
- \textit{private} con in più la restrizione che nessuna sua sottodirectory
- (anche se relativa ad un ulteriore montaggio) possa essere utilizzata per un
- come sorgente di un \textit{bind mount}.
+ \textit{unbindable mount}. Un \textit{mount point} marcato in questo modo
+ non può essere usato per un \textit{bind mount} del suo contenuto. Si
+ comporta cioè come allo stesso modo di un \textit{mount point} ordinario di
+ tipo \textit{private} con in più la restrizione che nessuna sua
+ sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere
+ utilizzata come sorgente di un \textit{bind mount}.
\end{basedescript}
\itindend{shared~subtree}
-
-\begin{basedescript}{\desclabelwidth{1.9cm}\desclabelstyle{\nextlinelabel}}
+L'ultimo \textit{mount flag} che controlla una modalità operativa di
+\func{mount} è \constd{MS\_MOVE}, che consente di effettuare lo spostamento
+del \textit{mount point} di un filesystem. La directory del \textit{mount
+ point} originale deve essere indicata nell'argomento \param{source}, e la
+sua nuova posizione nell'argomento \param{target}. Tutti gli altri argomenti
+della funzione vengono ignorati.
+
+Lo spostamento avviene atomicamente, ed il ramo di albero presente sotto
+\param{source} sarà immediatamente visibile sotto \param{target}. Non esiste
+cioè nessun momento in cui il filesystem non risulti montato in una o
+nell'altra directory e pertanto è garantito che la risoluzione di
+\textit{pathname} relativi all'interno del filesystem non possa fallire.
+
+Elenchiamo infine i restanti \textit{mount flag}, il cui utilizzo non attiene
+alle operazioni di \func{mount}, ma soltanto l'impostazione di opzioni
+generiche relative al funzionamento di un filesystem e che vengono per lo più
+utilizzati solo in fase di montaggio:
+
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
\item[\constd{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una
directory venga immediatamente registrata su disco in maniera sincrona
(introdotta a partire dai kernel della serie 2.6). L'opzione si applica a
tutte le directory del filesystem, ma su alcuni filesystem è possibile
- impostarla a livello di singole directory o per i sottorami di una directory
+ impostarla a livello di singole directory o per i sotto-rami di una directory
con il comando \cmd{chattr}.\footnote{questo avviene tramite delle opportune
\texttt{ioctl} (vedi sez.~\ref{sec:file_fcntl_ioctl}).}
operazioni sulle directory non saranno più bufferizzate e si bloccheranno
fino all'arrivo dei dati sul disco prima che un programma possa proseguire.
+\item[\constd{MS\_LAZYTIME}] Modifica la modalità di registrazione di tempi
+ dei file (vedi sez.~\ref{sec:file_file_times}) per ridurre al massimo gli
+ accessi a disco (particolarmente utile per i portatili). Attivandolo i tempi
+ dei file vengono mantenuti in memoria e vengono salvati su disco solo in
+ quattro casi: quando c'è da eseguire un aggiornamento dei dati
+ dell'\textit{inode} per altri motivi, se viene usata una delle funzioni di
+ sincronizzazione dei dati su disco (vedi sez.~\ref{sec:file_sync}), se
+ l'\textit{inode} viene rimosso dalla memoria, o se è passato un giorno
+ dall'ultima registrazione. Introdotto a partire dal kernel 4.0.
+
+ In questo modo si possono ridurre significativamente le scritture su disco
+ mantenendo tutte le informazioni riguardo ai tempi dei file, riducendo anche
+ l'impatto dell'uso di \const{MS\_STRICTATIME}. Il costo da pagare è il
+ rischio, in caso di crash del sistema, di avere dati vecchi fino a 24 ore
+ per quel che riguarda i tempi dei file.
+
\item[\constd{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking}
(vedi sez.~\ref{sec:file_mand_locking}) sui file del filesystem. Per poterlo
utilizzare effettivamente però esso dovrà essere comunque attivato
esplicitamente per i singoli file impostando i permessi come illustrato in
sez.~\ref{sec:file_mand_locking}.
-\item[\constd{MS\_MOVE}] Effettua uno del spostamento del \textit{mount point}
- di un filesystem. La directory del \textit{mount point} originale deve
- essere indicata nell'argomento \param{source}, e la sua nuova posizione
- nell'argomento \param{target}. Tutti gli altri argomenti della funzione
- vengono ignorati.
-
- Lo spostamento avviene atomicamente, ed il ramo di albero presente
- sotto \param{source} sarà immediatamente visibile sotto \param{target}. Non
- esiste cioè nessun momento in cui il filesystem non risulti montato in una o
- nell'altra directory e pertanto è garantito che la risoluzione di
- \textit{pathname} relativi all'interno del filesystem non possa fallire.
-
\item[\constd{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
dell'\textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
- qualunque tipo di file. Dato che l'aggiornamento dell'\textit{access time}
- è una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
+ qualunque tipo di file. Dato che l'aggiornamento dell'\textit{access time} è
+ una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
elevato visto che una qualunque lettura comporta comunque una scrittura su
- disco,\footnote{e questo ad esempio ha conseguenze molto pesanti nell'uso
- della batteria sui portatili.} questa opzione consente di disabilitarla
- completamente. La soluzione può risultare troppo drastica dato che
- l'informazione viene comunque utilizzata da alcuni programmi, per cui nello
- sviluppo del kernel sono state introdotte altre opzioni che forniscono
- soluzioni più appropriate e meno radicali.
+ disco, questa opzione consente di disabilitarla completamente. La soluzione
+ può risultare troppo drastica dato che l'informazione viene comunque
+ utilizzata da alcuni programmi, per cui nello sviluppo del kernel sono state
+ introdotte altre opzioni che forniscono soluzioni più appropriate e meno
+ radicali.
\item[\constd{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
questo non venga modificato (ad esempio per ispezionare un filesystem
corrotto). All'avvio di default il kernel monta la radice in questa
modalità. Si tenga presente che se non viene indicato il filesystem verrà
- montato, o rimontanto nel caso lo si usi con \const{MS\_REMOUNT}, in
+ montato, o rimontato nel caso lo si usi con \const{MS\_REMOUNT}, in
lettura/scrittura; questo significa in sostanza che non esiste una opzione
separata per indicare il montaggio in lettura/scrittura.
\item[\constd{MS\_REC}] Applica ricorsivamente a tutti i \textit{mount point}
presenti al di sotto del \textit{mount point} indicato gli effetti della
- opzione degli \textit{shared subtree} associata. Anche questo caso
- l'argomento \param{target} deve fare riferimento ad un \textit{mount point}
- e tutti gli altri argomenti sono ignorati, ed il flag deve essere indicato o
- con \const{MS\_BIND} o assieme ad una fra \const{MS\_PRIVATE},
- \const{MS\_SHARED}, \const{MS\_SLAVE} e \const{MS\_UNBINDABLE}. Presente dal
- kernel 2.4.11.
-
- % TODO trattare l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
- % vedi http://lwn.net/Articles/621046/
+ opzione degli \textit{shared subtree} associata. In questo caso l'argomento
+ \param{target} deve fare riferimento ad un \textit{mount point} e tutti gli
+ altri argomenti sono ignorati, ed il flag deve essere indicato con uno fra
+ \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
+ \const{MS\_UNBINDABLE}. Può anche essere usato con \const{MS\_BIND} per
+ richiedere il montaggio ricorsivo anche degli eventuali ulteriori
+ \textit{bind mount} presenti sotto \param{target}.
\item[\constd{MS\_RELATIME}] Indica di effettuare l'aggiornamento
dell'\textit{access time} sul filesystem soltanto quando questo risulti
\end{basedescript}
+% NOTE: per l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
+% vedi http://lwn.net/Articles/621046/
+
% NOTE per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE} e
% \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees, in particolare
% * http://lwn.net/Articles/159077/ e
questo è un collegamento simbolico (vedi
sez.~\ref{sec:link_symlink_rename}). Questa è una misura di sicurezza
introdotta per evitare, per quei filesystem per il quale è prevista una
-gestione diretta da parte degli utenti, come quelli basati su
+gestione diretta da parte degli utenti, come quelli basati su \itindex{FUSE}
FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
di implementarne le funzioni in \textit{user space}, così da rendere
(il numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
sez.~\ref{sec:sys_limits}).
\item[\errcode{EPERM}] il filesystem che contiene \param{oldpath} e
- \param{newpath} non supporta i collegamenti diretti o è una directory.
+ \param{newpath} non supporta i collegamenti diretti, è una directory o non
+ si rispettano i criteri per i \textit{protected hardlink}.\footnotemark
\item[\errcode{EXDEV}] i file \param{oldpath} e \param{newpath} non fanno
riferimento ad un filesystem montato sullo stesso
\textit{mount point}.
generico.}
\end{funcproto}
+\footnotetext{i \textit{protected hardlink} sono una funzionalità di
+ protezione introdotta con il kernel 3.16 (vedi sez..}
+
La funzione crea in \param{newpath} un collegamento diretto al file indicato
da \param{oldpath}. Per quanto detto la creazione di un nuovo collegamento
diretto non copia il contenuto del file, ma si limita a creare la voce
specificata da \param{newpath} nella directory corrispondente e l'unica
proprietà del file che verrà modificata sarà il numero di riferimenti al file
(il campo \var{i\_nlink} della struttura \kstruct{inode}, vedi
-fig.~\ref{fig:kstruct_inode}) che verrà aumentato di di uno. In questo modo lo
+fig.~\ref{fig:kstruct_inode}) che verrà aumentato di uno. In questo modo lo
stesso file potrà essere acceduto sia con \param{newpath} che
con \param{oldpath}.
in quanto in caso di \textit{loop} la directory creata non sarebbe vuota e
non si potrebbe più rimuoverla.}
-Data la pericolosità di questa operazione e la disponibilità dei collegamenti
-simbolici (che vedremo a breve) e dei \textit{bind mount}
-(già visti in sez.~\ref{sec:filesystem_mounting}) che possono fornire la
-stessa funzionalità senza questi problemi, nel caso di Linux questa capacità è
-stata completamente disabilitata, e al tentativo di creare un collegamento
-diretto ad una directory la funzione \func{link} restituisce sempre l'errore
-\errcode{EPERM}.
+Data la pericolosità di questa operazione, e vista che i collegamenti
+simbolici (che tratteremo a breve) ed i \textit{bind mount} (già visti in
+sez.~\ref{sec:filesystem_mounting}) possono fornire la stessa funzionalità
+senza questi problemi, nel caso di Linux questa capacità è stata completamente
+disabilitata, e al tentativo di creare un collegamento diretto ad una
+directory la funzione \func{link} restituisce sempre l'errore \errcode{EPERM}.
Un ulteriore comportamento peculiare di Linux è quello in cui si crea un
\textit{hard link} ad un collegamento simbolico. In questo caso lo standard
-
-
\section{La manipolazione delle caratteristiche dei file}
\label{sec:file_infos}
la funzione \func{stat}, che permette l'accesso a tutti i dati memorizzati
nell'\textit{inode}; esamineremo poi le varie funzioni usate per manipolare
tutte queste informazioni, eccetto quelle che riguardano la gestione del
-controllo di accesso, trattate in in sez.~\ref{sec:file_access_control}.
+controllo di accesso, trattate in sez.~\ref{sec:file_access_control}.
\subsection{La lettura delle caratteristiche dei file}
contenuto della directory.
Questo significa che se si ha il permesso di esecuzione senza permesso di
-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
+lettura si potrà lo stesso aprire un file all'interno di 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.
\fdesc{Imposta la maschera dei permessi.}
}
-{La funzione ritorna ritorna il precedente valore della maschera, non sono
- previste condizioni di errore.}
+{La funzione ritorna il precedente valore della maschera, non sono previste
+ condizioni di errore.}
\end{funcproto}
La funzione imposta la maschera dei permessi dei bit al valore specificato
cui essi fanno riferimento. Questa scelta vale però soltanto per i file e le
directory ordinarie, se valesse in generale infatti si avrebbe un serio
problema di sicurezza dato che esistono diversi oggetti sul filesystem per i
- quali è normale avere avere il permesso di scrittura consentito a tutti gli
+ quali è normale avere il permesso di scrittura consentito a tutti gli
utenti, come i collegamenti simbolici, o alcuni file di dispositivo come
\texttt{/dev/null}. Se fosse possibile usare su di essi gli \textit{extended
user attributes} un utente qualunque potrebbe inserirvi dati a
{La funzione ritorna un oggetto di tipo \type{acl\_t} in caso di successo in
caso di successo e \val{NULL} per un errore, nel qual caso \var{errno}
- assumerà assumerà uno dei valori:
+ assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EINVAL}] l'argomento \param{acl} non è un puntatore valido
per una ACL.
indicata viene utilizzata come prefisso per le singole voci.
L'ultimo argomento, \param{options}, consente di controllare la modalità con
-cui viene generata la rappresentazione testuale. Un valore nullo fa si che
+cui viene generata la rappresentazione testuale. Un valore nullo fa sì che
vengano usati gli identificatori standard \texttt{user}, \texttt{group},
\texttt{other} e \texttt{mask} con i nomi di utenti e gruppi risolti rispetto
ai loro valori numerici. Altrimenti si può specificare un valore in forma di
% 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 FDCWD functions
-% LocalWords: faccessat grpid lacl AppArmor capsetp mygetfacl
+% LocalWords: faccessat grpid lacl AppArmor capsetp mygetfacl table Tb MSK
+% LocalWords: LAZYTIME submount peer
%%% Local Variables:
%%% mode: latex
scopo di queste dispense, per i dettagli si consulti la documentazione su
\textit{Yama} nei sorgenti del kernel. Introdotta a partire dal kernel 3.4.
-\itindbeg{secure~computing~mode}
-\item[\constd{PR\_SET\_SECCOMP}] Imposta il cosiddetto \textit{secure computing
- mode} per il processo corrente. Prevede come unica possibilità
- che \param{arg2} sia impostato ad 1. Una volta abilitato il \textit{secure
- computing mode} il processo potrà utilizzare soltanto un insieme
- estremamente limitato di \textit{system call}: \func{read}, \func{write},
- \func{\_exit} e \funcm{sigreturn}. Ogni altra \textit{system call} porterà
- all'emissione di un \signal{SIGKILL} (vedi sez.~\ref{sec:sig_termination}).
- Il \textit{secure computing mode} è stato ideato per fornire un supporto per
- l'esecuzione di codice esterno non fidato e non verificabile a scopo di
- calcolo;\footnote{lo scopo è quello di poter vendere la capacità di calcolo
- della proprio macchina ad un qualche servizio di calcolo distribuito senza
- comprometterne la sicurezza eseguendo codice non sotto il proprio
- controllo.} in genere i dati vengono letti o scritti grazie ad un socket o
- una \textit{pipe}, e per evitare problemi di sicurezza non sono possibili
- altre operazioni se non quelle citate. Introdotta a partire dal kernel
- 2.6.23, disponibile solo se si è abilitato il supporto nel kernel con
- \texttt{CONFIG\_SECCOMP}.
-
-% TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
-% terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
-% Documentation/prctl/seccomp_filter.txt
-% vedi anche http://lwn.net/Articles/600250/
-
-% TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
-% * Documentation/prctl/seccomp_filter.txt
-% * http://lwn.net/Articles/475043/
-
-% TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
-% vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
+\item[\constd{PR\_SET\_SECCOMP}] Attiva il \textit{secure computing mode} per
+ il processo corrente. Introdotta a partire dal kernel 2.6.23 la funzionalità
+ è stata ulteriorimente estesa con il kernel 3.5, salvo poi diventare un
+ sottoinsieme della \textit{system call} \func{seccomp} a partire dal kernel
+ 3.17. Prevede che si indichi per \param{arg2} il valore
+ \const{SECCOMP\_MODE\_STRICT} (unico possibile fino al kernel 2.6.23) per
+ selezionare il cosidetto \textit{strict mode} o, dal kernel 3.5,
+ \const{SECCOMP\_MODE\_FILTER} per usare il \textit{filter mode}. Tratteremo
+ questa opzione nei dettagli più avanti, in sez.~\ref{sec:procadv_seccomp},
+ quando affronteremo l'argomento del \textit{Secure Computing}.
\item[\constd{PR\_GET\_SECCOMP}] Ottiene come valore di ritorno della funzione
- lo stato corrente del \textit{secure computing mode}, al momento attuale la
- funzione è totalmente inutile in quanto l'unico valore ottenibile è 0, dato
- che la chiamata di questa funzione in \textit{secure computing mode}
- comporterebbe l'emissione di \signal{SIGKILL}, è stata comunque definita per
- eventuali estensioni future. Introdotta a partire dal kernel 2.6.23.
-\itindend{secure~computing~mode}
+ lo stato corrente del \textit{secure computing mode}. Fino al kernel 3.5,
+ quando era possibile solo lo \textit{strict mode}, la funzione era
+ totalmente inutile in quanto l'unico valore ottenibile era 0 in assenza di
+ \textit{secure computing}, dato che la chiamata di questa funzione in
+ \textit{strict mode} avrebbe comportato l'emissione di \signal{SIGKILL} per
+ il chiamante. La funzione però, a partire dal kernel 2.6.23, era stata
+ comunque definita per eventuali estensioni future, ed infatti con
+ l'introduzione del \textit{filter mode} con il kernel 3.5, se essa viene
+ inclusa nelle funzioni consentite restituisce il valore 2 quando il
+ \textit{secure computing mode} è attivo (se non inclusa si avrà di nuovo un
+ \signal{SIGKILL}).
\item[\constd{PR\_SET\_SECUREBITS}] Imposta i \textit{securebits} per il
processo chiamante al valore indicato da \param{arg2}; per i dettagli sul
generazione di un segnale di \signal{SIGSEGV} (vedi
sez.~\ref{sec:sig_prog_error}). La lettura viene automaticamente
disabilitata se si attiva il \textit{secure computing mode} (vedi
- \const{PR\_SET\_SECCOMP}). Introdotta a partire dal kernel
- 2.6.26, solo su x86.
+ \const{PR\_SET\_SECCOMP} e sez.~\ref{sec:procadv_seccomp}). Introdotta a
+ partire dal kernel 2.6.26, solo su x86.
\item[\constd{PR\_GET\_TSC}] Ottiene il valore del flag che controlla la
lettura del contattore dei \textit{timestamp}, salvato all'indirizzo
informazioni, che saranno così indipendenti per i due processi, come avviene
nel comportamento ordinario di un sistema unix-like.
-\item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo il nuovo
- processo condividerà con il padre il contesto dell'I/O, altrimenti, come
- come avviene nel comportamento ordinario con una \func{fork} otterrà un suo
- contesto dell'I/O.
+\item[\constd{CLONE\_IO}] se questo flag viene impostato il nuovo processo
+ condividerà con il padre il contesto dell'I/O, altrimenti, come avviene nel
+ comportamento ordinario con una \func{fork} otterrà un suo contesto
+ dell'I/O.
Il contesto dell'I/O viene usato dagli \textit{scheduler} di I/O (visti in
sez.~\ref{sec:io_priority}) e se questo è lo stesso per diversi processi
\label{sec:process_security}
Tratteremo in questa sezione le funzionalità più avanzate relative alla
-gestione della sicurezza, a partire dalle \textit{capabilities} e dalle
-funzionalità di \textit{Secure Computing}, fino alle funzionalità relative
-alla gestione delle chiavi crittografiche.
+gestione della sicurezza ed il controllo degli accessi all'interno dei
+processi, a partire dalle \textit{capabilities} e dalle funzionalità di
+\textit{Secure Computing}. Esamineremo inoltre tutte le altre funzionalità
+relative alla sicurezza come gestione delle chiavi crittografiche e varie
+estensioni e funzionalita disponibili su questo argomento.
Una seconda circostanza è quella relativa a cosa succede alle
\textit{capabilities} di un processo nelle possibili transizioni da \ids{UID}
nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a
-cedere o riottenere i i privilegi di amministratore) che si possono effettuare
+cedere o riottenere i privilegi di amministratore) che si possono effettuare
con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la
casistica è di nuovo alquanto complessa, considerata anche la presenza dei
diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si
% http://lwn.net/Articles/211883/
-Un elenco delle delle \textit{capabilities} disponibili su Linux, con una
-breve descrizione ed il nome delle costanti che le identificano, è riportato
-in tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa
- tabella, ripreso dalla pagina di manuale (accessibile con \texttt{man
- capabilities}) e dalle definizioni in
- \texttt{include/linux/capabilities.h}, è aggiornato al kernel 3.2.} la
-tabella è divisa in due parti, la prima riporta le \textit{capabilities}
-previste anche nella bozza dello standard POSIX1.e, la seconda quelle
-specifiche di Linux. Come si può notare dalla tabella alcune
+Un elenco delle \textit{capabilities} disponibili su Linux, con una breve
+descrizione ed il nome delle costanti che le identificano, è riportato in
+tab.~\ref{tab:proc_capabilities};\footnote{l'elenco presentato questa tabella,
+ ripreso dalla pagina di manuale (accessibile con \texttt{man capabilities})
+ e dalle definizioni in \texttt{include/linux/capabilities.h}, è aggiornato
+ al kernel 3.2.} la tabella è divisa in due parti, la prima riporta le
+\textit{capabilities} previste anche nella bozza dello standard POSIX1.e, la
+seconda quelle specifiche di Linux. Come si può notare dalla tabella alcune
\textit{capabilities} attengono a singole funzionalità e sono molto
specializzate, mentre altre hanno un campo di applicazione molto vasto, che è
opportuno dettagliare maggiormente.
+\subsection{La gestione del \textit{Secure Computing}.}
+\label{sec:procadv_seccomp}
+
+\itindbeg{secure~computing~mode}
+
+Il \textit{secure computing mode} è un meccanismo ideato per fornire un
+supporto per l'esecuzione di codice esterno non fidato e non verificabile a
+scopo di calcolo. L'idea era quello di poter vendere la capacità di calcolo
+della propria macchina ad un qualche servizio di calcolo distribuito, senza
+comprometterne la sicurezza eseguendo codice non sotto il proprio controllo.
+
+Nella prima versione del meccanismo, introdotto con il kernel 2.6.23 e
+disponibile solo avendo è abilitato il supporto nel kernel con
+\texttt{CONFIG\_SECCOMP}, questo veniva attovato con \func{prctl} indicando
+l'opzione \const{PR\_SET\_SECCOMP}, che all'epoca supportava soltanto l'uso
+del valore \const{SECCOMP\_MODE\_STRICT} per \param{arg2}.
+
+Una volta abilitato il \textit{secure computing mode} in questa modalità (in
+seguito denominata \textit{strict mode}) il processo o il \textit{thread}
+chiamante potrà utilizzare soltanto un insieme estremamente limitato di
+\textit{system call}: \func{read}, \func{write}, \func{\_exit} e
+\funcm{sigreturn}. Ogni altra \textit{system call} porterà all'emissione di un
+\signal{SIGKILL} (vedi sez.~\ref{sec:sig_termination}). In questa modalità di
+utilizzo i dati vengono letti o scritti grazie ad un socket o una
+\textit{pipe}, creati prima di lanciare il processo che eseguirà il codice non
+fidato, e per evitare problemi di sicurezza non saranno possibili altre
+operazioni se non quelle citate.
+
+
+% TODO a partire dal kernel 3.5 è stato introdotto la possibilità di usare un
+% terzo argomento se il secondo è SECCOMP_MODE_FILTER, vedi
+% Documentation/prctl/seccomp_filter.txt
+% vedi anche http://lwn.net/Articles/600250/
+
+% TODO documentare PR_SET_SECCOMP introdotto a partire dal kernel 3.5. Vedi:
+% * Documentation/prctl/seccomp_filter.txt
+% * http://lwn.net/Articles/475043/
+
+% TODO a partire dal kernel 3.17 è stata introdotta la nuova syscall seccomp,
+% vedi http://lwn.net/Articles/600250/ e http://lwn.net/Articles/603321/
+
+
+\itindend{secure~computing~mode}
+
+\subsection{Altre funzionalità di sicurezza.}
+\label{sec:procadv_security_misc}
+
+Oltre alle funzionalità specifiche esaminite nelle sezioni precedenti, il
+kernel supporta una varietà di ulteriori impostazioni di sicurezza,
+accessibili nelle maniere più varie, che abbiamo raccolto in questa sezione.
+
+Una serie di modalità di sicurezza sono attivabili a richiesta attraverso
+alcune opzioni di controllo attivabili via \func{sysctl} o il filesystem
+\texttt{/proc}, un elenco delle stesse e dei loro effetti è il seguente:
+
+\begin{basedescript}{\desclabelwidth{2.2cm}\desclabelstyle{\nextlinelabel}}
+\item[\sysctlrelfiled{fs}{protected\_hardlinks}] Un valore nullo, il default,
+ mantiene il comportamento standard che non pone restrizioni alla creazione
+ di \textit{hard link}. Se il valore viene posto ad 1 vengono invece attivate
+ una serie di restrizioni, che se non soddisfatte causano il fallimento di
+ \func{link} con un errore di \errval{EPERM}. Perché questo non avvenga
+ almeno una delle seguenti condizioni deve essere soddisfatta:
+ \begin{itemize*}
+ \item il processo chiamante deve avere i privilegi amministrativi (la
+ \textit{capability}) \const{CAP\_FOWNER}); in caso di utilizzo
+ dell'\textit{user namespace} oltre a possedere \const{CAP\_FOWNER} è
+ necessario che l'\ids{UID} del proprietario del file sia mappato nel
+ \textit{namespace}.
+ \item il \textit{filesystem} \ids{UID} del chiamante (normalmente
+ equivalente all'\ids{UID} effettivo) deve corrispondere a quello del
+ proprietario del file a cui si vuole effettuare il collegamento.
+ \item sono soddistatte tutte le seguenti condizioni:
+ \begin{itemize*}
+ \item il file è un file ordinario
+ \item il file non ha il \acr{suid} bit attivo
+ \item il file non ha lo \acr{sgid} bit attivo ed il permesso di esecuzione
+ per il gruppo
+ \item il chiamante ha i permessi di lettura e scrittura sul file
+ \end{itemize*}
+ \end{itemize*}
+\end{basedescript}
+
% TODO: trattare keyctl (man 2 keyctl)
+
+
% TODO trattare le funzioni di protezione della memoria pkey_alloc, pkey_free,
% pkey_mprotect, introdotte con il kernel 4.8, vedi
% http://lwn.net/Articles/689395/ e Documentation/x86/protection-keys.txt
projects / gapil.git / commitdiff