-\chapter{Files e directories}
+\chapter{File e directory}
\label{cha:files_and_dirs}
In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
identificatori di utenti e gruppi (\textsl{uid} e \textsl{gid}), e accessibili
-da programm tramite i campi \var{st\_uid} e \var{st\_gid} della struttura
+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 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 altri
utenti.
-I permessi sono espressi da un insieme 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 rispettivamente con le lettere
-\textsl{w}, \textit{r} \textsl{x} nei comandi di sistema) applicabili
-rispettivamente al proprietario, al gruppo, a tutti. 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
+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 rispettivamente con le lettere \textsl{w}, \textit{r}
+\textsl{x} nei comandi di sistema) applicabili rispettivamente al
+proprietario, al gruppo, a tutti. 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
\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 termimologia in uso nel VMS,
+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 confuzione. Le costanti che permettono di accedere
+iniziali possono da luogo a confusione. Le costanti che permettono di accedere
al valore numerico di questi bit sono riportate in \ntab.
\begin{table}[htb]
shell), occorre il permesso di esecuzione per il medesimo, inoltre solo i file
regolari possono essere eseguiti.
-
La procedura con cui il kernel stabilisce se un processo possiede un certo
permesso (di lettura, scrittura o esecuzione) si basa sul confronto fra
l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e
\var{st\_gid} accennati in precedenza) e l'\textit{effective user id},
l'\textit{effective group id} e gli eventuali \textit{supplementary group id}
-del processo (per una spiegazione dettagliata degli ID dei processi si veda
-\secref{sec:prochand_perms}; normalmente, a parte quanto spiegato in
-\secref{sec:filedir_suid_sgid}, essi corrispondono all'uid e al gid
-dell'utente che ha lanciato il processo).
+del processo.
+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
+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.
% Quando un processo cerca l'accesso al file esso controlla i propri uid e gid
% confrontandoli con quelli del file e se l'operazione richiesta è compatibile
controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a
tutti i file.
\item Se l'\textit{effective user id} del processo è uguale all'uid del
- proprietario del file (che nel caso più comune significa che chi ha lanciato
- il processo è il proprietario del file) allora:
+ proprietario del file (nel qual caso si dice che il processo è proprietario
+ 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
\item altrimenti l'accesso è negato
\end{itemize}
\item Se l'\textit{effective group id} del processo o uno dei
- \textit{supplementary group id} dei processi.
+ \textit{supplementary group id} dei processi corrispondono al gid del file
+ allora:
+ \begin{itemize}
+ \item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è
+ consentito, altrimenti l'accesso è negato
+ \end{itemize}
+\item se il bit dei permessi d'accesso per tutti gli altri è settato,
+ l'accesso è consentito, altrimenti l'accesso è negato.
\end{itemize}
-questi passi vengono eseguiti in quest'ordine, qualora si abbia il permesso
-d'accesso la scansione viene terminata.
-\subsection{I flag \texttt{suid} e \texttt{sgid}}
+Si tenga presente che questi passi vengono eseguiti esattamente in
+quest'ordine. Questo vuol dire che se un processo è il proprietario di un file
+l'accesso è consentito o negato solo sulla base dei permessi per l'utente; i
+permessi per il gruppo non vengono neanche controllati; lo stesso vale se il
+processo appartiene ad un gruppo appropriato, in questo caso i permessi per
+tutti gli altri non vengono controllati.
+
+\subsection{I flag \textsl{suid} e \textsl{sgid}}
\label{sec:filedir_suid_sgid}
-\subsection{La titolarità di nuovi files e directory}
+Come si è accennato (in \secref{sec:filedir_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
+\textsl{suid} e \textsl{sgid}.
+
+Come spiegato in dettaglio in \secref{sec:prochand_exec}, quando si lancia un
+programma il comportamendo normale del kernel è quello di settare
+l'\textit{effective user id} e l'\textit{effective group id} del nuovo
+processo all'uid e al gid del processo corrente, che corrispondono dell'utente
+con cui si è entrati nel sistema.
+
+Se però il file del programma (che ovviamente deve essere eseguibile) ha il
+bit \textsl{suid} (o \textit{set-user-ID bit}) settato al posto dell'uid del
+processo originario il kernel assegnerà come \textit{effective user id} al
+nuovo processo l'uid del proprietario del file. Analogamente avere il bit
+\textsl{sgid} (o \textit{set-group-ID bit}) settato ha lo stesso effetto
+sull'\textit{effective group id}.
+
+I bit \textsl{suid} e \textsl{sgid} vengono usati per permettere agli utenti
+normali di usare programmi che abbisognano di privilegi speciali; l'esempio
+classico è il comando \cmd{passwd} che ha la necessità di modificare il file
+delle password, quest'ultimo ovviamente può essere scritto solo
+dall'amministratore, ma non è necessairo chiamare l'amministratore per
+cambiare la propria pasword. Infatti il comando \cmd{passwd} appartiene a root
+ma ha il suid bit settato per cui quando viene lanciato da un utente normale
+parte con i privilegi di root.
+
+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}).
+
+I due bit suid e sgid possono essere controllati all'interno di \var{st\_mode}
+con l'uso delle due costanti \macro{S\_ISUID} e \macro{S\_ISGID}, definite in
+\tabref{tab:filedir_file_mode_flags}. I file possono essere identificati con
+il comando \cmd{ls -l} in quanto presentano la lettera \cmd{s} al posto della
+\cmd{x} in corrispondenza dei permessi di utente o gruppo. La stessa lettera
+\cmd{s} può essere usata nel comando \cmd{chmod} per settare questi bit.
+
+Gli stessi bit vengono ad assumere in significato completamente diverso per le
+directory, in questo caso infatti linux usa la convezione di SVR4 per indicare
+con questi bit l'uso della semantica BSD nella creazione di nuovi file
+(si veda \secref{sec:filedir_ownership}).
+
+Infine il caso in cui il file abbia il bit \textsl{sgid} settato ma non il
+corrispondente bit per l'esecuzione viene utilizzato per attivare per quel
+file il \textit{mandatory locking} (argomento affrontato nei dettagli in
+\secref{sec:xxx_mandatory_lock}).
+
+
+\subsection{Il flag \texttt{sticky}}
+\label{sec:filedir_sticky}
+
+L'ultimo
+
+\subsection{La titolarità di nuovi file e directory}
\label{sec:filedir_ownership}
\subsection{Le funzioni \texttt{chmod} e \texttt{fchmod}}
\label{sec:filedir_chmod}
-\subsection{Il flag \texttt{sticky}}
-\label{sec:filedir_sticky}
-
\subsection{Le funzioni \texttt{chown}, \texttt{fchown} e \texttt{lchown}}
\label{sec:filedir_chown}
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 esaminanto in \secref{sec:filedir_access_control}.
+manipolazione sarà invece esaminato in \secref{sec:filedir_access_control}.
\subsection{Le funzioni \texttt{stat}, \texttt{fstat} e \texttt{lstat}}
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}.
-Dato che il valore numerico può variare a seconda delle implementazioni lo
+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,
-queste venfono usate anche da Linux che supporta pure le estensioni per link
-simbolici e socket definite da BDS, l'elenco è riportato in \ntab:
+queste vengono usate anche da Linux che supporta pure le estensioni per link
+simbolici e socket definite da BSD, l'elenco completo di tutte le macro
+definite in GNU/Linux è riportato in \ntab:
\begin{table}[htb]
\centering
\footnotesize
Macro & Tipo del file \\
\hline
\hline
- \macro{S\_ISREG(m)} & file normale \\
+ \macro{S\_ISREG(m)} & file regolare \\
\macro{S\_ISDIR(m)} & directory \\
\macro{S\_ISCHR(m)} & device a caraetteri \\
\macro{S\_ISBLK(m)} & device a blocchi\\
Flag & Valore & Significato \\
\hline
\hline
- \macro{S\_IFMT} & 0170000 & bitmask for the file type bitfields \\
- \macro{S\_IFSOCK} & 0140000 & socket \\
- \macro{S\_IFLNK} & 0120000 & symbolic link \\
- \macro{S\_IFREG} & 0100000 & regular file \\
- \macro{S\_IFBLK} & 0060000 & block device \\
- \macro{S\_IFDIR} & 0040000 & directory \\
- \macro{S\_IFCHR} & 0020000 & character device \\
- \macro{S\_IFIFO} & 0010000 & fifo \\
- \macro{S\_ISUID} & 0004000 & set UID bit \\
- \macro{S\_ISGID} & 0002000 & set GID bit (see below) \\
- \macro{S\_ISVTX} & 0001000 & sticky bit (see below) \\
- \macro{S\_IRWXU} & 00700 & mask for file owner permissions \\
- \macro{S\_IRUSR} & 00400 & owner has read permission \\
- \macro{S\_IWUSR} & 00200 & owner has write permission \\
- \macro{S\_IXUSR} & 00100 & owner has execute permission \\
- \macro{S\_IRWXG} & 00070 & mask for group permissions \\
- \macro{S\_IRGRP} & 00040 & group has read permission \\
- \macro{S\_IWGRP} & 00020 & group has write permission \\
- \macro{S\_IXGRP} & 00010 & group has execute permission \\
- \macro{S\_IRWXO} & 00007 & mask for permissions for others (not in
- group) \\
- \macro{S\_IROTH} & 00004 & others have read permission \\
- \macro{S\_IWOTH} & 00002 & others have write permisson \\
- \macro{S\_IXOTH} & 00001 & others have execute permission \\
+ \macro{S\_IFMT} & 0170000 & bitmask per i bit del tipo di file \\
+ \macro{S\_IFSOCK} & 0140000 & socket \\
+ \macro{S\_IFLNK} & 0120000 & link simbolico \\
+ \macro{S\_IFREG} & 0100000 & file regolare \\
+ \macro{S\_IFBLK} & 0060000 & device a blocchi \\
+ \macro{S\_IFDIR} & 0040000 & directory \\
+ \macro{S\_IFCHR} & 0020000 & device a caratteri \\
+ \macro{S\_IFIFO} & 0010000 & fifo \\
+ \hline
+ \macro{S\_ISUID} & 0004000 & set UID bit \\
+ \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\_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\_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\_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 \\
\hline
\end{tabular}
- \caption{Flag per il campo \var{st\_mode} (definite in
- \texttt{sys/stat.h})}
+ \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}
\end{table}
\subsection{La dimensione dei file}
\label{sec:filedir_file_size}
-Il membro \var{st\_size} contiene la dimensione del file in bytes (se il file
+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
pathname che contiene).
(valore specifico ritornato da linux che non consente l'uso di
\texttt{unlink} con le directory, e non conforme allo standard POSIX, che
prescrive invece l'uso di \texttt{EPERM} in caso l'operazione non sia
- consnetita o il processo non abbia privilegi sufficienti).
+ consentita o il processo non abbia privilegi sufficienti).
\item \texttt{EROFS} \var{pathname} è su un filesystem montato in sola
lettura.
\item \texttt{EISDIR} \var{pathname} fa riferimento a una directory.
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 files (trattati in dettaglio in
+ errore standard di accesso ai file (trattati in dettaglio in
\secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
\begin{errlist}
\item \texttt{EEXIST} Un file (o una directory) con quel nome esiste di
\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
-genere effttuata dalla funzione che restituisce il file descriptor
+genere effettuata dalla funzione che restituisce il file descriptor
(normalmente la \func{open}).
\begin{figure}[htb]
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 files (trattati in dettaglio in
+ di accesso ai file (trattati in dettaglio in
\secref{sec:filedir_access_control}) ai quali si aggiungono i seguenti:
\begin{errlist}
\item \texttt{EACCESS}
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 files (trattati in dettaglio in
+ errore standard di accesso ai file (trattati in dettaglio in
\secref{sec:filedir_access_control}) ai quali si aggiunge il codice
\texttt{ENOTDIR} nel caso il \texttt{filename} indichi un file che non sia
una directory.
projects / gapil.git / blobdiff