%% filedir.tex
%%
-%% Copyright (C) 2000-2012 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2015 Simone Piccardi. Permission is granted to
%% copy, distribute and/or modify this document under the terms of the GNU Free
%% Documentation License, Version 1.1 or any later version published by the
%% Free Software Foundation; with the Invariant Sections being "Un preambolo",
\errval{ENOENT}, \errval{ENOMEM} nel loro significato generico. }
\end{funcproto}
-\footnotetext{più precisamente la \itindex{capabilities} capacità
- \const{CAP\_SYS\_ADMIN}, vedi sez.~\ref{sec:proc_capabilities}.}
+\footnotetext{più precisamente la capacità \const{CAP\_SYS\_ADMIN}, vedi
+ sez.~\ref{sec:proc_capabilities}.}
La funzione prende il nome della directory su cui il filesystem è montato e
non il file o il dispositivo che è stato montato,\footnote{questo è vero a
collegamento simbolico può fare riferimento anche ad un file che non esiste;
ad esempio possiamo usare il comando \cmd{ln} per creare un collegamento
simbolico nella nostra directory con:
-\begin{Command}
-$ ln -s /tmp/tmp_file symlink
-\end{Command}
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ln -s /tmp/tmp_file symlink}
+\end{Console}
%$
e questo avrà successo anche se \file{/tmp/tmp\_file} non esiste:
-\begin{Command}
-$ ls symlink
-\end{Command}
-\begin{Terminal}
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ls symlink}
symlink
-\end{Terminal}
+\end{Console}
%$
ma questo può generare confusione, perché accedendo in sola lettura a
\file{symlink}, ad esempio con \cmd{cat}, otterremmo un errore:
-\begin{Command}
-$ cat symlink
-\end{Command}
-\begin{Terminal}
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{cat symlink}
cat: symlink: No such file or directory
-\end{Terminal}
+\end{Console}
%$
con un errore che può sembrare sbagliato, dato che \cmd{ls} ci ha mostrato
l'esistenza di \file{symlink}, se invece scrivessimo su \file{symlink}
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 \itindex{close-on-exec} \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.
+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
utilizzato all'interno del proprio programma. In particolare dovrà essere
chiuso attraverso il \textit{directory stream} con \func{closedir} e non
direttamente. Si tenga presente inoltre che \func{fdopendir} non modifica lo
-stato di un eventuale flag di \itindex{close-on-exec} \textit{close-on-exec},
-che pertanto dovrà essere impostato esplicitamente in fase di apertura del
-file descriptor.
+stato di un eventuale flag di \textit{close-on-exec}, che pertanto dovrà
+essere impostato esplicitamente in fase di apertura del file descriptor.
Una volta che si sia aperto un \textit{directory stream} la lettura del
contenuto della directory viene effettuata attraverso la funzione
trovato coi sorgenti allegati alla guida nel file \file{myls.c}.
In sostanza tutto quello che fa il programma, dopo aver controllato
-(\texttt{\small 12--15}) di avere almeno un argomento, che indicherà la
+(\texttt{\small 12-15}) di avere almeno un argomento, che indicherà la
directory da esaminare, è chiamare (\texttt{\small 16}) la funzione
\myfunc{dir\_scan} per eseguire la scansione, usando la funzione \code{do\_ls}
-(\texttt{\small 22--29}) per fare tutto il lavoro.
+(\texttt{\small 22-29}) per fare tutto il lavoro.
Quest'ultima si limita (\texttt{\small 26}) a chiamare \func{stat} sul file
indicato dalla directory entry passata come argomento (il cui nome è appunto
riportata in fig.~\ref{fig:file_dirscan}. La funzione è volutamente generica e
permette di eseguire una funzione, passata come secondo argomento, su tutte le
voci di una directory. La funzione inizia con l'aprire (\texttt{\small
- 18--22}) uno \textit{stream} sulla directory passata come primo argomento,
+ 18-22}) uno \textit{stream} sulla directory passata come primo argomento,
stampando un messaggio in caso di errore.
-Il passo successivo (\texttt{\small 23--24}) è cambiare
+Il passo successivo (\texttt{\small 23-24}) è cambiare
\index{directory~di~lavoro} directory di lavoro (vedi
sez.~\ref{sec:file_work_dir}), usando in sequenza le funzioni \func{dirfd} e
\func{fchdir} (in realtà si sarebbe potuto usare direttamente \func{chdir} su
\var{dirname}), in modo che durante il successivo ciclo (\texttt{\small
- 26--30}) sulle singole voci dello \textit{stream} ci si trovi all'interno
+ 26-30}) sulle singole voci dello \textit{stream} ci si trovi all'interno
della directory.\footnote{questo è essenziale al funzionamento della funzione
\code{do\_ls}, e ad ogni funzione che debba usare il campo \var{d\_name}, in
quanto i nomi dei file memorizzati all'interno di una struttura
o \const{S\_IFBLK} o \const{S\_IFCHR}), il valore di \param{dev} dovrà essere
usato per indicare a quale dispositivo si fa riferimento, altrimenti il suo
valore verrà ignorato. Solo l'amministratore può creare un file di
-dispositivo usando questa funzione (il processo deve avere la
-\itindex{capabilities} \textit{capability} \const{CAP\_MKNOD}), ma in
-Linux\footnote{questo è un comportamento specifico di Linux, la funzione non è
- prevista dallo standard POSIX.1 originale, mentre è presente in SVr4 e
- 4.4BSD, ma esistono differenze nei comportamenti e nei codici di errore,
- tanto che questa è stata introdotta in POSIX.1-2001 con una nota che la
- definisce portabile solo quando viene usata per creare delle fifo, ma
- comunque deprecata essendo utilizzabile a tale scopo la specifica
- \func{mkfifo}.} l'uso per la creazione di un file ordinario, di una fifo o
-di un socket è consentito anche agli utenti normali.
+dispositivo usando questa funzione (il processo deve avere la capacità
+\const{CAP\_MKNOD}), ma in Linux\footnote{questo è un comportamento specifico
+ di Linux, la funzione non è prevista dallo standard POSIX.1 originale,
+ mentre è presente in SVr4 e 4.4BSD, ma esistono differenze nei comportamenti
+ e nei codici di errore, tanto che questa è stata introdotta in POSIX.1-2001
+ con una nota che la definisce portabile solo quando viene usata per creare
+ delle fifo, ma comunque deprecata essendo utilizzabile a tale scopo la
+ specifica \func{mkfifo}.} l'uso per la creazione di un file ordinario, di
+una fifo o di un socket è consentito anche agli utenti normali.
I nuovi \itindex{inode} \textit{inode} creati con \func{mknod} apparterranno
al proprietario e al gruppo del processo (usando \ids{UID} e \ids{GID} del
proprietari del file o avere i privilegi di amministratore. Se invece si è
specificato un valore diverso la funzione avrà successo solo se si è
proprietari del file o se si hanno i privilegi di amministratore.\footnote{per
- essere precisi la \itindex{capabilities} capacità \const{CAP\_FOWNER}, vedi
+ essere precisi la capacità \const{CAP\_FOWNER}, vedi
sez.~\ref{sec:proc_capabilities}.} In entrambi i casi per verificare la
proprietà del file viene utilizzato l'\ids{UID} effettivo del processo.
Il controllo di accesso ai file segue un modello abbastanza semplice che
prevede tre permessi fondamentali strutturati su tre livelli di accesso.
-Esistono varie estensioni a questo modello,\footnote{come le
- \itindex{Access~Control~List~(ACL)} \textit{Access Control List} che sono
- state aggiunte ai filesystem standard con opportune estensioni (vedi
- sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di controllo ancora più
- sofisticati come il \itindex{Mandatory~Access~Control~(MAC)}
- \textit{mandatory access control} di SE-Linux e delle altre estensioni come
- \textit{Smack} o \textit{AppArmor}.} ma nella maggior parte dei casi il
-meccanismo standard è più che sufficiente a soddisfare tutte le necessità più
-comuni. I tre permessi di base associati ad ogni file sono:
+Esistono varie estensioni a questo modello,\footnote{come le \textit{Access
+ Control List} che sono state aggiunte ai filesystem standard con opportune
+ estensioni (vedi sez.~\ref{sec:file_ACL}) per arrivare a meccanismi di
+ controllo ancora più sofisticati come il \textit{Mandatory Access Control}
+ di \textit{SELinux} e delle altre estensioni come \textit{Smack} o
+ \textit{AppArmor}.} ma nella maggior parte dei casi il meccanismo standard è
+più che sufficiente a soddisfare tutte le necessità più comuni. I tre
+permessi di base associati ad ogni file sono:
\begin{itemize*}
\item il permesso di lettura (indicato con la lettera \texttt{r}, dall'inglese
\textit{read}).
per cui a differenza dei permessi ordinari esse varranno per qualunque utente
compreso l'amministratore. L'amministratore è l'unico che può attivare o
disattivare questi attributi,\footnote{più precisamente un processo con la
- \itindex{capabilities} capacità \const{CAP\_LINUX\_IMMUTABLE}, vedi
+ capacità \const{CAP\_LINUX\_IMMUTABLE}, vedi
sez.~\ref{sec:proc_capabilities}.} e potendo rimuoverli è comunque capace di
tornare in grado di eseguire qualunque operazione su un file immutabile o
\textit{append-only}.
Un classico esempio di directory che ha questo bit impostato è \file{/tmp}, i
cui permessi infatti di solito sono i seguenti:
-\begin{Command}
-$ ls -ld /tmp
-\end{Command}
-\begin{Terminal}
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{ls -ld /tmp}
drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
-\end{Terminal}
+\end{Console}
%$
quindi con lo \textit{sticky bit} bit impostato. In questo modo qualunque
utente nel sistema può creare dei file in questa directory, che come
\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 \itindex{capabilities} capacità \const{CAP\_FSETID}, vedi
- sez.~\ref{sec:proc_capabilities}.} effettui una scrittura. In questo modo
-anche se un utente malizioso scopre un file \acr{suid} su cui può scrivere,
-un'eventuale modifica comporterà la perdita di questo privilegio.
+ della capacità \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.}
+effettui una scrittura. In questo modo anche se un utente malizioso scopre un
+file \acr{suid} su cui può scrivere, un'eventuale modifica comporterà la
+perdita di questo privilegio.
Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
permessi di un file, resta però il problema di quali sono i permessi assegnati
Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
specificati dalle variabili \param{owner} e \param{group}. Con Linux solo
-l'amministratore\footnote{o in generale un processo con la
- \itindex{capabilities} capacità \const{CAP\_CHOWN}, vedi
- sez.~\ref{sec:proc_capabilities}.} può cambiare il proprietario di un file;
-in questo viene seguita la semantica usata da BSD che non consente agli utenti
-di assegnare i loro file ad altri utenti evitando eventuali aggiramenti delle
-quote. L'amministratore può cambiare sempre il gruppo di un file, il
-proprietario può cambiare il gruppo solo dei file che gli appartengono e solo
-se il nuovo gruppo è il suo gruppo primario o uno dei gruppi di cui fa parte.
+l'amministratore\footnote{o in generale un processo con la capacità
+ \const{CAP\_CHOWN}, vedi sez.~\ref{sec:proc_capabilities}.} può cambiare il
+proprietario di un file; in questo viene seguita la semantica usata da BSD che
+non consente agli utenti di assegnare i loro file ad altri utenti evitando
+eventuali aggiramenti delle quote. L'amministratore può cambiare sempre il
+gruppo di un file, il proprietario può cambiare il gruppo solo dei file che
+gli appartengono e solo se il nuovo gruppo è il suo gruppo primario o uno dei
+gruppi di cui fa parte.
La funzione \func{chown} segue i collegamenti simbolici, per operare
direttamente su un collegamento simbolico si deve usare la funzione
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 \itindex{file~capabilities}
- \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.
+ 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.
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
\hline
\texttt{security}&Gli \textit{extended security attributes}: vengono
utilizzati dalle estensioni di sicurezza del kernel (i
- \itindex{Linux~Security~Modules} \textit{Linux
- Security Modules}), per le realizzazione di meccanismi
- evoluti di controllo di accesso come \index{SELinux}
- SELinux o le \textit{capabilities} dei file di
- sez.~\ref{sec:proc_capabilities}.\\
+ \textit{Linux Security Modules}), per le realizzazione
+ 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
dal kernel per memorizzare dati di sistema associati ai
- file come le \itindex{Access~Control~List~(ACL)} ACL (vedi
- sez.~\ref{sec:file_ACL}) o le \itindex{capabilities}
+ 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
Dato che uno degli usi degli \textit{Extended Attributes} è di impiegarli per
-realizzare delle estensioni (come le \itindex{Access~Control~List~(ACL)} ACL,
-\index{SELinux} SELinux, ecc.) al tradizionale meccanismo dei controlli di
-accesso di Unix, 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 tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti
-casi:
+realizzare delle estensioni (come le ACL, \textit{SELinux}, ecc.) al
+tradizionale meccanismo dei controlli di accesso di Unix, 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
+tab.~\ref{tab:extended_attribute_class}, si hanno i seguenti casi:
\begin{basedescript}{\desclabelwidth{1.7cm}\desclabelstyle{\nextlinelabel}}
\item[\texttt{security}] L'accesso agli \textit{extended security attributes}
dipende dalle politiche di sicurezza stabilite da loro stessi tramite
- l'utilizzo di un sistema di controllo basato sui
- \itindex{Linux~Security~Modules} \textit{Linux Security Modules} (ad esempio
- \index{SELinux} SELinux). Pertanto l'accesso in lettura o scrittura dipende
- dalle politiche di sicurezza implementate all'interno dal 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 \itindex{capabilities}
- \textit{capability} \const{CAP\_SYS\_ADMIN}.
+ l'utilizzo di un sistema di controllo basato sui \textit{Linux Security
+ Modules} (ad esempio \textit{SELinux}). Pertanto l'accesso in lettura o
+ scrittura dipende dalle politiche di sicurezza implementate all'interno dal
+ 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}.
\item[\texttt{system}] Anche l'accesso agli \textit{extended system
attributes} dipende dalle politiche di accesso che il kernel realizza
anche utilizzando gli stessi valori in essi contenuti. Ad esempio nel caso
- delle \itindex{Access~Control~List~(ACL)} ACL l'accesso è consentito in
- lettura 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
- \textit{capability} \itindex{capabilities}
+ delle ACL (vedi sez.~\ref{sec:file_ACL}) l'accesso è consentito in lettura
+ 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.}
\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 \itindex{capabilities}
- \textit{capability} \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.
+ 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.
\item[\texttt{user}] L'accesso agli \textit{extended user attributes} è
regolato dai normali permessi dei file: occorre avere il permesso di lettura
per evitare eventuali abusi, se una directory ha lo \itindex{sticky~bit}
\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à \itindex{capabilities}
- \const{CAP\_FOWNER}.
+ privilegi amministrativi della capacità \const{CAP\_FOWNER}.
\end{basedescript}
Le funzioni per la gestione degli attributi estesi, come altre funzioni di
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à \itindex{capabilities} \const{CAP\_FOWNER}.
+la capacità \const{CAP\_FOWNER}.
\begin{table}[htb]
\centering
\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 \itindex{capabilities} capacità
- \const{CAP\_DAC\_OVERRIDE} per i file e \const{CAP\_DAC\_READ\_SEARCH} per
- le directory, vedi sez.~\ref{sec:proc_capabilities}.}
+ precisamente se si devono avere le capacità \const{CAP\_DAC\_OVERRIDE} per
+ i file e \const{CAP\_DAC\_READ\_SEARCH} per le directory, vedi
+ sez.~\ref{sec:proc_capabilities}.}
\item Se l'\ids{UID} del processo corrisponde al proprietario del file allora:
\begin{itemize*}
\item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
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
+programma richiede un unico argomento (\texttt{\small 16-20}) che indica il
file di cui si vuole leggere la ACL. Se questo è presente si usa
(\texttt{\small 22}) la funzione \func{get\_acl\_file} per leggerne la ACL, e
-si controlla (\texttt{\small 23--26}) se l'operazione ha successo, uscendo con
+si controlla (\texttt{\small 23-26}) se l'operazione ha successo, uscendo con
un messaggio di errore in caso contrario.
Ottenuta la ACL la si converte in formato testuale (\texttt{\small 27}) con la
funzione \func{acl\_to\_text}, controllando di nuovo se l'operazione ha
-successo (\texttt{\small 28--31}) ed uscendo in caso contrario. Si provvede
+successo (\texttt{\small 28-31}) ed uscendo in caso contrario. Si provvede
infine a stampare la rappresentazione testuale (\texttt{\small 32}) e dopo
-aver liberato (\texttt{\small 33--34}) le risorse allocate automaticamente, si
+aver liberato (\texttt{\small 33-34}) le risorse allocate automaticamente, si
conclude l'esecuzione.
operazioni di attivazione, disattivazione e di modifica dei limiti delle quote
sono riservate e richiedono i privilegi di amministratore.\footnote{per essere
precisi tutte le operazioni indicate come privilegiate in
- tab.~\ref{tab:quotactl_commands} richiedono la \textit{capability}
+ tab.~\ref{tab:quotactl_commands} richiedono la capacità
\const{CAP\_SYS\_ADMIN}.} Inoltre gli utenti possono soltanto richiedere i
dati relativi alle proprie quote, solo l'amministratore può ottenere i dati di
tutti.
con \macro{QCMD} al comando \const{Q\_GETQUOTA} per ottenere i dati.
La funzione viene eseguita all'interno di un condizionale (\texttt{\small
- 5--16}) che in caso di successo provvede a costruire (\texttt{\small 6--12})
+ 5-16}) che in caso di successo provvede a costruire (\texttt{\small 6-12})
opportunamente una risposta restituendo tramite la opportuna funzione di
interfaccia un oggetto Python contenente i dati della struttura \struct{dqblk}
relativi a uso corrente e limiti sia per i blocchi che per gli \itindex{inode}
-\textit{inode}. In caso di errore (\texttt{\small 13--15}) si usa un'altra
+\textit{inode}. In caso di errore (\texttt{\small 13-15}) si usa un'altra
funzione dell'interfaccia per passare il valore di \var{errno} come eccezione.
\begin{figure}[!htbp]
della precedente, con lo stesso significato, a cui si aggiungono i valori per
il \textit{soft limit} e l'\textit{hard limit}. In questo caso occorrerà,
prima di chiamare \func{quotactl}, inizializzare opportunamente
-(\texttt{\small 5--7}) i campi della struttura \struct{dqblk} che si vogliono
+(\texttt{\small 5-7}) i campi della struttura \struct{dqblk} che si vogliono
utilizzare (quelli relativi ai limiti sui blocchi) e specificare gli stessi
con \const{QIF\_BLIMITS} in \var{dq.dqb\_valid}.
Fatto questo la chiamata a \func{quotactl}, stavolta con il comando
\const{Q\_SETQUOTA}, viene eseguita come in precedenza all'interno di un
-condizionale (\texttt{\small 9--14}). In questo caso non essendovi da
+condizionale (\texttt{\small 9-14}). In questo caso non essendovi da
restituire nessun dato in caso di successo si usa (\texttt{\small 10}) una
apposita funzione di uscita, mentre si restituisce come prima una eccezione
-con il valore di \var{errno} in caso di errore (\texttt{\small 12--13}).
+con il valore di \var{errno} in caso di errore (\texttt{\small 12-13}).
\subsection{La gestione delle \textit{capabilities}}
gestione dei privilegi in un sistema unix-like ha il sostanziale problema di
fornire all'amministratore dei poteri troppo ampi. Questo comporta che anche
quando si siano predisposte delle misure di protezione per in essere in grado
-di difendersi dagli effetti di una eventuale compromissione del
-sistema,\footnote{come montare un filesystem in sola lettura per impedirne
- modifiche, o marcare un file come immutabile.} una volta che questa sia
-stata effettuata e si siano ottenuti i privilegi di amministratore, queste
-misure potranno essere comunque rimosse.\footnote{nei casi elencati nella
- precedente nota si potrà sempre rimontare il sistema in lettura-scrittura, o
- togliere l'attributo di immutabilità.}
+di difendersi dagli effetti di una eventuale compromissione del sistema (come
+montare un filesystem in sola lettura per impedirne modifiche, o marcare un
+file come immutabile) una volta che questa sia stata effettuata e si siano
+ottenuti i privilegi di amministratore, queste misure potranno essere comunque
+rimosse (nei casi elencati nella precedente nota si potrà sempre rimontare il
+sistema in lettura-scrittura, o togliere l'attributo di immutabilità).
Il problema consiste nel fatto che nell'architettura tradizionale di un
sistema unix-like i controlli di accesso sono basati su un solo livello di
processi con i privilegi di amministratore essi non vengono neppure eseguiti.
Per questo motivo non era previsto alcun modo per evitare che un processo con
diritti di amministratore non potesse eseguire certe operazioni, o per cedere
-definitivamente alcuni privilegi da un certo momento in poi.
-
-Per ovviare a tutto ciò, a partire dai kernel della serie 2.2, è stato
+definitivamente alcuni privilegi da un certo momento in poi.
+
+Per risolvere questo problema sono possibili varie soluzioni ed ad esempio dai
+kernel 2.5 è stata introdotta la struttura dei
+\itindex{Linux~Security~Modules} \textit{Linux Security Modules} che han
+permesso di aggiungere varie forme di \itindex{Mandatory~Access~Control~(DAC)}
+\textit{Mandatory Access Control} (MAC), in cui si potessero parcellizzare e
+controllare nei minimi dettagli tutti i privilegi e le modalità in cui questi
+possono essere usati dai programmi e trasferiti agli utenti, con la creazione
+di varie estensioni (come \textit{SELinux}, \textit{Smack}, \textit{Tomoyo},
+\textit{AppArmor}) che consentono di superare l'architettura tradizionale dei
+permessi basati sul modello classico del controllo di accesso chiamato
+\itindex{Discrectionary~Access~Control~(DAC)} \textit{Discrectionary Access
+ Control} (DAC).
+
+Ma già in precedenza, a partire dai kernel della serie 2.2, era stato
introdotto un meccanismo, detto \textit{capabilities}, che consentisse di
suddividere i vari privilegi tradizionalmente associati all'amministratore in
un insieme di \textsl{capacità} distinte. L'idea era che queste capacità
\itindbeg{file~capabilities}
-Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
- si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
- poi abbandonato.} prevede inoltre la possibilità di associare le stesse ai
-singoli file eseguibili, in modo da poter stabilire quali capacità possono
-essere utilizzate quando viene messo in esecuzione uno specifico programma; ma
-il supporto per questa funzionalità, chiamata \textit{file capabilities}, è
-stato introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva
-essere il programma stesso ad eseguire una riduzione esplicita delle sue
-capacità, cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la
-presenza di meccanismi alternativi per ottenere limitazioni delle capacità
-dell'amministratore a livello di sistema operativo, come \index{SELinux}
-SELinux.
+Il meccanismo completo delle \textit{capabilities} (l'implementazione si rifà
+ad una bozza di quello che doveva diventare lo standard POSIX.1e, poi
+abbandonato) prevede inoltre la possibilità di associare le stesse ai singoli
+file eseguibili, in modo da poter stabilire quali capacità possono essere
+utilizzate quando viene messo in esecuzione uno specifico programma; ma il
+supporto per questa funzionalità, chiamata \textit{file capabilities}, è stato
+introdotto soltanto a partire dal kernel 2.6.24. Fino ad allora doveva essere
+il programma stesso ad eseguire una riduzione esplicita delle sue capacità,
+cosa che ha reso l'uso di questa funzionalità poco diffuso, vista la presenza
+di meccanismi alternativi per ottenere limitazioni delle capacità
+dell'amministratore a livello di sistema operativo, come \textit{SELinux}.
Con questo supporto e con le ulteriori modifiche introdotte con il kernel
2.6.25 il meccanismo delle \textit{capabilities} è stato totalmente
\itindend{file~capabilities}
-% TODO verificare per process capability bounding set, vedi:
-% http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
+% NOTE per dati relativi al process capability bounding set, vedi:
+% http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
-% TODO capire cosa cambia con i patch vari, vedi
+% NOTE riferimenti ai vari cambiamenti vedi:
% http://lwn.net/Articles/280279/
% http://lwn.net/Articles/256519/
% http://lwn.net/Articles/211883/
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 2.6.26.} la
+ \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
\const{CAP\_AUDIT\_WRITE}&Scrivere dati nel giornale di
auditing del kernel (dal kernel 2.6.11).\\
% TODO verificare questa roba dell'auditing
+ \const{CAP\_BLOCK\_SUSPEND}&Utilizzare funzionalità che possono bloccare
+ la sospensione del sistema (dal kernel 3.5).\\
\const{CAP\_CHOWN} & Cambiare proprietario e gruppo
proprietario di un file (vedi
sez.~\ref{sec:file_ownership_management}).\\
sez.~\ref{sec:file_perm_management}).\\
\const{CAP\_KILL} & Mandare segnali a qualunque
processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
- \const{CAP\_SETFCAP} & Impostare le
- \textit{capabilities} di un file (dal kernel
- 2.6.24).\\
+ \const{CAP\_SETFCAP} & Impostare le \textit{capabilities} di un file (dal kernel
+ 2.6.24).\\
\const{CAP\_SETGID} & Manipolare i group ID dei
processi, sia il principale che i supplementari,
(vedi sez.~\ref{sec:proc_setgroups}) che quelli
funzioni \func{mlock}, \func{mlockall},
\func{shmctl}, \func{mmap} (vedi
sez.~\ref{sec:proc_mem_lock} e
- sez.~\ref{sec:file_memory_map}). \\
+ sez.~\ref{sec:file_memory_map}). \\
+% TODO verificare l'interazione con SHM_HUGETLB
\const{CAP\_IPC\_OWNER} & Evitare il controllo dei permessi
per le operazioni sugli oggetti di
intercomunicazione fra processi (vedi
sez.~\ref{sec:file_asyncronous_lease})
pur non essendo proprietari del file (dal kernel
2.4).\\
- \const{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli
- attributi \textit{immutable} e
- \itindex{append~mode} \textit{append-only} (vedi
+ \const{CAP\_LINUX\_IMMUTABLE}& Impostare sui file gli attributi
+ \textit{immutable} e \textit{append-only} (vedi
sez.~\ref{sec:file_perm_overview}) se
supportati.\\
- \const{CAP\_MKNOD} & Creare
- \index{file!di~dispositivo} file di dispositivo
- con \func{mknod} (vedi
+ \const{CAP\_MKNOD} & Creare \index{file!di~dispositivo} file di
+ dispositivo con \func{mknod} (vedi
sez.~\ref{sec:file_mknod}) (dal kernel 2.4).\\
\const{CAP\_NET\_ADMIN} & Eseguire alcune operazioni
privilegiate sulla rete.\\
- \const{CAP\_NET\_BIND\_SERVICE}& Porsi in ascolto
- su porte riservate (vedi
+ \const{CAP\_NET\_BIND\_SERVICE}& Porsi in ascolto su porte riservate (vedi
sez.~\ref{sec:TCP_func_bind}).\\
\const{CAP\_NET\_BROADCAST}& Consentire l'uso di socket in
\itindex{broadcast} \textit{broadcast} e
\itindex{multicast} \textit{multicast}.\\
- \const{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e
- \texttt{PACKET} (vedi sez.~\ref{sec:sock_type}).\\
+ \const{CAP\_NET\_RAW} & Usare socket \texttt{RAW} e \texttt{PACKET}
+ (vedi sez.~\ref{sec:sock_type}).\\
\const{CAP\_SETPCAP} & Effettuare modifiche privilegiate alle
\textit{capabilities}.\\
- \const{CAP\_SYS\_ADMIN} & Eseguire una serie di compiti
- amministrativi.\\
- \const{CAP\_SYS\_BOOT} & Eseguire un riavvio del
- sistema (vedi sez.~\ref{sec:sys_reboot}).\\
- \const{CAP\_SYS\_CHROOT}& Eseguire la funzione
- \func{chroot} (vedi sez.~\ref{sec:file_chroot}).\\
+ \const{CAP\_SYS\_ADMIN} & Eseguire una serie di compiti amministrativi.\\
+ \const{CAP\_SYS\_BOOT} & Eseguire un riavvio del sistema (vedi
+ sez.~\ref{sec:sys_reboot}).\\
+ \const{CAP\_SYS\_CHROOT}& Eseguire la funzione \func{chroot} (vedi
+ sez.~\ref{sec:file_chroot}).\\
\const{CAP\_MAC\_ADMIN} & Amministrare il \textit{Mandatory
- Access Control} di Smack (dal kernel 2.6.25).\\
- \const{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory
- Access Control} di Smack (dal kernel 2.6.25).\\
- \const{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del
- kernel.\\
- \const{CAP\_SYS\_NICE} & Modificare le varie priorità dei
- processi (vedi sez.~\ref{sec:proc_priority}).\\
- \const{CAP\_SYS\_PACCT} & Usare le funzioni di
- \textit{accounting} dei processi (vedi
- sez.~\ref{sec:sys_bsd_accounting}).\\
+ Access Control} di \textit{Smack} (dal kernel
+ 2.6.25).\\
+ \const{CAP\_MAC\_OVERRIDE}& Evitare il \textit{Mandatory
+ Access Control} di \textit{Smack} (dal kernel
+ 2.6.25).\\
+ \const{CAP\_SYS\_MODULE}& Caricare e rimuovere moduli del kernel.\\
+ \const{CAP\_SYS\_NICE} & Modificare le varie priorità dei processi (vedi
+ sez.~\ref{sec:proc_priority}).\\
+ \const{CAP\_SYS\_PACCT} & Usare le funzioni di \textit{accounting} dei
+ processi (vedi
+ sez.~\ref{sec:sys_bsd_accounting}).\\
\const{CAP\_SYS\_PTRACE}& La capacità di tracciare qualunque processo con
\func{ptrace} (vedi
sez.~\ref{sec:process_ptrace}).\\
- \const{CAP\_SYS\_RAWIO} & Operare sulle porte
- di I/O con \func{ioperm} e \func{iopl} (vedi
+ \const{CAP\_SYS\_RAWIO} & Operare sulle porte di I/O con \func{ioperm} e
+ \func{iopl} (vedi
sez.~\ref{sec:process_io_port}).\\
- \const{CAP\_SYS\_RESOURCE}& Superare le varie limitazioni
- sulle risorse.\\
- \const{CAP\_SYS\_TIME} & Modificare il tempo di sistema
- (vedi sez.~\ref{sec:sys_time}).\\
- \const{CAP\_SYS\_TTY\_CONFIG}&Simulare un \textit{hangup}
- della console, con la funzione
- \func{vhangup}.\\
+ \const{CAP\_SYS\_RESOURCE}& Superare le varie limitazioni sulle risorse.\\
+ \const{CAP\_SYS\_TIME} & Modificare il tempo di sistema (vedi
+ sez.~\ref{sec:sys_time}).\\
+ \const{CAP\_SYS\_TTY\_CONFIG}&Simulare un \textit{hangup} della console,
+ con la funzione \func{vhangup}.\\
\const{CAP\_SYSLOG} & Gestire il buffer dei messaggi
del kernel, (vedi sez.~\ref{sec:sess_daemon}),
introdotta dal kernel 2.6.38 come capacità
\label{tab:proc_capabilities}
\end{table}
-% \footnotetext{vale a dire i permessi caratteristici del modello classico del
-% controllo di accesso chiamato \itindex{Discrectionary~Access~Control~(DAC)}
-% \textit{Discrectionary Access Control} (da cui il nome DAC).}
-
Prima di dettagliare il significato della capacità più generiche, conviene
però dedicare un discorso a parte a \const{CAP\_SETPCAP}, il cui significato è
kernel) nel \textit{capabilities bounding set} usato di default, essa non è
neanche mai stata realmente disponibile.
-Con l'introduzione \itindex{file~capabilities} \textit{file capabilities} e
-il cambiamento del significato del \textit{capabilities bounding set} la
-possibilità di modificare le capacità di altri processi è stata completamente
-rimossa, e \const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere
-il suo significato originario, e cioè la capacità del processo di poter
-inserire nel suo \textit{inheritable set} qualunque capacità presente nel
-\textit{bounding set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP}
-consente ad un processo di eliminare una capacità dal proprio \textit{bounding
- set} (con la conseguente impossibilità successiva di eseguire programmi con
-quella capacità), o di impostare i \textit{securebits} delle
-\textit{capabilities}.
+Con l'introduzione \textit{file capabilities} e il cambiamento del significato
+del \textit{capabilities bounding set} la possibilità di modificare le
+capacità di altri processi è stata completamente rimossa, e
+\const{CAP\_SETPCAP} ha acquisito quello che avrebbe dovuto essere il suo
+significato originario, e cioè la capacità del processo di poter inserire nel
+suo \textit{inheritable set} qualunque capacità presente nel \textit{bounding
+ set}. Oltre a questo la disponibilità di \const{CAP\_SETPCAP} consente ad un
+processo di eliminare una capacità dal proprio \textit{bounding set} (con la
+conseguente impossibilità successiva di eseguire programmi con quella
+capacità), o di impostare i \textit{securebits} delle \textit{capabilities}.
La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare
maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un
La struttura a cui deve puntare l'argomento \param{hdrp} serve ad indicare,
tramite il campo \var{pid}, il \ids{PID} del processo del quale si vogliono
leggere o modificare le \textit{capabilities}. Con \func{capset} questo, se si
-usano le \itindex{file~capabilities} \textit{file capabilities}, può essere
-solo 0 o il \ids{PID} del processo chiamante, che sono equivalenti. Non
-tratteremo, essendo comunque di uso irrilevante, il caso in cui, in mancanza
-di tale supporto, la funzione può essere usata per modificare le
-\textit{capabilities} di altri processi, per il quale si rimanda, se
-interessati, alla lettura della pagina di manuale.
+usano le \textit{file capabilities}, può essere solo 0 o il \ids{PID} del
+processo chiamante, che sono equivalenti. Non tratteremo, essendo comunque di
+uso irrilevante, il caso in cui, in mancanza di tale supporto, la funzione può
+essere usata per modificare le \textit{capabilities} di altri processi, per il
+quale si rimanda, se interessati, alla lettura della pagina di manuale.
Il campo \var{version} deve essere impostato al valore della versione delle
stesse usata dal kernel (quello indicato da una delle costanti
\errval{ESRCH}. Gli stessi valori possono essere letti direttamente nel
filesystem \textit{proc}, nei file \texttt{/proc/<pid>/status}; ad esempio per
\texttt{init} si otterrà qualcosa del tipo:
-\begin{Command}
-$ cat /proc/1/status
-\end{Command}
-\begin{Terminal}
+\begin{Console}
+piccardi@hain:~/gapil$ \textbf{cat /proc/1/status}
...
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
...
-\end{Terminal}
+\end{Console}
%$
\itindend{capability~state}
l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni,
che si è tralasciata) al valore del \ids{PID} del processo di cui si vuole
leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso
-(\texttt{\small 1--6}) si utilizza (\texttt{\small 2}) \func{cap\_get\_proc}
+(\texttt{\small 1-6}) si utilizza (\texttt{\small 2}) \func{cap\_get\_proc}
per ottenere lo stato delle capacità del processo, nel secondo (\texttt{\small
- 7--13}) si usa invece \func{cap\_get\_pid} (\texttt{\small 8}) per leggere
+ 7-13}) si usa invece \func{cap\_get\_pid} (\texttt{\small 8}) per leggere
il valore delle capacità del processo indicato.
Il passo successivo è utilizzare (\texttt{\small 15}) \func{cap\_to\_text} per
tradurre in una stringa lo stato, e poi (\texttt{\small 16}) stamparlo; infine
-(\texttt{\small 18--19}) si libera la memoria allocata dalle precedenti
+(\texttt{\small 18-19}) si libera la memoria allocata dalle precedenti
funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della
funzione.
% cgroup o altro
% TODO: trattare la funzione setns e i namespace file descriptors (vedi
-% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0
+% http://lwn.net/Articles/407495/) introdotti con il kernel 3.0, altre
+% 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.
\textsl{imprigionato}.
Solo un processo con i privilegi di amministratore può usare questa
-funzione,\footnote{più precisamente se possiede la \itindex{capabilities}
- capacità \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in
+funzione,\footnote{più precisamente se possiede la capacità
+ \const{CAP\_SYS\_CHROOT}.} e la nuova radice, per quanto detto in
sez.~\ref{sec:proc_fork}, sarà ereditata da tutti i suoi processi figli. Si
tenga presente però che la funzione non cambia la directory di lavoro del
processo, che potrebbe restare fuori dalla \textit{chroot jail}.
projects / gapil.git / blobdiff