una fra \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
\const{MS\_UNBINDABLE}.
+ % TODO trattare l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
+ % vedi http://lwn.net/Articles/621046/
+
\item[\const{MS\_RELATIME}] Indica di effettuare l'aggiornamento degli
\textit{access time} sul filesystem soltanto quando questo risulti
antecedente il valore corrente del \textit{modification time} o del
\var{st\_size} non è detto che corrisponda all'occupazione dello spazio su
disco, e non solo perché la parte finale del file potrebbe riempire
parzialmente un blocco. In un sistema unix-like infatti è possibile
-l'esistenza dei cosiddetti \itindex{sparse~file} \textit{sparse file}, cioè
-file in cui sono presenti dei ``\textsl{buchi}'' \index{file!\textit{hole}}
-(\textit{holes} nella nomenclatura inglese) che si formano tutte le volte che
-si va a scrivere su un file dopo aver eseguito uno spostamento oltre la sua
-fine (tratteremo in dettaglio l'argomento in sez.~\ref{sec:file_lseek}).
+l'esistenza dei cosiddetti \textit{sparse file}, cioè file in cui sono
+presenti dei ``\textsl{buchi}'' (\textit{holes} nella nomenclatura inglese)
+che si formano tutte le volte che si va a scrivere su un file dopo aver
+eseguito uno spostamento oltre la sua fine (tratteremo in dettaglio
+l'argomento in sez.~\ref{sec:file_lseek}).
In questo caso si avranno risultati differenti a seconda del modo in cui si
calcola la lunghezza del file, ad esempio il comando \cmd{du}, (che riporta il
numero di blocchi occupati) potrà dare una dimensione inferiore, mentre se si
legge dal file (ad esempio usando il comando \cmd{wc -c}), dato che in tal
-caso per i ``\textsl{buchi}'' \index{file!\textit{hole}} vengono restituiti
-degli zeri, si avrà lo stesso risultato di \cmd{ls}.
+caso per i ``\textsl{buchi}'' vengono restituiti degli zeri, si avrà lo stesso
+risultato di \cmd{ls}.
Se è sempre possibile allargare un file, scrivendoci sopra o usando la
funzione \func{lseek} (vedi sez.~\ref{sec:file_lseek}) per spostarsi oltre la
Il comportamento in caso di lunghezza del file inferiore a \param{length} non
è specificato e dipende dall'implementazione: il file può essere lasciato
invariato o esteso fino alla lunghezza scelta. Nel caso di Linux viene esteso
-con la creazione di un \index{file!\textit{hole}} \textsl{buco} nel
-\itindex{sparse~file} file e ad una lettura si otterranno degli zeri, si tenga
-presente però che questo comportamento è supportato solo per filesystem
-nativi, ad esempio su un filesystem non nativo come il VFAT di Windows questo
-non è possibile.
+con la creazione di un \textsl{buco} nel file e ad una lettura si otterranno
+degli zeri, si tenga presente però che questo comportamento è supportato solo
+per filesystem nativi, ad esempio su un filesystem non nativo come il VFAT di
+Windows questo non è possibile.
\subsection{I tempi dei file}
campi della struttura \struct{stat} è illustrato nello schema di
tab.~\ref{tab:file_file_times}, dove è anche riportato un esempio delle
funzioni che effettuano cambiamenti su di essi. Il valore del tempo è espresso
-nel cosiddetto \itindex{calendar~time} \textit{calendar time}, su cui
-torneremo in dettaglio in sez.~\ref{sec:sys_time}.
+nel cosiddetto \textit{calendar time}, su cui torneremo in dettaglio in
+sez.~\ref{sec:sys_time}.
\begin{table}[htb]
\centering
rivoluzionato, rendendolo più aderente alle intenzioni originali dello
standard POSIX, rimuovendo il significato che fino ad allora aveva avuto la
capacità \const{CAP\_SETPCAP} e cambiando le modalità di funzionamento del
-cosiddetto \itindex{capabilities~bounding~set} \textit{capabilities bounding
- set}. Ulteriori modifiche sono state apportate con il kernel 2.6.26 per
-consentire la rimozione non ripristinabile dei privilegi di
-amministratore. Questo fa sì che il significato ed il comportamento del kernel
-finisca per dipendere dalla versione dello stesso e dal fatto che le nuove
-\textit{file capabilities} siano abilitate o meno. Per capire meglio la
-situazione e cosa è cambiato conviene allora spiegare con maggiori dettagli
-come funziona il meccanismo delle \textit{capabilities}.
+cosiddetto \textit{capabilities bounding set}. Ulteriori modifiche sono state
+apportate con il kernel 2.6.26 per consentire la rimozione non ripristinabile
+dei privilegi di amministratore. Questo fa sì che il significato ed il
+comportamento del kernel finisca per dipendere dalla versione dello stesso e
+dal fatto che le nuove \textit{file capabilities} siano abilitate o meno. Per
+capire meglio la situazione e cosa è cambiato conviene allora spiegare con
+maggiori dettagli come funziona il meccanismo delle \textit{capabilities}.
Il primo passo per frazionare i privilegi garantiti all'amministratore,
supportato fin dalla introduzione iniziale del kernel 2.2, è stato quello in
% informazioni su setns qui: http://lwn.net/Articles/532748/
% http://lwn.net/Articles/531498/
-
% TODO: spostare chroot e le funzioni affini relative ai container da qualche
% parte diversa se è il caso.
+% TODO Inheriting capabilities vedi http://lwn.net/Articles/632520/ eambient
+% capabilities introdotte con il kernel 4.3, vedi
+% http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08
Benché non abbia niente a che fare con permessi, utenti e gruppi, la funzione
\func{chroot} viene usata spesso per restringere le capacità di accesso di un
projects / gapil.git / blobdiff