file che si vuole creare ed i relativi permessi, secondo i valori riportati in
tab.~\ref{tab:file_mode_flags}, che vanno combinati con un OR binario. I
permessi sono comunque modificati nella maniera usuale dal valore di
-\var{umask} (si veda sez.~\ref{sec:file_perm_management}).
+\itindex{umask} \textit{umask} (si veda sez.~\ref{sec:file_perm_management}).
Per il tipo di file può essere specificato solo uno fra: \const{S\_IFREG} per
un file regolare (che sarà creato vuoto), \const{S\_IFBLK} per un dispositivo
La funzione crea la fifo \param{pathname} con i permessi \param{mode}. Come
per \func{mknod} il file \param{pathname} non deve esistere (neanche come link
simbolico); al solito i permessi specificati da \param{mode} vengono
-modificati dal valore di \var{umask}.
+modificati dal valore di \itindex{umask} \textit{umask}.
primitivi del sistema (di quelli definiti in
tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.h}).
+% TODO: aggiornare con i cambiamenti ai tempi fatti con il 2.6
\subsection{I tipi di file}
\label{sec:file_types}
\textbf{Macro} & \textbf{Tipo del file} \\
\hline
\hline
- \macro{S\_ISREG(m)} & File normale.\\
- \macro{S\_ISDIR(m)} & Directory.\\
- \macro{S\_ISCHR(m)} & Dispositivo a caratteri.\\
- \macro{S\_ISBLK(m)} & Dispositivo a blocchi.\\
- \macro{S\_ISFIFO(m)} & Fifo.\\
- \macro{S\_ISLNK(m)} & Link simbolico.\\
- \macro{S\_ISSOCK(m)} & Socket.\\
+ \macro{S\_ISREG(m)} & file normale.\\
+ \macro{S\_ISDIR(m)} & directory.\\
+ \macro{S\_ISCHR(m)} & dispositivo a caratteri.\\
+ \macro{S\_ISBLK(m)} & dispositivo a blocchi.\\
+ \macro{S\_ISFIFO(m)} & fifo.\\
+ \macro{S\_ISLNK(m)} & link simbolico.\\
+ \macro{S\_ISSOCK(m)} & socket.\\
\hline
\end{tabular}
\caption{Macro per i tipi di file (definite in \texttt{sys/stat.h}).}
del file) allora:
\begin{itemize*}
\item se il relativo\footnote{per relativo si intende il bit di user-read se
- il processo vuole accedere in scrittura, quello di user-write per
+ il processo vuole accedere in lettura, quello di user-write per
l'accesso in scrittura, ecc.} bit dei permessi d'accesso dell'utente è
impostato, l'accesso è consentito
\item altrimenti l'accesso è negato
consentito,
\item altrimenti l'accesso è negato
\end{itemize*}
-\item se il bit dei permessi d'accesso per tutti gli altri è impostato,
+\item Se il bit dei permessi d'accesso per tutti gli altri è impostato,
l'accesso è consentito, altrimenti l'accesso è negato.
\end{enumerate}
l'uso del \itindex{suid~bit} \textit{suid bit}) che vuole controllare se
l'utente originale ha i permessi per accedere ad un certo file.
+% TODO documentare euidaccess (e eaccess)
+
Per cambiare i permessi di un file il sistema mette ad disposizione due
funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un
filename e su un file descriptor, i loro prototipi sono:
gruppi, ed inoltre il problema si pone anche per l'interfaccia nativa quando i
permessi non vengono indicati esplicitamente.
-In tutti questi casi l'unico riferimento possibile è quello della modalità di
-apertura del nuovo file (lettura/scrittura o sola lettura), che però può
-fornire un valore che è lo stesso per tutti e tre i permessi di
-sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e $222$ nel
-secondo). Per questo motivo il sistema associa ad ogni processo\footnote{è
- infatti contenuta nel campo \var{umask} della struttura \struct{fs\_struct},
- vedi fig.~\ref{fig:proc_task_struct}.} una maschera di bit, la cosiddetta
-\textit{umask}, che viene utilizzata per impedire che alcuni permessi possano
-essere assegnati ai nuovi file in sede di creazione. I bit indicati nella
-maschera vengono infatti cancellati dai permessi quando un nuovo file viene
-creato.
+\itindbeg{umask}
+
+Per le funzioni dell'interfaccia standard ANSI C l'unico riferimento possibile
+è quello della modalità di apertura del nuovo file (lettura/scrittura o sola
+lettura), che però può fornire un valore che è lo stesso per tutti e tre i
+permessi di sez.~\ref{sec:file_perm_overview} (cioè $666$ nel primo caso e
+$222$ nel secondo). Per questo motivo il sistema associa ad ogni
+processo\footnote{è infatti contenuta nel campo \var{umask} della struttura
+ \struct{fs\_struct}, vedi fig.~\ref{fig:proc_task_struct}.} una maschera di
+bit, la cosiddetta \textit{umask}, che viene utilizzata per impedire che
+alcuni permessi possano essere assegnati ai nuovi file in sede di creazione. I
+bit indicati nella maschera vengono infatti cancellati dai permessi quando un
+nuovo file viene creato.\footnote{l'operazione viene fatta sempre: anche
+ qualora si indichi esplicitamente un valore dei permessi nelle funzioni di
+ creazione che lo consentono, i permessi contenuti nella \textit{umask}
+ verranno tolti.}
La funzione che permette di impostare il valore di questa maschera di
controllo è \funcd{umask}, ed il suo prototipo è:
voluti. Di norma questo valore viene impostato una volta per tutte al login a
$022$, e gli utenti non hanno motivi per modificarlo.
+\itindend{umask}
\subsection{La gestione della titolarità dei file}
gli \textit{Extended Attributes} (anche se su Solaris hanno lo stesso nome),
che sono un meccanismo molto più semplice, che pur essendo limitato (potendo
contenere solo una quantità limitata di informazione) hanno il grande
-vantaggio di essere molto più semplici da realizzare e più
+vantaggio di essere molto più semplici da realizzare, più
efficienti,\footnote{cosa molto importante, specie per le applicazioni che
richiedono una gran numero di accessi, come le ACL.} e di garantire
l'atomicità di tutte le operazioni.
\begin{table}[htb]
\centering
\footnotesize
- \begin{tabular}{|c|p{8cm}|}
+ \begin{tabular}{|c|p{10cm}|}
\hline
\textbf{Nome} & \textbf{Descrizione} \\
\hline
rispondere in maniera adeguata a situazioni che richiedono una gestione
complessa dei permessi di accesso.\footnote{già un requisito come quello di
dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non
- si può soddisfare in maniera soddisfacente.}
+ si può soddisfare in maniera semplice.}
Per questo motivo erano state progressivamente introdotte nelle varie versioni
di Unix dei meccanismi di gestione dei permessi dei file più flessibili, nella
uno standard, dato però che una parte della documentazione prodotta era di
alta qualità venne deciso di rilasciare al pubblico la diciassettesima bozza
del documento, quella che va sotto il nome di \textit{POSIX 1003.1e Draft 17},
-che è divenuta la base sulla quale si definiscono quelle che vanno sotto il
-nome di \textit{Posix ACL}.
+che è divenuta la base sulla quale si definiscono le cosiddette \textit{Posix
+ ACL}.
A differenza di altri sistemi (ad esempio FreeBSD) nel caso di Linux si è
scelto di realizzare le ACL attraverso l'uso degli
Anche in questo caso le funzioni di questa libreria non fanno parte delle
\acr{glibc} e devono essere installate a parte;\footnote{la versione corrente
della libreria è \texttt{libacl1}, e nel caso si usi Debian la si può
- installare con il pacchetto omonimo ed il collegato \texttt{libacl1-dev}.}
-pertanto se un programma le utilizza si dovrà indicare esplicitamente l'uso
-della libreria \texttt{libacl} invocando il compilatore con l'opzione
-\texttt{-lacl}.
+ installare con il pacchetto omonimo e con il collegato \texttt{libacl1-dev}
+ per i file di sviluppo.} pertanto se un programma le utilizza si dovrà
+indicare esplicitamente l'uso della libreria \texttt{libacl} invocando il
+compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che per
+poterle utilizzare le ACL devono essere attivate esplicitamente montando il
+filesystem\footnote{che deve supportarle, ma questo è ormai vero per
+ praticamente tutti i filesystem più comuni, con l'eccezione di NFS per il
+ quale esiste però un supporto sperimentale.} su cui le si vogliono
+utilizzare con l'opzione \texttt{acl} attiva. Dato che si tratta di una
+estensione è infatti opportuno utilizzarle soltanto laddove siano necessarie.
+
+Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
+costituita da un \textsl{tipo}, da un eventuale
+\textsl{qualificatore},\footnote{deve essere presente soltanto per le voci di
+ tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi.
+Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
+permessi di accesso, detta \textit{access ACL}. Inoltre per le directory si
+può impostare una ACL aggiuntiva, detta \textit{default ACL}, che serve ad
+indicare quale dovrà essere la ACL assegnata di default nella creazione di un
+file all'interno della directory stessa. Come avviene per i permessi le ACL
+possono essere impostate solo del proprietario del file, o da un processo con
+la capability \index{capabilities} \const{CAP\_FOWNER}.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{8cm}|}
+ \hline
+ \textbf{Tipo} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{ACL\_USER\_OBJ} & voce che contiene i diritti di accesso del
+ proprietario del file.\\
+ \const{ACL\_USER} & voce che contiene i diritti di accesso per
+ l'utente indicato dal rispettivo
+ qualificatore.\\
+ \const{ACL\_GROUP\_OBJ}& voce che contiene i diritti di accesso del
+ gruppo proprietario del file.\\
+ \const{ACL\_GROUP} & voce che contiene i diritti di accesso per
+ il gruppo indicato dal rispettivo
+ qualificatore.\\
+ \const{ACL\_MASK} & voce che contiene la maschera dei massimi
+ permessi di accesso che possono essere garantiti
+ da voci del tipo \const{ACL\_USER},
+ \const{ACL\_GROUP} e \const{ACL\_GROUP\_OBJ}.\\
+ \const{ACL\_OTHER} & voce che contiene i diritti di accesso di chi
+ non corrisponde a nessuna altra voce dell'ACL.\\
+ \hline
+ \end{tabular}
+ \caption{Le costanti che identificano i tipi delle voci di una ACL.}
+ \label{tab:acl_tag_types}
+\end{table}
+L'elenco dei vari tipi di voci presenti in una ACL, con una breve descrizione
+del relativo significato, è riportato in tab.~\ref{tab:acl_tag_types}. Tre di
+questi tipi, \const{ACL\_USER\_OBJ}, \const{ACL\_GROUP\_OBJ} e
+\const{ACL\_OTHER}, corrispondono direttamente ai tre permessi ordinari dei
+file (proprietario, gruppo proprietario e tutti gli altri) e una ACL valida
+deve sempre contenere una ed una sola voce per ciascuno di questi tipi.
+
+Una ACL può poi contenere un numero arbitrario di voci di tipo
+\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
+permessi assegnati all'utente e al gruppo indicato dal relativo qualificatore;
+ovviamente un utente o gruppo potranno essere indicati una sola volta
+all'interno di una ACL. Inoltre se in una ACL esiste una voce di uno di questi
+due tipi è obbligatoria anche la presenza di una ed una sola voce di tipo
+\const{ACL\_MASK}, che negli altri casi è opzionale.
+
+Quest'ultimo tipo di voce contiene la maschera dei permessi che possono essere
+assegnati tramite voci di tipo \const{ACL\_USER}, \const{ACL\_GROUP} e
+\const{ACL\_GROUP\_OBJ}, se in una di queste voci si fosse specificato un
+permesso non presente in \const{ACL\_MASK} questo verrebbe ignorato. L'uso di
+\const{ACL\_MASK} è di particolare utilità quando associata ad una
+\textit{default ACL} di una directory in quanto i permessi così specificati
+vengono ereditati da tutti i file creati nella stessa, ottenendo una sorta di
+\itindex{umask} \textit{umask} associata ad un oggetto sul filesystem
+piuttosto che a un processo.
+
+Dato che le ACL vengono a costituire una estensione dei permess ordinari, uno
+dei problemi che si erano posti nella loro standardizzazione era appunto
+quello della corrispondenza fra questi e le ACL. Come accennato i permessi
+ordinari vengono mappati le tre voci di tipo \const{ACL\_USER\_OBJ},
+\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER} che devono essere presenti in
+qualunque ACL; un cambiamento ad una di queste voci viene automaticamente
+riflesso sui permessi ordinari dei file\footnote{per permessi ordinari si
+ intende quelli mantenuti nell'\textit{inode}, che devono restare dato che un
+ filesystem può esseere montato senza abilitare le ACL.} e viceversa. In
+realtà la mappatura è diretta solo per le voci \const{ACL\_USER\_OBJ} e
+\const{ACL\_OTHER}, nel caso di \const{ACL\_GROUP\_OBJ} questo vale fintanto
+che non è presente una voce di tipo \const{ACL\_MASK}, nel qual caso valgono
+invece i permessi in essa specificati.\footnote{questo diverso comportamento a
+ seconda delle condizioni è stato introdotto dalla standardizzazione
+ \textit{POSIX 1003.1e Draft 17} per mantenere il comportamento invariato sui
+ sistemi dotati di ACL per tutte quelle applicazioni che sono conformi
+ soltanto all'ordinario standard \textit{POSIX 1003.1}.}
+
+Un secondo aspetto dell'incidenza delle ACL sul comportamento del sistema è
+quello relativo alla creazione di nuovi file,\footnote{o oggetti sul
+ filesystem, il comportamento discusso vale per le funzioni \func{open} e
+ \func{creat} (vedi sez.~\ref{sec:file_open}), \func{mkdir} (vedi
+ sez.~\ref{sec:file_dir_creat_rem}), \func{mknod} e \func{mkfifo} (vedi
+ sez.~\ref{sec:file_mknod}).} che come accennato può essere modificato dalla
+presenza di una default ACL sulla directory che contiene quel file. Se questa
+non c'è valgono le regole illustrate in sez.~\ref{sec:file_perm_management}
+per cui essi sono determinati dalla \itindex{umask} \textit{umask} del
+processo, e la sola differenza è che i permessi ordinari da esse risultanti
+vengono automaticamente rimappati su una ACL di accesso assegnata al nuovo
+file che contiene solo le tre voci di tipo \const{ACL\_USER\_OBJ},
+\const{ACL\_GROUP\_OBJ} e \const{ACL\_OTHER}.
+
+Se invece è presente una ACL di default sulla directory che contiene il nuovo
+file questa diventerà la sua ACL di accesso, a meno di non aver indicato nelle
+funzioni di creazione che lo consentono uno specifico insieme di
+permessi.\footnote{tutte le funzioni citate in precedenza supportano un
+ argomento \var{mode} che indichi un insieme di permssi iniziale.} In tal
+caso quelli non presenti in tale insieme saranno eliminati dalle voci
+corrispondenti nella ACL.
+
+Ovviamente la presenza della ACL modifica anche le regole del controllo di
+accesso ai file illustrate in sez.~\ref{sec:file_perm_overview}; per il
+controllo vengono sempre utilizzati gli identificatori del gruppo
+\textit{effective} del processo, ed i passi attraverso i quali viene stabilito
+se esso ha diritto di accesso sono i seguenti:
+\begin{enumerate}
+\item Se l'user-ID del processo è nullo l'accesso è sempre garantito senza
+ nessun ulteriore controllo.
+\item Se l'user-ID del processo corrisponde al proprietario del file allora:
+ \begin{itemize*}
+ \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
+ l'accesso è consentito
+ \item altrimenti l'accesso è negato
+ \end{itemize*}
+\item Se l'user-ID del processo corrisponde ad un qualunque qualificatore
+ presente in una voce \const{ACL\_USER} allora:
+ \begin{itemize*}
+ \item se la voce \const{ACL\_USER} corrispondente e la voce
+ \const{ACL\_MASK} contengono entrambe il permesso richiesto, l'accesso è
+ consentito
+ \item altrimenti l'accesso è negato
+ \end{itemize*}
+\item Se il group-ID del processo o uno dei group-ID supplementari corrisponde
+ al gruppo proprietario del file o a un qualunque qualificatore di una voce
+ di tipo allora:
+ \begin{itemize*}
+ \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è
+ consentito,
+ \item altrimenti l'accesso è negato
+ \end{itemize*}
+\item Se il bit dei permessi d'accesso per tutti gli altri è impostato,
+ l'accesso è consentito, altrimenti l'accesso è negato.
+\end{enumerate}
projects / gapil.git / blobdiff