\section{Il controllo di accesso ai file}
-\label{sec:filedir_access_control}
+\label{sec:file_access_control}
Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
del controllo di accesso ai file, che viene implementato per qualunque
\subsection{I permessi per l'accesso ai file}
-\label{sec:filedir_perm_overview}
+\label{sec:file_perm_overview}
Il controllo di accesso ai file in unix segue un modello abbastanza semplice,
ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre
\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
identificatori di utenti e gruppi (\textsl{uid} e \textsl{gid}). Questi valori
sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
-della struttura \var{stat} (si veda \secref{sec:filedir_stat}). Ad ogni file
+della struttura \var{stat} (si veda \secref{sec:file_stat}). Ad ogni file
viene inoltre associato un insieme di permessi che sono divisi in tre classi,
e cioè attribuiti rispettivamente all'utente proprietario del file, a un
qualunque utente faccia parte del gruppo cui appartiene il file, e a tutti gli
I permessi, così come vengono presi dai comandi e dalle routine di sistema,
sono espressi da un numero di 12 bit; di questi i nove meno significativi sono
usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed
-esecuzione (indicati nei comandi di sistema con le lettere \textsl{w},
-\textit{r} \textsl{x}) ed applicabili rispettivamente al proprietario, al
-gruppo, a tutti. I restanti tre bit (\textsl{suid}, \textsl{sgid}, e
+esecuzione (indicati nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e
+\cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti
+gli altri. I restanti tre bit (\textsl{suid}, \textsl{sgid}, e
\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
-su cui torneremo in seguito (vedi \secref{sec:filedir_suid_sgid} e
-\secref{sec:filedir_sticky}).
-
-Anche i permessi sono tenuti per ciascun file (di qualunque tipo, quindi anche
-per le fifo, i socket e i file di dispositivo) nell'inode, in opportuni bit
-del campo \var{st\_mode} della struttura letta da \func{stat} (vedi
-\figref{fig:filedir_stat_struct}).
-
-In genere ci si riferisce a questi permessi usando le lettere \textsl{u} (per
-\textit{user}), \textsl{g} (per \textit{group}) e \textsl{o} (per
-\textit{other}), inoltre se si vuole indicare tutti questi gruppi insieme si
-usa la lettera \textsl{a} (per \textit{all}). Si tenga ben presente questa
-distinzione dato che in certi casi, mutuando la terminologia in uso nel VMS,
-si parla dei permessi base come di permessi di owner, group ed all, le cui
-iniziali possono da luogo a confusione. Le costanti che permettono di accedere
-al valore numerico di questi bit nel campo \var{st\_mode} sono riportate in
-\ntab.
+su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e
+\secref{sec:file_sticky}).
+
+Anche i permessi, come tutte le altre informazioni generali, sono tenuti per
+ciascun file nell'inode; in particolare essi sono contenuti in alcuni bit
+del campo \var{st\_mode} della struttura letta da \func{stat} (di nuovo si veda
+\secref{sec:file_stat} per i dettagli).
+
+In genere ci si riferisce a questo raggruppamento dei permessi usando le
+lettere \cmd{u} (per \textit{user}), \cmd{g} (per \textit{group}) e \cmd{o}
+(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
+insieme si usa la lettera \cmd{a} (per \textit{all}). Si tenga ben presente
+questa distinzione dato che in certi casi, mutuando la terminologia in uso nel
+VMS, si parla dei permessi base come di permessi per \textit{owner},
+\textit{group} ed \textit{all}, le cui iniziali possono dar luogo a confusione.
+Le costanti che permettono di accedere al valore numerico di questi bit nel
+campo \var{st\_mode} sono riportate in \ntab.
\begin{table}[htb]
\centering
I permessi per un link simbolico sono ignorati, contano quelli del file a cui
fa riferimento; per questo in genere \cmd{ls} per un link simbolico riporta
-tutti i permessi come concessi; anche utente e gruppo a cui appartiene vengono
-ignorati quando il link viene risolto, vengono controllati sono quando viene
+tutti i permessi come concessi; utente e gruppo a cui esso appartiene vengono
+ignorati quando il link viene risolto, vengono controllati solo quando viene
richiesta la rimozione del link e quest'ultimo è in una directory con lo
-\textsl{sticky bit} settato (vedi \secref{sec:filedir_sticky}).
+\textsl{sticky bit} settato (si veda \secref{sec:file_sticky}).
La procedura con cui il kernel stabilisce se un processo possiede un certo
permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
Per una spiegazione dettagliata degli identificatori associati ai processi si
veda \secref{sec:prochand_perms}; normalmente, a parte quanto vedremo in
-\secref{sec:filedir_suid_sgid}, l'\textit{effective user id} e
+\secref{sec:file_suid_sgid}, l'\textit{effective user id} e
l'\textit{effective group id} corrispondono a uid e gid dell'utente che ha
lanciato il processo, mentre i \textit{supplementary group id} sono quelli dei
gruppi cui l'utente appartiene.
processo appartiene ad un gruppo appropriato, in questo caso i permessi per
tutti gli altri non vengono controllati.
+
\subsection{I bit \textsl{suid} e \textsl{sgid}}
-\label{sec:filedir_suid_sgid}
+\label{sec:file_suid_sgid}
-Come si è accennato (in \secref{sec:filedir_perm_overview}) nei dodici bit del
+Come si è accennato (in \secref{sec:file_perm_overview}) nei dodici bit del
campo \var{st\_mode} usati per il controllo di accesso oltre ai bit dei
permessi veri e propri, ci sono altri tre bit che vengono usati per indicare
alcune proprietà speciali dei file. Due di questi sono i bit detti
Chiaramente avere un processo che ha privilegi superiori a quelli che avrebbe
normalmente l'utente che lo ha lanciato comporta vari rischi, e questo tipo di
programmi devono essere scritti accuratamente (torneremo sull'argomento in
-\secref{sec:prochand_perms}).
+\secref{sec:prochand_perms}) per evitare che possano essere usati per
+guadagnare privilegi non consentiti.
La presenza dei bit \textsl{suid} e \textsl{sgid} su un file può essere
rilevata con il comando \cmd{ls -l}, in tal caso comparirà la lettera \cmd{s}
questi bit. Infine questi bit possono essere controllati all'interno di
\var{st\_mode} con l'uso delle due costanti \macro{S\_ISUID} e
\macro{S\_IGID}, i cui valori sono riportati in
-\tabref{tab:filedir_file_mode_flags}.
+\tabref{tab:file_mode_flags}.
Gli stessi bit vengono ad assumere in significato completamente diverso per le
-directory, normalmente infatti Linux usa la convezione di SVR4 per indicare
+directory, normalmente infatti Linux usa la convenzione di SVR4 per indicare
con questi bit l'uso della semantica BSD nella creazione di nuovi file (si
-veda \secref{sec:filedir_ownership} per una spiegazione al proposito).
+veda \secref{sec:file_ownership} per una spiegazione dettagliata al
+proposito).
Infine Linux utilizza il bit \textsl{sgid} per una ulteriore estensione
-mutuata da SVR4; il caso in cui il file abbia il bit \textsl{sgid} settato ma
-non il corrispondente bit per l'esecuzione viene infatti utilizzato per
-attivare per quel file il \textit{mandatory locking} (argomento che
-affronteremo nei dettagli in \secref{sec:xxx_mandatory_lock}).
+mutuata da SVR4. Il caso in cui il file abbia il bit \textsl{sgid} settato ma
+non il corrispondente bit di esecuzione viene utilizzato per attivare per
+quel file il \textit{mandatory locking} (argomento che affronteremo nei
+dettagli in \secref{sec:xxx_mandatory_lock}).
+
\subsection{Il bit \textsl{sticky}}
-\label{sec:filedir_sticky}
+\label{sec:file_sticky}
-L'ultimo dei bit rimanenti, identificato dalla costante \macro{S\_ISVTX} è in
+L'ultimo dei bit rimanenti, identificato dalla costante \macro{S\_ISVTX}, è in
parte un rimasuglio delle origini dei sistemi unix. A quell'epoca infatti la
memoria virtuale e l'accesso ai files erano molto meno sofisticati e per
ottenere la massima velocità possibile per i programmi usati più comunemente
-si poteva settare questo bit.
+si poteva settare questo bit.
L'effetto di questo bit era che il segmento di testo del programma (si veda
\secref{sec:proc_mem_layout} per i dettagli) veniva scritto nella swap la
tempo di caricamento rispetto alla ricerca del file su disco.
Ovviamente per evitare che gli utenti potessero intasare la swap solo
-l'amministratore era in grado di settare questo bit, che venne poi chiamato
-anche \textit{saved text bit}, da cui deriva il nome della costante. Le
-attuali implementazioni di memoria virtuale e filesystem rendono
-sostanzialmente inutile questo procedimento.
+l'amministratore era in grado di settare questo bit, che venne chiamato anche
+\textit{saved text bit}, da cui deriva il nome della costante. Le attuali
+implementazioni di memoria virtuale e filesystem rendono sostanzialmente
+inutile questo procedimento. Lo \textsl{sticky bit} è indicato attraverso la
+lettera \cmd{t} al posto della \cmd{x} nei permessi per gli altri.
Benché ormai non venga più utilizzato per i file, lo \textsl{sticky bit} ha
-invece assunto un uso corrente per le directory\footnote{lo \textsl{sticky
- bit} è una estensione non definita nello standard POSIX, Linux però la
- supporta, così come BSD e SVR4}, se il bit è settato infatti un file può
-essere rimosso dalla directory soltanto se l'utente ha il permesso di
-scrittura ed inoltre è vera una delle seguenti condizioni:
+assunto un uso corrente per le directory\footnote{lo \textsl{sticky bit} è una
+ estensione non definita nello standard POSIX, Linux però la supporta, così
+ come BSD e SVR4}, in questo caso se il bit è settato un file potrà essere
+rimosso dalla directory soltanto se l'utente ha il permesso di scrittura ed
+inoltre è vera una delle seguenti condizioni:
\begin{itemize}
\item l'utente è proprietario del file
\item l'utente è proprietario della directory
\item l'utente è l'amministratore
\end{itemize}
-il classico esempio di directory che ha questo bit settato è \file{/tmp}, i
+un classico esempio di directory che ha questo bit settato è \file{/tmp}, i
permessi infatti di solito sono settati come:
\begin{verbatim}
+$ ls -l /tmp
drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
-\end{verbatim}
-in questo modo chiunque può leggere, scrivere ed eseguire i file, o crearne di
-nuovi, ma solo l'utente che ha creato un file nella directory potrà
-cancellarlo o rinominarlo.
+\end{verbatim}%$
+in questo modo chiunque può leggere, scrivere ed eseguire i file temporanei
+ivi memorizzati, sia crearne di nuovi, ma solo l'utente che ha creato un file
+nella directory potrà cancellarlo o rinominarlo, evitando così che utente
+possa, più o meno consapevolemnte, cancellare i file degli altri.
+
\subsection{La titolarità di nuovi file e directory}
-\label{sec:filedir_ownership}
+\label{sec:file_ownership}
-Vedremo in \secref{sec:fileunix_base_func} quali sono le funzioni per creare
-nuovi file, ma se è possibile specificare in sede di creazione quali permessi
-applicare ad un nuovo file, non si può indicare a quale utente e gruppo deve
-appartenere. Lo stesso problema di presenta per la creazione di nuove
-directory (descritto in \secref{sec:filedir_dir_creat_rem}).
+Vedremo in \secref{sec:file_base_func} come creare nuovi file, ma se è
+possibile specificare in sede di creazione quali permessi applicare ad un
+file, non si può indicare a quale utente e gruppo esso deve appartenere. Lo
+stesso problema di presenta per la creazione di nuove directory (procedimento
+descritto in \secref{sec:file_dir_creat_rem}).
Lo standard POSIX prescrive che l'uid del nuovo file corrisponda
all'\textit{effective user id} del processo che lo crea; per il gid invece
prevede due diverse possibilità:
\begin{itemize}
-\item il gid del file corrisponde all'\textit{effective group id} del processo
-\item il gid del file corrisponde al gid della directory in cui esso è creato
+\item il gid del file corrisponde all'\textit{effective group id} del processo.
+\item il gid del file corrisponde al gid della directory in cui esso è creato.
\end{itemize}
-in genere BSD usa sempre la seconda possibilità, che viene per questo anche
-chiamata semantica BSD. Linux invece segue quella che viene chiamata semantica
-SVR4; di norma cioè il nuovo file viene creato con il gid del processo, se
-però la directory in cui viene creato il file ha il bit sgid settato allora
-viene usato il gid di quest'ultima.
+in genere BSD usa sempre la seconda possibilità, che viene per questo chiamata
+semantica BSD. Linux invece segue quella che viene chiamata semantica SVR4; di
+norma cioè il nuovo file viene creato, seguendo la prima opzione, con il gid
+del processo, se però la directory in cui viene creato il file ha il bit
+\textsl{sgid} settato allora viene usata la seconda opzione..
Usare la semantica BSD ha il vantaggio che il gid viene sempre automaticamente
propagato, restando coerente a quello della directory di partenza, in tutte le
-sottodirectory, la semantica SVR4 offre una maggiore possibilità di scelta, ma
+sottodirectory. La semantica SVR4 offre una maggiore possibilità di scelta, ma
per ottenere lo stesso risultato necessita che per le nuove directory venga
-anche propagato anche il bit sgid, questo è comunque il comportamento di
+anche propagato anche il bit sgid. Questo è comunque il comportamento di
default di \func{mkdir}, ed é in questo modo ad esempio che Debian assicura
che le sottodirectory create nelle home di un utente restino sempre con il gid
del gruppo primario dello stesso.
\subsection{La funzione \texttt{access}}
-\label{sec:filedir_access}
+\label{sec:file_access}
-Come detto in \secref{sec:filedir_access_control} il controllo di accesso ad
+Come detto in \secref{sec:file_access_control} il controllo di accesso ad
un file viene fatto usando \textit{effective user id} e \textit{effective
group id} del processo, ma ci sono casi in cui si può voler effettuare il
controllo usando il \textit{real user id} e il \textit{real group id} (cioè
l'uid dell'utente che ha lanciato il programma, che, come accennato in
-\secref{sec:filedir_suid_sgid} e spiegato in \secref{sec:prochand_perms} non è
+\secref{sec:file_suid_sgid} e spiegato in \secref{sec:prochand_perms} non è
detto sia uguale all'\textit{effective user id}). Per far questo si può usare
la funzione \func{access}, il cui prototipo è:
file indicato da \var{pathname}.
La funzione ritorna 0 se l'accesso è consentito, -1 altrimenti; in
- quest'utlimo caso la variabile \texttt{errno} viene settata secondo i codici
+ quest'ultimo caso la variabile \texttt{errno} viene settata secondo i codici
di errore: \macro{EACCES}, \macro{EROFS}, \macro{EFAULT}, \macro{EINVAL},
\macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOTDIR}, \macro{ELOOP},
\macro{EIO}.
\end{tabular}
\caption{Valori possibile per il parametro \var{mode} della funzione
\func{access}}
- \label{tab:filedir_access_mode_val}
+ \label{tab:file_access_mode_val}
\end{table}
Un esempio tipico per l'uso di questa funzione è quello di un processo che sta
accedere ad un certo file.
-\subsection{La funzione \texttt{umask}}
-\label{sec:filedir_umask}
-
-Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai
-nuovi file sono controllati anche da una maschera di bit settata con la
-funzione \func{umask}. Questa viene utilizzata per impedire che alcuni
-permessi possano essere assegnati ai nuovi file, tutti i bit indicati nella
-maschera vengono infatti esclusi quando un nuovo file viene creato.
-
-
\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
-\label{sec:filedir_chmod}
+\label{sec:file_chmod}
Per cambiare i permessi di un file il sistema mette ad disposizione due
-funzioni, che operano rispettivamente su un filename e un file descriptor, i
-prototipi sono:
+funzioni, che operano rispettivamente su un filename e su un file descriptor,
+i cui prototipi sono:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
\funcdecl{int chmod(const char *path, mode\_t mode)} Cambia i permessi del
- file indicato da \var{path} al valore indicato da \var{mode}
+ file indicato da \var{path} al valore indicato da \var{mode}.
- \funcdecl{chmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa il
- file descriptor \var{fd} per indicare il file.
-
+ \funcdecl{int fchmod(int fd, mode\_t mode)} Analoga alla precedente, ma usa
+ il file descriptor \var{fd} per indicare il file.
Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
caso di errore \texttt{errno} viene settato ai valori:
\begin{errlist}
- \item \texttt{EPERM} L'uid non corrisponde a quello del file o non è zero.
+ \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello
+ del proprietario del file o non è zero.
\end{errlist}
+ Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e
+ \macro{EIO}; \func{chmod} restituisce anche \macro{EFAULT},
+ \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR},
+ \macro{EACCES}, \macro{ELOOP}; \func{fchmod} anche \macro{EBADF}.
\end{functions}
+I valori possibili per \var{mode} sono indicati in \ntab. I valori possono
+esser combinati con l'OR binario delle relative macro, o specificati
+direttamente, come per l'analogo comando di shell, con il valore ottale. Ad
+esempio i permessi standard assegnati ai nuovi file (lettura e scrittura per
+il proprietario, sola lettura per il gruppo e gli altri) sono corrispondenti
+al valore ottale $0644$, un programma invece avrebbe anche il bit di
+esecuzione attivo, con un valore di $0755$, se si volesse attivare il bit suid
+il valore da fornire sarebbe $4755$.
+
+\begin{table}[!htb]
+ \centering
+ \begin{tabular}[c]{|c|c|l|}
+ \hline
+ \var{mode} & Valore & Significato \\
+
+ \hline
+ \hline
+ \macro{S\_ISUID} & 04000 & set user ID \\
+
+ \macro{S\_ISGID} & 02000 & set group ID \\
+
+ \macro{S\_ISVTX} & 01000 & sticky bit \\
+
+ \hline
+ \macro{S\_IRWXU} & 00700 & l'utente ha tutti i permessi \\
+
+ \macro{S\_IRUSR} & 00400 & l'utente ha il permesso di lettura \\
+
+ \macro{S\_IWUSR} & 00200 & l'utente ha il permesso di scrittura \\
+
+ \macro{S\_IXUSR} & 00100 & l'utente ha il permesso di esecuzione \\
+
+ \hline
+ \macro{S\_IRWXG} & 00070 & il gruppo ha tutti i permessi \\
+
+ \macro{S\_IRGRP} & 00040 & il gruppo ha il permesso di lettura \\
+
+ \macro{S\_IWGRP} & 00020 & il gruppo ha il permesso di scrittura \\
+
+ \macro{S\_IXGRP} & 00010 & il gruppo ha il permesso di esecuzione \\
+
+ \hline
+ \macro{S\_IRWXO} & 00007 & gli altri hanno tutti i permessi \\
+
+ \macro{S\_IROTH} & 00004 & gli altri hanno il permesso di lettura \\
+
+ \macro{S\_IWOTH} & 00002 & gli altri hanno il permesso di scrittura \\
+
+ \macro{S\_IXOTH} & 00001 & gli altri hanno il permesso di esecuzione \\
+
+ \hline
+ \end{tabular}
+ \caption{I valori delle costanti usate per indicare i permessi dei file.}
+ \label{tab:file_permission_const}
+\end{table}
+
+Il cambiamento dei permessi di un file attraverso queste funzioni ha comunque
+alcune limitazioni, provviste per motivi di sicurezza. Questo significa che
+anche se si è proprietari del file non tutte le operazioni sono permesse, in
+particolare:
+\begin{itemize}
+\item siccome solo l'amministratore può settare lo \textit{sticky bit} se se
+ l'\textit{effective user id} del processo non è zero esso viene
+ automaticamente cancellato (senza notifica di errore) qualora sia stato
+ indicato in \var{mode}.
+\item per via della semantica SVR4 nella creazione dei nuovi file, si può
+ avere il caso in cui il file creato da un processo è assegnato a un gruppo
+ per il quale il processo non ha privilegi. Per evitare che si possa
+ assegnare il bit \textsl{sgid} ad un file appartenente a un gruppo per cui
+ non si hanno diritti, questo viene automaticamente cancellato (senza
+ notifica di errore) da \var{mode} qualora il gruppo del file non corrisponda
+ a quelli associati al processo (la cosa non avviene quando
+ l'\textit{effective user id} del processo è zero).
+\end{itemize}
+
+Per alcuni filesystem\footnote{il filesystem \textsl{ext2} supporta questa
+ caratteristica, che è mutuata da BSD.} è inoltre prevista una ulteriore
+misura di sicurezza, volta ad scongiurare l'abuso dei bit \textsl{suid} e
+\textsl{sgid}; essa consiste nel cancellare automaticamente questi bit qualora
+un processo che non appartenga all'amministratore scriva su un file. In questo
+modo anche se un utente malizioso scopre un file \textsl{suid} su cui può
+scrivere, un eventuale modifica comporterà la perdita di ogni ulteriore
+privilegio.
+
+
+\subsection{La funzione \texttt{umask}}
+\label{sec:file_umask}
+
+Oltre che dai valori indicati in sede di creazione, i permessi assegnati ai
+nuovi file sono controllati anche da una maschera di bit settata con la
+funzione \func{umask}, il cui prototipo è:
+
+\begin{prototype}{stat.h}
+{mode\_t umask(mode\_t mask)}
+
+ Setta la maschera dei permessi dei bit al valore specificato da \var{mask}
+ (di cui vengono presi solo i 9 bit meno significativi).
+
+ La funzione ritorna il precedente valore della maschera. È una delle poche
+ funzioni che non restituisce codici di errore.
+\end{prototype}
+
+Questa maschera è una caratteristica di ogni processo e viene utilizzata per
+impedire che alcuni permessi possano essere assegnati ai nuovi file in sede di
+creazione, i bit indicati nella maschera vengono infatti esclusi quando un
+nuovo file viene creato.
+
+In genere questa maschera serve per impostare un default che escluda alcuni
+permessi (usualmente quello di scrittura per il gruppo e gli altri,
+corrispondente ad un valore di $022$). Essa è utile perché le routine
+dell'interfaccia ANSI C degli stream non prevedono l'esistenza dei permessi, e
+pertanto tutti i nuovi file vengono sempre creati con un default di $666$
+(cioè permessi di lettura e scrittura per tutti, si veda
+\tabref{tab:file_permission_const} per un confronto); in questo modo è
+possibile cancellare automaticamente i permessi non voluti, senza doverlo fare
+esplicitamente.
+
+In genere il valore di \func{umask} viene stabilito una volta per tutte al
+login, e di norma gli utenti non hanno motivi per modificarlo. Se però si
+vuole che un processo possa creare un file che chiunque possa leggere allora
+occorrerà cambiare il valore di \func{umask}.
\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
-\label{sec:filedir_chown}
+\label{sec:file_chown}
+Come per i permessi, il sistema fornisce anche delle funzioni che permettano
+di cambiare utente e gruppo cui il file appartiene; le funzioni in questione
+sono tre e i loro prototipi sono i seguenti:
+\begin{functions}
+ \headdecl{sys/types.h}
+ \headdecl{sys/stat.h}
+
+ \funcdecl{int chown(const char *path, uid\_t owner, gid\_t group)}
+ \funcdecl{int fchown(int fd, uid\_t owner, gid\_t group)}
+ \funcdecl{int lchown(const char *path, uid\_t owner, gid\_t group)}
+ Le funzioni cambiano utente e gruppo di appartenenza di un file ai valori
+ specificati dalle variabili \var{owner} e \var{group}.
+
+ Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
+ caso di errore \texttt{errno} viene settato ai valori:
+ \begin{errlist}
+ \item \macro{EPERM} L'\textit{effective user id} non corrisponde a quello
+ del proprietario del file o non è zero, o utente e gruppo non sono validi
+ \end{errlist}
+ Oltre a questi entrambe restituiscono gli errori \macro{EROFS} e
+ \macro{EIO}; \func{chown} restituisce anche \macro{EFAULT},
+ \macro{ENAMETOOLONG}, \macro{ENOENT}, \macro{ENOMEM}, \macro{ENOTDIR},
+ \macro{EACCES}, \macro{ELOOP}; \func{fchown} anche \macro{EBADF}.
+\end{functions}
+
+Soltanto l'amministratore può cambiare il proprietario di un file, seguendo la
+semantica di BSD che non consente agli utenti di assegnare i loro file ad
+altri (per evitare eventuali aggiramenti delle quote). L'amministratore può
+cambiare il gruppo di un file, il proprietario può cambiare il gruppo dei file
+che gli appartengono solo se il nuovo gruppo è il suo gruppo primario o uno
+dei gruppi a cui appartiene.
+
+La funzione \func{chown} segue i link simbolici, per operare direttamente su
+in link simbolico si deve usare la funzione \func{lchown}\footnote{fino alla
+ versione 2.1.81 in Linux \func{chown} non seguiva i link simbolici, da
+ allora questo comportamento è stato assegnato alla funzione \func{lchown},
+ introdotta per l'occazione, ed è stata creata una nuova system call per
+ \func{chown} che seguisse i link simbolici}. La funzione \func{fchown} opera
+su un file aperto, essa è mututata da BSD, ma non è nello standard POSIX.
+Un'altra estensione rispetto allo standard POSIX è che specificando -1 come
+valore per \var{owner} e \var{group} i valori restano immutati.
+
+Quando queste funzioni sono chiamate con successo da un processo senza i
+privilegi di root entrambi i bit \textsl{suid} e \textsl{sgid} vengono
+cancellati. Questo non avviene per il bit \textsl{sgid} nel caso in cui esso
+sia usato (in assenza del corrispondente permesso di esecuzione) per indicare
+che per il file è attivo il \textit{mandatory locking}.
%La struttura fondamentale che contiene i dati essenziali relativi ai file è il
%cosiddetto \textit{inode}; questo conterrà informazioni come il
\section{La manipolazione delle caratteristiche dei files}
-\label{sec:filedir_infos}
+\label{sec:file_infos}
-Come spiegato in \secref{sec:fileintr_filesystem} tutte le informazioni
-generali relative alle caratteristiche di ciascun file sono mantenute
-nell'inode. Vedremo in questa sezione come sia possibile accedervi usando la
-funzione \texttt{stat} ed esamineremo alcune funzioni utilizzabili per
-manipolare una parte di questa informazione. Tutto quello che invece riguarda
-il meccanismo di controllo di accesso ad i file e le relative funzioni di
-manipolazione sarà invece esaminato in \secref{sec:filedir_access_control}.
+Come spiegato in \secref{sec:file_filesystem} tutte le informazioni
+generali relative alle caratteristiche di ciascun file, a partire dalle
+informazioni relative al controllo di accesso, sono mantenute nell'inode.
+
+Vedremo in questa sezione come sia possibile leggere tutte queste informazioni
+usando la funzione \texttt{stat}, esamineremo poi le varie funzioni che si
+possono per manipolare le restanti informazioni (avendo esaminato quelle per
+la gestione del controllo di accesso in \secref{sec:file_access_control}).
\subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
-\label{sec:filedir_stat}
+\label{sec:file_stat}
La lettura delle informazioni relative ai file è fatta attraverso la famiglia
delle funzioni \func{stat}, che è la funzione che il comando \cmd{ls} usa
descriptor \var{filedes}.
Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
- caso di errore \texttt{errno} viene settato ai valori:
- \begin{errlist}
- \item \texttt{EACCESS} non c'è il permesso di accedere al file.
- \item \texttt{ENOTDIR} una componente del pathname non è una directory.
- \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
- completare l'operazione.
- \item \texttt{ENAMETOOLONG} il filename è troppo lungo.
- \end{errlist}
+ caso di errore \texttt{errno} viene settato ai valori \macro{EACCESS},
+ \macro{EBADF}, \macro{ELOOP}, \macro{EFAULT}, \macro{ENOENT},
+ \macro{ENOTDIR}, \macro{ENOMEM}, \macro{ENAMETOOLONG}.
\end{functions}
La struttura \texttt{stat} è definita nell'header \texttt{sys/stat.h} e in
\normalsize
\caption{La struttura \texttt{stat} per la lettura delle informazioni dei
file}
- \label{fig:filedir_stat_struct}
+ \label{fig:file_stat_struct}
\end{figure}
Si noti come i vari membri della struttura siano specificati come tipi nativi
\subsection{I tipi di file}
-\label{sec:filedir_file_types}
+\label{sec:file_types}
-Come riportato in \tabref{tab:fileintr_file_types} in Linux oltre ai file e
+Come riportato in \tabref{tab:file_file_types} in Linux oltre ai file e
alle directory esistono vari altri oggetti che possono stare su un filesystem;
-il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode}.
+il tipo di file è ritornato dalla \texttt{stat} nel campo \texttt{st\_mode}
+(che è quello che contiene anche le informazioni relative ai permessi).
Dato che il valore numerico può variare a seconda delle implementazioni, lo
standard POSIX definisce un insieme di macro per verificare il tipo di files,
\hline
\end{tabular}
\caption{Macro per i tipi di file (definite in \texttt{sys/stat.h})}
- \label{tab:filedir_file_type_macro}
+ \label{tab:file_type_macro}
\end{table}
Oltre a queste macro è possibile usare direttamente il valore di
\macro{S\_ISGID} & 0002000 & set GID bit \\
\macro{S\_ISVTX} & 0001000 & sticky bit \\
\hline
- \macro{S\_IRWXU} & 00700 & bitmask per i permessi del proprietario \\
+% \macro{S\_IRWXU} & 00700 & bitmask per i permessi del proprietario \\
\macro{S\_IRUSR} & 00400 & il proprietario ha permesso di lettura \\
\macro{S\_IWUSR} & 00200 & il proprietario ha permesso di scrittura \\
\macro{S\_IXUSR} & 00100 & il proprietario ha permesso di esecuzione\\
\hline
- \macro{S\_IRWXG} & 00070 & bitmask per i permessi del gruppo \\
+% \macro{S\_IRWXG} & 00070 & bitmask per i permessi del gruppo \\
\macro{S\_IRGRP} & 00040 & il gruppo ha permesso di lettura \\
\macro{S\_IWGRP} & 00020 & il gruppo ha permesso di scrittura \\
\macro{S\_IXGRP} & 00010 & il gruppo ha permesso di esecuzione \\
\hline
- \macro{S\_IRWXO} & 00007 & bitmask per i permessi di tutti gli altri\\
+% \macro{S\_IRWXO} & 00007 & bitmask per i permessi di tutti gli altri\\
\macro{S\_IROTH} & 00004 & gli altri hanno permesso di lettura \\
\macro{S\_IWOTH} & 00002 & gli altri hanno permesso di esecuzione \\
\macro{S\_IXOTH} & 00001 & gli altri hanno permesso di esecuzione \\
\end{tabular}
\caption{Costanti per l'identificazione dei vari bit che compongono il campo
\var{st\_mode} (definite in \texttt{sys/stat.h})}
- \label{tab:filedir_file_mode_flags}
+ \label{tab:file_mode_flags}
\end{table}
Il primo valore definisce la maschera dei bit usati nei quali viene
in cui prima si estraggono da \var{st\_mode} i bit relativi al tipo di file e
poi si effettua il confronto con la combinazione di tipi scelta.
+
\subsection{La dimensione dei file}
-\label{sec:filedir_file_size}
+\label{sec:file_file_size}
Il membro \var{st\_size} contiene la dimensione del file in byte (se il file
è un file normale, nel caso di un link simbolico al dimensione è quella del
che corrisponda all'occupazione dello spazio su disco per via della possibile
esistenza dei cosiddetti \textsl{buchi} (detti normalmente \textit{holes}) che
si formano tutte le volte che si va a scrivere su un file dopo aver eseguito
-una \func{seek} (vedi \secref{sec:fileunix_lseek}) oltre la sua conclusione
+una \func{seek} (vedi \secref{sec:file_lseek}) oltre la sua conclusione
corrente.
In tal caso si avranno differenti risultati a seconda del modi in cui si
\funcdecl{int ftruncate(int fd, off\_t length))} Identica a \func{truncate}
eccetto che si usa con un file aperto, specificato tramite il suo file
- descriptor \var{fd},
+ descriptor \var{fd}.
Le funzioni restituiscono zero in caso di successo e -1 per un errore, in
- caso di errore \texttt{errno} viene settato ai valori:
+ caso di errore \texttt{errno} viene settato opportunamente; per
+ \func{ftruncate} si hanno i valori:
\begin{errlist}
- \item \texttt{EACCESS} non c'è il permesso di accedere al file.
- \item \texttt{ENOTDIR} una componente del pathname non è una directory.
- \item \texttt{EMLOOP} ci sono troppi link simbolici nel pathname.
- \item \texttt{EFAULT} i puntatori usati sono fuori dallo spazio di indirizzi
- del processo.
- \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
- completare l'operazione.
- \item \texttt{ENOENT} il file non esiste.
- \item \texttt{ENAMETOOLONG} il filename è troppo lungo.
+ \item \macro{EBADF} \var{fd} non è un file descriptor.
+ \item \texttt{EINVAL} \var{fd} è un riferimento ad un socket, non a un file
+ o non è aperto in scrittura.
\end{errlist}
+ per \func{truncate} si hanno:
+ \begin{errlist}
+ \item \texttt{EACCES} il file non ha permesso di scrittura o non si ha il
+ permesso di esecuzione una delle directory del pathname.
+ \item \texttt{ETXTBSY} Il file è un programma in esecuzione.
+ \end{errlist}
+ ed anche \macro{ENOTDIR}, \macro{ENAMETOOLONG}, \macro{ENOENT},
+ \macro{EROFS}, \macro{EIO}, \macro{EFAULT}, \macro{ELOOP}.
\end{functions}
Se il file è più lungo della lunghezza specificata i dati in eccesso saranno
\subsection{I tempi dei file}
-\label{sec:filedir_file_times}
+\label{sec:file_file_times}
Il sistema mantiene per ciascun file tre tempi. Questi sono registrati
nell'inode insieme agli altri attibuti del file e possono essere letti tramite
la funzione \func{stat}, che li restituisce attraverso tre campi della
-struttura in \figref{fig:filedir_stat_struct}. Il significato di detti tempi e
+struttura in \figref{fig:file_stat_struct}. Il significato di detti tempi e
dei relativi campi è riportato nello schema in \ntab:
\begin{table}[htb]
\hline
\end{tabular}
\caption{I tre tempi associati a ciascun file}
- \label{tab:filedir_file_times}
+ \label{tab:file_file_times}
\end{table}
Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di
\caption{Effetti delle varie funzioni su tempi di ultimo accesso
\textsl{(a)}, ultima modifica \textsl{(m)} e ultimo cambiamento
\textsl{(c)}}
- \label{tab:filedir_times_effects}
+ \label{tab:file_times_effects}
\end{table}
Si noti infine come \var{st\_ctime} non abbia nulla a che fare con il tempo di
\subsection{La funzione \texttt{utime}}
-\label{sec:filedir_utime}
+\label{sec:file_utime}
I tempi di ultimo accesso e modifica possono essere cambiati usando la
funzione \func{utime}, il cui prototipo è:
-
-
-
\section{La manipolazione di file e directory}
-Come già accennato in \secref{sec:fileintr_filesystem} in un sistema unix-like
+Come già accennato in \secref{sec:file_filesystem} in un sistema unix-like
i file hanno delle caratteristiche specifiche dipendenti dall'architettura del
sistema, esamineremo qui allora le funzioni usate per la creazione di link
simbolici e diretti e per la gestione delle directory, approfondendo quanto
\subsection{Le funzioni \texttt{link} e \texttt{unlink}}
-\label{sec:fileintr_link}
+\label{sec:file_link}
Una delle caratteristiche comuni a vari sistemi operativi è quella di poter
creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo
ma data la struttura del sistema ci sono due metodi sostanzialmente diversi
per fare questa operazione.
-Come spiegato in \secref{sec:fileintr_architecture} l'accesso al contenuto di
+Come spiegato in \secref{sec:file_architecture} l'accesso al contenuto di
un file su disco avviene attraverso il suo inode, e il nome che si trova in
una directory è solo una etichetta associata ad un puntatore a detto inode.
Questo significa che la realizzazione di un link è immediata in quanto uno
nome ai precedenti. Si noti che uno stesso file può essere così richiamato in
diverse directory.
-Per quanto dicevamo in \secref{sec:fileintr_filesystem} la creazione del
+Per quanto dicevamo in \secref{sec:file_filesystem} la creazione del
collegamento diretto è possibile solo se entrambi i pathname sono nello stesso
filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è
il caso ad esempio del filesystem \texttt{vfat} di windows).
in alcuni filesystem solo l'amministratore è in grado di creare un
collegamento diretto ad un'altra directory, questo lo si fa perché in questo
caso è possibile creare dei circoli nel filesystem (vedi
-\secref{sec:fileintr_symlink}) che molti programmi non sono in grado di
+\secref{sec:file_symlink}) che molti programmi non sono in grado di
gestire e la cui rimozione diventa estremamente complicata (in genere occorre
far girare il programma \texttt{fsck} per riparare il filesystem); data la sua
pericolosità in generale nei filesystem usati in Linux questa caratteristica è
\texttt{unlink} subito dopo.
\subsection{Le funzioni \texttt{remove} e \texttt{rename}}
-\label{sec:fileintr_remove}
+\label{sec:file_remove}
Al contrario di quanto avviene con altri unix in Linux non è possibile usare
\texttt{unlink} sulle directory, per cancellare una directory si può usare la
-funzione \texttt{rmdir} (vedi \secref{sec:filedir_dir_creat_rem}), oppure la
+funzione \texttt{rmdir} (vedi \secref{sec:file_dir_creat_rem}), oppure la
funzione \texttt{remove}. Questa è la funzione prevista dallo standard ANSI C
per cancellare un file o una directory (e funziona anche per i sistemi che non
supportano i link diretti), che per i file è identica alla \texttt{unlink} e
\item \texttt{ENOTDIR} Uno dei componenti dei pathname non è una directory
o\texttt{oldpath} è una directory e \texttt{newpath} esiste e non è una
directory.
- \item \texttt{EFAULT} o \texttt{oldpath} o \texttt{newpath} è fuori dello
- spazio di indirizzi del processo.
\item \texttt{EACCESS} Non c'è il permesso di scrittura per la directory in
cui si vuole creare il nuovo link o una delle directory del pathname non
consente la ricerca (permesso di esecuzione).
\texttt{newpath} hanno lo sticky bit attivo e i permessi del processo non
consentono rispettivamente la cancellazione e la creazione del file, o il
filesystem non supporta i link.
- \item \texttt{ENAMETOOLONG} uno dei pathname è troppo lungo.
- \item \texttt{ENOENT} Uno dei componenti del pathname non esiste o è un link
- simbolico spezzato.
- \item \texttt{ENOMEM} il kernel non ha a disposizione memoria sufficiente a
- completare l'operazione.
- \item \texttt{EROFS} I file sono su un filesystem montato in sola lettura.
- \item \texttt{ELOOP} Ci sono troppi link simbolici nella risoluzione del
- pathname.
\item \texttt{ENOSPC} Il device di destinazione non ha più spazio per la
nuova voce.
\end{errlist}
\end{prototype}
\subsection{I link simbolici}
-\label{sec:fileintr_symlink}
+\label{sec:file_symlink}
Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può
funzionare soltanto per file che risiedono sullo stesso filesystem, dato che
La funzione restituisce zero in caso di successo e -1 per un errore, in caso
di errore. La variabile \texttt{errno} viene settata secondo i codici di
errore standard di accesso ai file (trattati in dettaglio in
- \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
+ \secref{sec:file_access_control}) ai quali si aggiungono i seguenti:
\begin{errlist}
\item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
già.
\hline
\end{tabular}
\caption{Uso dei link simbolici da parte di alcune funzioni.}
- \label{tab:filedir_symb_effect}
+ \label{tab:file_symb_effect}
\end{table}
si noti che non si è specificato il comportamento delle funzioni che operano
con i file descriptor, in quanto la gestione del link simbolico viene in
\centering
\includegraphics[width=5cm]{img/link_loop.eps}
\caption{Esempio di loop nel filesystem creato con un link simbolico.}
- \label{fig:filedir_link_loop}
+ \label{fig:file_link_loop}
\end{figure}
Un caso comune che si può avere con i link simbolici è la creazione dei
\subsection{Le funzioni \texttt{mkdir} e \texttt{rmdir}}
-\label{sec:filedir_dir_creat_rem}
+\label{sec:file_dir_creat_rem}
Per creare una nuova directory si può usare la seguente funzione, omonima
dell'analogo comando di shell \texttt{mkdir}; per accedere ai tipi usati
La funzione restituisce zero in caso di successo e -1 per un errore, in caso
di errore \texttt{errno} viene settata secondo i codici di errore standard
di accesso ai file (trattati in dettaglio in
- \secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
+ \secref{sec:file_access_control}) ai quali si aggiungono i seguenti:
\begin{errlist}
\item \texttt{EACCESS}
Non c'è il permesso di scrittura per la directory in cui si vuole inserire
\subsection{Accesso alle directory}
-\label{sec:filedir_dir_read}
+\label{sec:file_dir_read}
Benché le directory siano oggetti del filesystem come tutti gli altri non ha
ovviamente senso aprirle come fossero dei file di dati. Può però essere utile
la funzione \texttt{opendir} apre uno di questi stream e la funzione
\texttt{readdir} legge il contenuto della directory, i cui elementi sono le
\textit{directory entries} (da distinguersi da quelle della cache di cui
-parlavamo in \secref{sec:fileintr_vfs}) in una opportuna struttura
+parlavamo in \secref{sec:file_vfs}) in una opportuna struttura
\texttt{struct dirent}.
\subsection{La directory di lavoro}
-\label{sec:filedir_work_dir}
+\label{sec:file_work_dir}
A ciascun processo è associato ad una directory nel filesystem che è chiamata
directory corrente o directory di lavoro (\textit{current working directory})
Entrambe le funzioni restituiscono zero in caso di successo e -1 per un
errore, in caso di errore \texttt{errno} viene settata secondo i codici di
errore standard di accesso ai file (trattati in dettaglio in
- \secref{sec:filedir_access_control}) ai quali si aggiunge il codice
+ \secref{sec:file_access_control}) ai quali si aggiunge il codice
\texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
una directory.
\end{prototype}
projects / gapil.git / blobdiff