controllo di accesso ai file.
permessa: solo il proprietario del file o un processo con sufficienti
privilegi può eseguire l'operazione.
\item \errcode{ENOENT} \textit{No such file or directory}. Il file indicato
- dal \itindex{pathname}\textit{pathname} non esiste: o una delle
- componenti non esiste o il \textit{pathname} contiene un link simbolico
- spezzato. Errore tipico di un riferimento ad un file che si suppone
- erroneamente essere esistente.
+ dal \itindex{pathname} \textit{pathname} non esiste: o una delle componenti
+ non esiste o il \textit{pathname} contiene un link simbolico spezzato.
+ Errore tipico di un riferimento ad un file che si suppone erroneamente
+ essere esistente.
\item \errcode{EIO} \textit{Input/output error}. Errore di input/output: usato
per riportare errori hardware in lettura/scrittura su un dispositivo.
\item \errcode{ENXIO} \textit{No such device or address}. Dispositivo
scrivere, o viceversa, o si è cercato di eseguire un'operazione non
consentita per quel tipo di file descriptor.
\item \errcode{EACCES} \textit{Permission denied}. Permesso negato; l'accesso
- al file non è consentito: i permessi del file o della directory non
- consentono l'operazione.
+ al file o alla directory non è consentito: i permessi del file o della
+ directory non consentono l'operazione richiesta.
\item \errcode{ELOOP} \textit{Too many symbolic links encountered}. Ci sono
troppi link simbolici nella risoluzione di un
\itindex{pathname}\textit{pathname}.
\item \errcode{ENAMETOOLONG} \textit{File name too long}. Si è indicato un
- \itindex{pathname}\textit{pathname} troppo lungo.
+ \itindex{pathname} \textit{pathname} troppo lungo per un file o una
+ directory.
\item \errcode{ENOTBLK} \textit{Block device required}. Si è specificato un
file che non è un \textit{block device} in un contesto in cui era necessario
specificare un \textit{block device} (ad esempio si è tentato di montare un
\item \errcode{ENOTDIR} \textit{Not a directory}. Si è specificato un file che
non è una directory in una operazione che richiede una directory.
\item \errcode{EISDIR} \textit{Is a directory}. Il file specificato è una
- directory, non può essere aperto in scrittura, né si possono creare o
+ directory; non può essere aperto in scrittura, né si possono creare o
rimuovere link diretti ad essa.
\item \errcode{EMFILE} \textit{Too many open files}. Il processo corrente ha
- troppi file aperti e non può aprirne altri. Anche i descrittori duplicati
- vengono tenuti in conto\footnote{Il numero massimo di file aperti è
- controllabile dal sistema, in Linux si può usare il comando
- \cmd{ulimit}.}.
-\item \errcode{ENFILE} \textit{File table overflow}. Ci sono troppi file aperti
- nel sistema.
+ troppi file aperti e non può aprirne altri. Anche i descrittori duplicati ed
+ i socket vengono tenuti in conto.\footnote{il numero massimo di file aperti
+ è controllabile dal sistema; in Linux si può impostare usando il comando
+ \cmd{ulimit}, esso è in genere indicato dalla costante \const{OPEN\_MAX},
+ vedi sez.~\ref{sec:sys_limits}.}
+\item \errcode{ENFILE} \textit{File table overflow}. Il sistema ha troppi file
+ aperti in contemporanea. Si tenga presente che anche i socket contano come
+ file. Questa è una condizione temporanea, ed è molto difficile che si
+ verifichi nei sistemi moderni.
\item \errcode{ENOTTY} \textit{Not a terminal}. Si è tentata una operazione di
controllo relativa ad un terminale su un file che non lo è.
\item \errcode{ETXTBSY} \textit{Text file busy}. Si è cercato di eseguire un
- file che è aperto in scrittura, o scrivere un file che è in esecuzione.
+ file che è aperto in scrittura, o di scrivere su un file che è in
+ esecuzione.
\item \errcode{EFBIG} \textit{File too big}. Si è ecceduto il limite imposto
dal sistema sulla dimensione massima che un file può avere.
-\item \errcode{ENOSPC} \textit{No space left on device}. la directory in cui si
- vuole creare il link non ha spazio per ulteriori voci.
-\item \errcode{ESPIPE} \textit{Invalid seek operation}.
-\item \errcode{EROFS} \textit{Read-only file system}. il file risiede su un
- filesystem read-only.
-\item \errcode{EMLINK} \textit{Too many links}. Ci sono troppi link al file (il
- numero massimo è specificato dalla variabile \const{LINK\_MAX}, vedi
- sez.~\ref{sec:sys_limits}).
+\item \errcode{ENOSPC} \textit{No space left on device}. La directory in cui si
+ vuole creare il link non ha spazio per ulteriori voci, o si è cercato di
+ scrivere o di creare un nuovo file su un dispositivo che è già pieno.
+\item \errcode{ESPIPE} \textit{Invalid seek operation}. Si cercato di eseguire
+ una \func{seek} su un file che non supporta questa operazione (ad esempio su
+ una pipe).
+\item \errcode{EROFS} \textit{Read-only file system}. Si è cercato di
+ eseguire una operazione di scrittura su un file o una directory che risiede
+ su un filesystem montato un sola lettura.
+\item \errcode{EMLINK} \textit{Too many links}. Ci sono già troppi link al
+ file (il numero massimo è specificato dalla variabile \const{LINK\_MAX},
+ vedi sez.~\ref{sec:sys_limits}).
\item \errcode{EPIPE} \textit{Broken pipe}. Non c'è un processo che stia
leggendo l'altro capo della pipe. Ogni funzione che restituisce questo
errore genera anche un segnale \const{SIGPIPE}, la cui azione predefinita è
gestione dei processi.
\begin{description}
-\item \errcode{ESRCH} \textit{No process matches the specified process ID}. Non
- esiste un processo con il \acr{pid} specificato.
-\item \errcode{E2BIG} \textit{Argument list too long}. Lista degli argomenti
- troppo lunga: è una condizione prevista da POSIX quando la lista degli
- argomenti passata ad una delle funzioni \func{exec} occupa troppa memoria,
- non può mai accadere in GNU/Linux.
-\item \errcode{ECHILD} \textit{There are no child processes}. Non esiste un
- processo figlio. Viene rilevato dalle funzioni per la gestione dei processi
- figli.
+\item \errcode{ESRCH} \textit{No process matches the specified process ID}.
+ Non esiste un processo o un \itindex{process~group} \textit{process group}
+ corrispondenti al valore dell'identificativo specificato.
+\item \errcode{E2BIG} \textit{Argument list too long}. La lista degli
+ argomenti passati è troppo lunga: è una condizione prevista da POSIX quando
+ la lista degli argomenti passata ad una delle funzioni \func{exec} occupa
+ troppa memoria, non può mai accadere in GNU/Linux.
+\item \errcode{ECHILD} \textit{There are no child processes}. Non esistono
+ processi figli di cui attendere la terminazione. Viene rilevato dalle
+ funzioni \func{wait} e \func{waitpid}.
%\item \errcode{EPROCLIM} \textit{}. Il limite dell'utente per nuovi processi
% sarà ecceduto alla prossima \func{fork}. (non credo esista in Linux)
% TODO verificare EPROCLIM
\begin{description}
\item \errcode{EINTR} \textit{Interrupted function call}. Una funzione di
libreria è stata interrotta. In genere questo avviene causa di un segnale
- asincrono al processo che impedisce la conclusione della chiamata. In questo
- caso è necessario ripetere la chiamata alla funzione.
+ asincrono al processo che impedisce la conclusione della chiamata, la
+ funzione ritorna con questo errore una volta che si sia correttamente
+ eseguito il gestore del segnale. In questo caso è necessario ripetere la
+ chiamata alla funzione.
\item \errcode{ENOMEM} \textit{No memory available}. Il kernel non è in grado
di allocare ulteriore memoria per completare l'operazione richiesta.
\item \errcode{EDEADLK} \textit{Deadlock avoided}. L'allocazione di una
- risorsa avrebbe causato un \textit{deadlock}\itindex{deadlock}. Non sempre
+ risorsa avrebbe causato un \itindex{deadlock} \textit{deadlock}. Non sempre
il sistema è in grado di riconoscere queste situazioni, nel qual caso si
avrebbe il blocco.
-\item \errcode{EFAULT} \textit{Bad address}. Una stringa passata come argomento
- è fuori dello spazio di indirizzi del processo, in genere questa situazione
- provoca l'emissione di un segnale di \textit{segment violation}
- (\const{SIGSEGV}).
+\item \errcode{EFAULT} \textit{Bad address}. Una stringa passata come
+ argomento è fuori dello spazio di indirizzi del processo, in genere questa
+ situazione provoca direttamente l'emissione di un segnale di \textit{segment
+ violation} (\const{SIGSEGV}).
\item \errcode{EINVAL} \textit{Invalid argument}. Errore utilizzato per
segnalare vari tipi di problemi dovuti all'aver passato un argomento
sbagliato ad una funzione di libreria.
\item \errcode{EDOM} \textit{Domain error}. È usato dalle funzioni matematiche
- quando il valore di un argomento è al di fuori dell'intervallo in cui sono
- definite.
-\item \errcode{ERANGE} \textit{Range error}. È usato dalle funzioni matematiche
- quando il risultato non è rappresentabile a causa di un overflow o di un
- underflow.
+ quando il valore di un argomento è al di fuori dell'intervallo in cui esse
+ sono definite.
+\item \errcode{ERANGE} \textit{Range error}. È usato dalle funzioni
+ matematiche quando il risultato dell'operazione non è rappresentabile nel
+ valore di ritorno a causa di un overflow o di un underflow.
\item \errcode{EAGAIN} \textit{Resource temporarily unavailable}. La funzione è
fallita ma potrebbe funzionare se la chiamata fosse ripetuta. Questo errore
accade in due tipologie di situazioni:
specificato un valore non valido.
\end{description}
-
\begin{description}
+
+% definiti nel manuale delle glibc ma inesistenti in linux/errno.h
%\item \errcode{EBADRPC} \textit{}.
%\item \errcode{ERPCMISMATCH} \textit{}.
%\item \errcode{EPROGUNAVAIL} \textit{}.
%\item \errcode{ENEEDAUTH} \textit{}.
%\item \errcode{EBACKGROUND} \textit{}.
%\item \errcode{EDIED} \textit{}.
+% questi sembrano scherzi, sempre dal manuale delle glibc...
%\item \errcode{ED} \textit{}.
%\item \errcode{EGREGIOUS} \textit{}.
%\item \errcode{EIEIO} \textit{}.
%\item \errcode{EGRATUITOUS} \textit{}.
-\item \errcode{EBADMSG} \textit{Not a data message}.
+
+
+\item \errcode{EBADMSG} \textit{Not a data message}. Definito da Posix come
+errore che arriva ad una funzione di lettura che opera su uno stream. Non
+essendo gli stream definiti su Linux il kernel non genera mai questo tipo di
+messaggio.
+
+\item \errcode{EMULTIHOP} \textit{Multihop attempted}. Definito da Posix come
+ errore dovuto all'accesso a file remoti attraverso più macchine, quando ciò
+ non è consentito. Non viene mai generato su Linux.
+
\item \errcode{EIDRM} \textit{Identifier removed}. Indica che l'oggetto del
\textit{SysV IPC} cui si fa riferimento è stato cancellato.
-\item \errcode{EMULTIHOP} \textit{Multihop attempted}.
-\item \errcode{ENODATA} \textit{No data available}.
+
+\item \errcode{ENODATA} \textit{No data available}. Viene indicato da Posix
+ come restituito da una \func{read} eseguita su un file descriptor in
+ modalità non bloccante quando non ci sono dati. In realtà in questo caso
+ viene utilizzato \errcode{EAGAIN}. In Linux viene utilizzato quando dalle
+ funzioni per la gestione degli attributi estesi dei file quando il nome
+ dell'attributo richiesto non viene trovato.
+
+% TODO referenziare la trattazione degli attributi estesi dei file
+
\item \errcode{ENOLINK} \textit{Link has been severed}.
-\item \errcode{ENOMSG} \textit{No message of desired type}. Indica che una
+
+\item \errcode{ENOMSG} \textit{No message of desired type}. Indica che in una
coda di messaggi del \textit{SysV IPC} non è presente nessun messaggio del
tipo desiderato.
+
\item \errcode{ENOSR} \textit{Out of streams resources}.
+
\item \errcode{ENOSTR} \textit{Device not a stream}.
+
\item \errcode{EOVERFLOW} \textit{Value too large for defined data type}. Si è
chiesta la lettura di un dato dal \textit{SysV IPC} con \const{IPC\_STAT} ma
il valore eccede la dimensione usata nel buffer di lettura.
+
\item \errcode{EPROTO} \textit{Protocol error}. C'è stato un errore nel
protocollo di rete usato dal socket.
+
\item \errcode{ETIME} \textit{Timer expired}.
\end{description}
\itindex{self-pipe trick} \textit{self-pipe trick}, che consiste nell'aprire
una pipe (vedi sez.~\ref{sec:ipc_pipes}) ed usare \func{select} sul capo in
lettura della stessa, e indicare l'arrivo di un segnale scrivendo sul capo
- in scrittura all'interno del manipolatore; in questo modo anche se il
- segnale va perso prima della chiamata di \func{select} questa lo riconoscerà
- comunque dalla presenza di dati sulla pipe.} ribloccandolo non appena essa
-ritorna, così che il precedente codice potrebbe essere riscritto nel seguente
-modo:
+ in scrittura all'interno del gestore dello stesso; in questo modo anche se
+ il segnale va perso prima della chiamata di \func{select} questa lo
+ riconoscerà comunque dalla presenza di dati sulla pipe.} ribloccandolo non
+appena essa ritorna, così che il precedente codice potrebbe essere riscritto
+nel seguente modo:
\includecodesnip{listati/pselect_norace.c}
in questo caso utilizzando \var{oldmask} durante l'esecuzione di
\func{pselect} la ricezione del segnale sarà abilitata, ed in caso di
comando \const{F\_SETSIG} di \func{fcntl}.\footnote{anche in questo caso si
può rispecificare lo stesso \const{SIGIO}.} Se si è fatto questo\footnote{è
in genere è opportuno farlo, come in precedenza, per utilizzare segnali
- real-time.} e si è installato il manipolatore del segnale con
-\const{SA\_SIGINFO} si riceverà nel campo \var{si\_fd} della struttura
-\struct{siginfo\_t} il valore del file descriptor del file sul quale è stato
-compiuto l'accesso; in questo modo un processo può mantenere anche più di un
-\textit{file lease}.
+ real-time.} e si è installato il gestore del segnale con \const{SA\_SIGINFO}
+si riceverà nel campo \var{si\_fd} della struttura \struct{siginfo\_t} il
+valore del file descriptor del file sul quale è stato compiuto l'accesso; in
+questo modo un processo può mantenere anche più di un \textit{file lease}.
Esistono due tipi di \textit{file lease}: di lettura (\textit{read lease}) e
di scrittura (\textit{write lease}). Nel primo caso la notifica avviene quando
directory, o di uno qualunque dei file in essa contenuti, viene modificato.
Come per i \textit{file lease} la notifica avviene di default attraverso il
segnale \const{SIGIO}, ma questo può essere modificato e si può ottenere nel
-manipolatore il file descriptor che è stato modificato dal contenuto della
+gestore il file descriptor che è stato modificato dal contenuto della
struttura \struct{siginfo\_t}.
\index{file!lease|)}
Il valore dell'argomento \param{prot} indica la protezione\footnote{in Linux
la memoria reale è divisa in pagine: ogni processo vede la sua memoria
attraverso uno o più segmenti lineari di memoria virtuale. Per ciascuno di
- questi segmenti il kernel mantiene nella \itindex{page~table}\textit{page
+ questi segmenti il kernel mantiene nella \itindex{page~table} \textit{page
table} la mappatura sulle pagine di memoria reale, ed le modalità di
accesso (lettura, esecuzione, scrittura); una loro violazione causa quella
che si chiama una \textit{segment violation}, e la relativa emissione del
kernel secondo lo schema di fig.~\ref{fig:file_flock_struct}, associando ad
ogni nuovo \textit{file lock} un puntatore\footnote{il puntatore è mantenuto
nel campo \var{fl\_file} di \struct{file\_lock}, e viene utilizzato solo per
- i lock creati con la semantica BSD.} alla voce nella \textit{file table} da
-cui si è richiesto il lock, che così ne identifica il titolare.
+ i lock creati con la semantica BSD.} alla voce nella \itindex{file~table}
+\textit{file table} da cui si è richiesto il lock, che così ne identifica il
+titolare.
Questa struttura prevede che, quando si richiede la rimozione di un file lock,
il kernel acconsenta solo se la richiesta proviene da un file descriptor che
-fa riferimento ad una voce nella file table corrispondente a quella registrata
-nel lock. Allora se ricordiamo quanto visto in sez.~\ref{sec:file_dup} e
-sez.~\ref{sec:file_sharing}, e cioè che i file descriptor duplicati e quelli
-ereditati in un processo figlio puntano sempre alla stessa voce nella file
-table, si può capire immediatamente quali sono le conseguenze nei confronti
-delle funzioni \func{dup} e \func{fork}.
+fa riferimento ad una voce nella \itindex{file~table} \textit{file table}
+corrispondente a quella registrata nel lock. Allora se ricordiamo quanto
+visto in sez.~\ref{sec:file_dup} e sez.~\ref{sec:file_sharing}, e cioè che i
+file descriptor duplicati e quelli ereditati in un processo figlio puntano
+sempre alla stessa voce nella \itindex{file~table} \textit{file table}, si può
+capire immediatamente quali sono le conseguenze nei confronti delle funzioni
+\func{dup} e \func{fork}.
Sarà così possibile rimuovere un file lock attraverso uno qualunque dei file
-descriptor che fanno riferimento alla stessa voce nella file table, anche se
-questo è diverso da quello con cui lo si è creato,\footnote{attenzione, questo
- non vale se il file descriptor fa riferimento allo stesso file, ma
- attraverso una voce diversa della file table, come accade tutte le volte che
- si apre più volte lo stesso file.} o se si esegue la rimozione in un
-processo figlio; inoltre una volta tolto un file lock, la rimozione avrà
-effetto su tutti i file descriptor che condividono la stessa voce nella file
-table, e quindi, nel caso di file descriptor ereditati attraverso una
-\func{fork}, anche su processi diversi.
+descriptor che fanno riferimento alla stessa voce nella \itindex{file~table}
+\textit{file table}, anche se questo è diverso da quello con cui lo si è
+creato,\footnote{attenzione, questo non vale se il file descriptor fa
+ riferimento allo stesso file, ma attraverso una voce diversa della
+ \itindex{file~table} \textit{file table}, come accade tutte le volte che si
+ apre più volte lo stesso file.} o se si esegue la rimozione in un processo
+figlio; inoltre una volta tolto un file lock, la rimozione avrà effetto su
+tutti i file descriptor che condividono la stessa voce nella
+\itindex{file~table} \textit{file table}, e quindi, nel caso di file
+descriptor ereditati attraverso una \func{fork}, anche su processi diversi.
Infine, per evitare che la terminazione imprevista di un processo lasci attivi
dei file lock, quando un file viene chiuso il kernel provveda anche a
rimuovere tutti i lock ad esso associati. Anche in questo caso occorre tenere
presente cosa succede quando si hanno file descriptor duplicati; in tal caso
infatti il file non verrà effettivamente chiuso (ed il lock rimosso) fintanto
-che non viene rilasciata la relativa voce nella file table; e questo avverrà
-solo quando tutti i file descriptor che fanno riferimento alla stessa voce
-sono stati chiusi. Quindi, nel caso ci siano duplicati o processi figli che
-mantengono ancora aperto un file descriptor, il lock non viene rilasciato.
+che non viene rilasciata la relativa voce nella \itindex{file~table}
+\textit{file table}; e questo avverrà solo quando tutti i file descriptor che
+fanno riferimento alla stessa voce sono stati chiusi. Quindi, nel caso ci
+siano duplicati o processi figli che mantengono ancora aperto un file
+descriptor, il lock non viene rilasciato.
Si tenga presente infine che \func{flock} non è in grado di funzionare per i
file mantenuti su NFS, in questo caso, se si ha la necessità di eseguire il
impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene
usato.} il lock è sempre associato all'inode\index{inode}, solo che in
questo caso la titolarità non viene identificata con il riferimento ad una
-voce nella file table, ma con il valore del \acr{pid} del processo.
+voce nella \itindex{file~table} \textit{file table}, ma con il valore del
+\acr{pid} del processo.
Quando si richiede un lock il kernel effettua una scansione di tutti i lock
presenti sul file\footnote{scandisce cioè la \itindex{linked~list}
Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid}. Se si ricorda
-quanto esposto in sez.~\ref{sec:file_suid_sgid}), esso viene di norma
+quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
utilizzato per cambiare il group-ID effettivo con cui viene eseguito un
programma, ed è pertanto sempre associato alla presenza del permesso di
esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
combinazione dei permessi originariamente non contemplata, in quanto senza
significato, diventa l'indicazione della presenza o meno del \textit{mandatory
locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
- sez.~\ref{sec:file_chmod} e cioè che il bit \acr{sgid} viene cancellato
- (come misura di sicurezza) quando di scrive su un file, questo non vale
- quando esso viene utilizzato per attivare il \textit{mandatory locking}.}
+ sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
+ cancellato (come misura di sicurezza) quando di scrive su un file, questo
+ non vale quando esso viene utilizzato per attivare il \textit{mandatory
+ locking}.}
L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
neanche l'amministratore può passare sopra ad un lock; pertanto un processo
scrittura su di essa, dato che si va a rimuovere una voce dal suo contenuto, e
il diritto di esecuzione sulla directory che la contiene (affronteremo in
dettaglio l'argomento dei permessi di file e directory in
-sez.~\ref{sec:file_access_control}). Se inoltre lo
-\itindex{sticky~bit}\textit{sticky bit} (vedi sez.~\ref{sec:file_sticky}) è
-impostato occorrerà anche essere proprietari del file o proprietari della
-directory (o root, per cui nessuna delle restrizioni è applicata).
+sez.~\ref{sec:file_access_control}). Se inoltre lo \itindex{sticky~bit}
+\textit{sticky bit} (vedi sez.~\ref{sec:file_special_perm}) è impostato
+occorrerà anche essere proprietari del file o proprietari della directory (o
+root, per cui nessuna delle restrizioni è applicata).
Una delle caratteristiche di queste funzioni è che la creazione/rimozione del
nome dalla directory e l'incremento/decremento del numero di riferimenti
I permessi di accesso alla directory (vedi sez.~\ref{sec:file_access_control})
sono specificati da \param{mode}, i cui possibili valori sono riportati in
tab.~\ref{tab:file_permission_const}; questi sono modificati dalla maschera di
-creazione dei file (si veda sez.~\ref{sec:file_umask}). La titolarità della
-nuova directory è impostata secondo quanto riportato in
-sez.~\ref{sec:file_ownership}.
+creazione dei file (si veda sez.~\ref{sec:file_perm_management}). La
+titolarità della nuova directory è impostata secondo quanto riportato in
+sez.~\ref{sec:file_ownership_management}.
La funzione per la cancellazione di una directory è \funcd{rmdir}, il suo
prototipo è:
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_umask}).
+\var{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
I nuovi inode\index{inode} creati con \func{mknod} apparterranno al
proprietario e al gruppo del processo che li ha creati, a meno che non si sia
attivato il bit \acr{sgid} per la directory o sia stata attivata la semantica
-BSD per il filesystem (si veda sez.~\ref{sec:file_ownership}) in cui si va a
-creare l'inode\index{inode}.
+BSD per il filesystem (si veda sez.~\ref{sec:file_ownership_management}) in
+cui si va a creare l'inode\index{inode}.
Per creare una fifo (un file speciale, su cui torneremo in dettaglio in
sez.~\ref{sec:ipc_named_pipe}) lo standard POSIX specifica l'uso della funzione
\begin{itemize*}
\item La variabile di ambiente \const{TMPNAME} (non ha effetto se non è
definita o se il programma chiamante è \itindex{suid~bit} \acr{suid} o
- \itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_suid_sgid}).
+ \itindex{sgid~bit} \acr{sgid}, vedi sez.~\ref{sec:file_special_perm}).
\item il valore dell'argomento \param{dir} (se diverso da \val{NULL}).
\item Il valore della costante \const{P\_tmpdir}.
\item la directory \file{/tmp}.
sez.~\ref{sec:file_access_control}).
-\subsection{Le funzioni \func{stat}, \func{fstat} e \func{lstat}}
+\subsection{La lettura delle caratteristiche dei file}
\label{sec:file_stat}
La lettura delle informazioni relative ai file è fatta attraverso la famiglia
delle funzioni \func{stat} (\funcd{stat}, \funcd{fstat} e \funcd{lstat});
questa è la funzione che ad esempio usa il comando \cmd{ls} per poter ottenere
-e mostrare tutti i dati dei file. I prototipi di queste funzioni sono i
-seguenti:
+e mostrare tutti i dati relativi a un file. I prototipi di queste funzioni
+sono i seguenti:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/stat.h}
Come riportato in tab.~\ref{tab:file_file_types} in Linux oltre ai file e alle
directory esistono altri oggetti che possono stare su un filesystem. Il tipo
-di file è ritornato dalla \func{stat} come maschera binaria nel campo
-\var{st\_mode} (che contiene anche le informazioni relative ai permessi).
+di file è ritornato dalla funzione \func{stat} come maschera binaria nel campo
+\var{st\_mode} (che contiene anche le informazioni relative ai permessi) di
+una struttura \struct{stat}.
Dato che il valore numerico può variare a seconda delle implementazioni, lo
standard POSIX definisce un insieme di macro per verificare il tipo di file,
\subsection{Le dimensioni dei file}
\label{sec:file_file_size}
-Il campo \var{st\_size} contiene la dimensione del file in byte (se si tratta
-di un file regolare, nel caso di un link simbolico la dimensione è quella del
-\itindex{pathname}\textit{pathname} che contiene, per le fifo è sempre nullo).
+Il campo \var{st\_size} di una struttura \struct{stat} contiene la dimensione
+del file in byte, se si tratta di un file regolare. Nel caso di un link
+simbolico la dimensione è quella del \itindex{pathname} \textit{pathname} che
+il link stesso contiene; per le fifo questo campo è sempre nullo.
Il campo \var{st\_blocks} definisce la lunghezza del file in blocchi di 512
byte. Il campo \var{st\_blksize} infine definisce la dimensione preferita per
secondo ad una modifica dell'inode\index{inode}; siccome esistono molte
operazioni (come la funzione \func{link} e molte altre che vedremo in seguito)
che modificano solo le informazioni contenute nell'inode\index{inode} senza
-toccare il file, diventa necessario l'utilizzo di un altro tempo.
+toccare il contenuto del file, diventa necessario l'utilizzo di un altro
+tempo.
-Il sistema non tiene conto dell'ultimo accesso all'inode\index{inode},
+Il sistema non tiene conto dell'ultimo accesso \index{inode} all'inode,
pertanto funzioni come \func{access} o \func{stat} non hanno alcuna influenza
sui tre tempi. Il tempo di ultimo accesso (ai dati) viene di solito usato per
cancellare i file che non servono più dopo un certo lasso di tempo (ad esempio
-\cmd{leafnode} cancella i vecchi articoli sulla base di questo tempo).
+il programma \cmd{leafnode} cancella i vecchi articoli sulla base di questo
+tempo).
Il tempo di ultima modifica invece viene usato da \cmd{make} per decidere
quali file necessitano di essere ricompilati o (talvolta insieme anche al
esplicitamente i tempi (ad esempio con l'opzione \cmd{-p} di \cmd{cp}) esso
avrà sempre il tempo corrente come data di ultima modifica.
-
-\subsection{La funzione \func{utime}}
-\label{sec:file_utime}
-
I tempi di ultimo accesso e modifica possono essere cambiati usando la
funzione \funcd{utime}, il cui prototipo è:
\begin{prototype}{utime.h}
\label{fig:file_perm_bit}
\end{figure}
-I restanti tre bit (noti come \itindex{suid~bit}\textit{suid bit},
-\itindex{sgid~bit}\textit{sgid bit}, e \itindex{sticky~bit} \textit{sticky
+I restanti tre bit (noti come \itindex{suid~bit} \textit{suid bit},
+\itindex{sgid~bit} \textit{sgid bit}, e \itindex{sticky~bit} \textit{sticky
bit}) sono usati per indicare alcune caratteristiche più complesse del
meccanismo del controllo di accesso su cui torneremo in seguito (in
-sez.~\ref{sec:file_suid_sgid} e sez.~\ref{sec:file_sticky}); lo schema di
-allocazione dei bit è riportato in fig.~\ref{fig:file_perm_bit}.
+sez.~\ref{sec:file_special_perm}); lo schema di allocazione dei bit è
+riportato in fig.~\ref{fig:file_perm_bit}.
Anche i permessi, come tutte le altre informazioni pertinenti al file, sono
memorizzati nell'inode\index{inode}; in particolare essi sono contenuti in
appartiene vengono pure ignorati quando il link viene risolto, vengono
controllati solo quando viene richiesta la rimozione del link e quest'ultimo è
in una directory con lo \itindex{sticky~bit} \textit{sticky bit} impostato (si
-veda sez.~\ref{sec:file_sticky}).
+veda sez.~\ref{sec:file_special_perm}).
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 sez.~\ref{sec:proc_perms}; normalmente, a parte quanto vedremo in
-sez.~\ref{sec:file_suid_sgid}, l'user-ID effettivo e il group-ID effettivo
+sez.~\ref{sec:file_special_perm}, l'user-ID effettivo e il group-ID effettivo
corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha
lanciato il processo, mentre i group-ID supplementari sono quelli dei gruppi
cui l'utente appartiene.
tutti gli altri non vengono controllati.
-\subsection{I bit \acr{suid} e \acr{sgid}}
-\label{sec:file_suid_sgid}
+\subsection{I bit dei permessi speciali}
+\label{sec:file_special_perm}
\itindbeg{suid~bit}
\itindbeg{sgid~bit}
Gli stessi bit vengono ad assumere in significato completamente diverso per le
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 sez.~\ref{sec:file_ownership} per una spiegazione dettagliata al
-proposito).
+veda sez.~\ref{sec:file_ownership_management} per una spiegazione dettagliata
+al proposito).
Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione mutuata
da SVr4. Il caso in cui un file ha il bit \acr{sgid} impostato senza che lo
\itindend{suid~bit}
\itindend{sgid~bit}
-\subsection{Il bit \textsl{sticky}}
-\label{sec:file_sticky}
\itindbeg{sticky~bit}
drwxrwxrwt 6 root root 1024 Aug 10 01:03 /tmp
\end{verbatim}%$
quindi con lo \textit{sticky bit} bit impostato. In questo modo qualunque
-utente nel sistema può creare dei file in questa directory (che, come
+utente nel sistema può c reare dei file in questa directory (che, come
suggerisce il nome, è normalmente utilizzata per la creazione di file
temporanei), ma solo l'utente che ha creato un certo file potrà cancellarlo o
rinominarlo. In questo modo si evita che un utente possa, più o meno
\itindend{sticky~bit}
-
-\subsection{La titolarità di nuovi file e directory}
-\label{sec:file_ownership}
-
-Vedremo in sez.~\ref{sec:file_base_func} con quali funzioni si possono creare
-nuovi file, in tale occasione vedremo che è possibile specificare in sede di
-creazione quali permessi applicare ad un file, però non si può indicare a
-quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta
-per la creazione di nuove directory (procedimento descritto in
-sez.~\ref{sec:file_dir_creat_rem}).
-
-Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
-all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede
-due diverse possibilità:
-\begin{itemize*}
-\item il \acr{gid} del file corrisponde al group-ID effettivo del processo.
-\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
- esso è creato.
-\end{itemize*}
-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
-\acr{gid} del processo, se però la directory in cui viene creato il file ha il
-bit \acr{sgid} impostato allora viene usata la seconda opzione.
-
-Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
-automaticamente propagato, restando coerente a quello della directory di
-partenza, in tutte le sotto-directory.
-
-La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
-risultato di coerenza che si ha con BSD necessita che per le nuove directory
-venga anche propagato anche il bit \acr{sgid}. Questo è il comportamento
-predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che Debian
-assicura che le sotto-directory create nella home di un utente restino sempre
-con il \acr{gid} del gruppo primario dello stesso.
-
-
-\subsection{La funzione \func{access}}
-\label{sec:file_access}
+\subsection{Le funzioni per la gestione dei permessi dei file}
+\label{sec:file_perm_management}
Come visto in sez.~\ref{sec:file_access_control} il controllo di accesso ad un
file viene fatto utilizzando l'user-ID ed il group-ID effettivo del processo;
ci sono casi però in cui si può voler effettuare il controllo con l'user-ID
reale ed il group-ID reale, vale a dire usando i valori di \acr{uid} e
\acr{gid} relativi all'utente che ha lanciato il programma, e che, come
-accennato in sez.~\ref{sec:file_suid_sgid} e spiegato in dettaglio in
+accennato in sez.~\ref{sec:file_special_perm} e spiegato in dettaglio in
sez.~\ref{sec:proc_perms}, non è detto siano uguali a quelli effettivi.
Per far questo si può usare la funzione \funcd{access}, il cui prototipo è:
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.
-
-\subsection{Le funzioni \func{chmod} e \func{fchmod}}
-\label{sec:file_chmod}
-
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:
\textit{sticky bit}, se l'user-ID effettivo del processo non è zero esso
viene automaticamente cancellato (senza notifica di errore) qualora sia
stato indicato in \param{mode}.
-\item per quanto detto in sez.~\ref{sec:file_ownership} riguardo la 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 \itindex{sgid~bit} \acr{sgid} ad un file
- appartenente a un gruppo per cui non si hanno diritti, questo viene
+\item per quanto detto in sez.~\ref{sec:file_ownership_management} riguardo la
+ 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 \itindex{sgid~bit} \acr{sgid} ad
+ un file appartenente a un gruppo per cui non si hanno diritti, questo viene
automaticamente cancellato da \param{mode} (senza notifica di errore)
qualora il gruppo del file non corrisponda a quelli associati al processo
(la cosa non avviene quando l'user-ID effettivo del processo è zero).
\end{enumerate}
Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
- \textsl{ext3}, \textsl{reiser}) supportano questa caratteristica, che è
+ \textsl{ext3}, \textsl{reiserfs}) supportano questa caratteristica, che è
mutuata da BSD.} è inoltre prevista una ulteriore misura di sicurezza, volta
a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa
consiste nel cancellare automaticamente questi bit dai permessi di un file
utente malizioso scopre un file \acr{suid} su cui può scrivere, un'eventuale
modifica comporterà la perdita di questo privilegio.
-\subsection{La funzione \func{umask}}
-\label{sec:file_umask}
-
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
quando il file viene creato. Le funzioni dell'interfaccia nativa di Unix, come
$022$, e gli utenti non hanno motivi per modificarlo.
-\subsection{Le funzioni \func{chown}, \func{fchown} e \func{lchown}}
-\label{sec:file_chown}
+
+\subsection{La gestione della titolarità dei file}
+\label{sec:file_ownership_management}
+
+Vedremo in sez.~\ref{sec:file_base_func} con quali funzioni si possono creare
+nuovi file, in tale occasione vedremo che è possibile specificare in sede di
+creazione quali permessi applicare ad un file, però non si può indicare a
+quale utente e gruppo esso deve appartenere. Lo stesso problema si presenta
+per la creazione di nuove directory (procedimento descritto in
+sez.~\ref{sec:file_dir_creat_rem}).
+
+Lo standard POSIX prescrive che l'\acr{uid} del nuovo file corrisponda
+all'user-ID effettivo del processo che lo crea; per il \acr{gid} invece prevede
+due diverse possibilità:
+\begin{itemize*}
+\item il \acr{gid} del file corrisponde al group-ID effettivo del processo.
+\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui
+ esso è creato.
+\end{itemize*}
+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
+\acr{gid} del processo, se però la directory in cui viene creato il file ha il
+bit \acr{sgid} impostato allora viene usata la seconda opzione.
+
+Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
+automaticamente propagato, restando coerente a quello della directory di
+partenza, in tutte le sotto-directory.
+
+La semantica SVr4 offre la possibilità di scegliere, ma per ottenere lo stesso
+risultato di coerenza che si ha con BSD necessita che per le nuove directory
+venga anche propagato anche il bit \acr{sgid}. Questo è il comportamento
+predefinito del comando \cmd{mkdir}, ed è in questo modo ad esempio che Debian
+assicura che le sotto-directory create nella home di un utente restino sempre
+con il \acr{gid} del gruppo primario dello stesso.
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
riferimento soltanto alla combinazione di bit per i quali il valore è
riportato esplicitamente.
+% TODO intrudurre nuova sezione sulle funzionalità di sicurezza avanzate, con
+% dentro chroot, gli attributi estesi, ecc.
\subsection{La funzione \func{chroot}}
\label{sec:file_chroot}
file non viene duplicato e verrà chiuso alla chiusura dello stream.
I nuovi file saranno creati secondo quanto visto in
-sez.~\ref{sec:file_ownership} ed avranno i permessi di accesso impostati al
-valore \code{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH} (pari a
+sez.~\ref{sec:file_ownership_management} ed avranno i permessi di accesso
+impostati al valore
+\code{S\_IRUSR|S\_IWUSR|S\_IRGRP|S\_IWGRP|S\_IROTH|S\_IWOTH} (pari a
\val{0666}) modificato secondo il valore di \acr{umask} per il processo (si
-veda sez.~\ref{sec:file_umask}).
+veda sez.~\ref{sec:file_perm_management}).
In caso di file aperti in lettura e scrittura occorre ricordarsi che c'è
di mezzo una bufferizzazione; per questo motivo lo standard ANSI C
Per capire come funziona il meccanismo occorre spiegare a grandi linee come il
kernel gestisce l'interazione fra processi e file. Il kernel mantiene sempre
un elenco dei processi attivi nella cosiddetta \itindex{process~table}
-\textit{process table} ed un elenco dei file aperti nella \textit{file table}.
+\textit{process table} ed un elenco dei file aperti nella
+\itindex{file~table} \textit{file table}.
La \itindex{process~table} \textit{process table} è una tabella che contiene
una voce per ciascun processo attivo nel sistema. In Linux ciascuna voce è
\item i flag relativi ai file descriptor.
\item il numero di file aperti.
\item una tabella che contiene un puntatore alla relativa voce nella
- \textit{file table} per ogni file aperto.
+ \itindex{file~table} \textit{file table} per ogni file aperto.
\end{itemize*}
il \textit{file descriptor} in sostanza è l'intero positivo che indicizza
quest'ultima tabella.
-La \textit{file table} è una tabella che contiene una voce per ciascun file
-che è stato aperto nel sistema. In Linux è costituita da strutture di tipo
-\struct{file}; in ciascuna di esse sono tenute varie informazioni relative al
-file, fra cui:
+La \itindex{file~table} \textit{file table} è una tabella che contiene una
+voce per ciascun file che è stato aperto nel sistema. In Linux è costituita da
+strutture di tipo \struct{file}; in ciascuna di esse sono tenute varie
+informazioni relative al file, fra cui:
\begin{itemize*}
\item lo stato del file (nel campo \var{f\_flags}).
\item il valore della posizione corrente (l'\textit{offset}) nel file (nel
La funzione apre il file usando il primo file descriptor libero, e crea
-l'opportuna voce, cioè la struttura \struct{file}, nella \textit{file table}
-del processo. Viene sempre restituito come valore di ritorno il file
-descriptor con il valore più basso disponibile.
+l'opportuna voce, cioè la struttura \struct{file}, nella \itindex{file~table}
+\textit{file table} del processo. Viene sempre restituito come valore di
+ritorno il file descriptor con il valore più basso disponibile.
\footnotetext[2]{la pagina di manuale di \func{open} segnala che questa
opzione è difettosa su NFS, e che i programmi che la usano per stabilire un
\hline
\const{O\_CREAT} & Se il file non esiste verrà creato, con le regole di
titolarità del file viste in
- sez.~\ref{sec:file_ownership}. Con questa opzione
- l'argomento \param{mode} deve essere specificato. \\
+ sez.~\ref{sec:file_ownership_management}. Con questa
+ opzione l'argomento \param{mode} deve essere
+ specificato. \\
\const{O\_EXCL} & Usato in congiunzione con \const{O\_CREAT} fa sì che
la precedente esistenza del file diventi un
errore\protect\footnotemark\ che fa fallire
valori possibili sono gli stessi già visti in sez.~\ref{sec:file_perm_overview}
e possono essere specificati come OR binario delle costanti descritte in
tab.~\ref{tab:file_bit_perm}. Questi permessi sono filtrati dal valore di
-\var{umask} (vedi sez.~\ref{sec:file_umask}) per il processo.
+\var{umask} (vedi sez.~\ref{sec:file_perm_management}) per il processo.
La funzione prevede diverse opzioni, che vengono specificate usando vari bit
dell'argomento \param{flags}. Alcuni di questi bit vanno anche a costituire
\index{file!locking} è trattato in sez.~\ref{sec:file_locking}) che il
processo poteva avere acquisito su di esso; se \param{fd} è l'ultimo
riferimento (di eventuali copie) ad un file aperto, tutte le risorse nella
-file table vengono rilasciate. Infine se il file descriptor era l'ultimo
-riferimento ad un file su disco quest'ultimo viene cancellato.
+\itindex{file~table} \textit{file table} vengono rilasciate. Infine se il file
+descriptor era l'ultimo riferimento ad un file su disco quest'ultimo viene
+cancellato.
Si ricordi che quando un processo termina anche tutti i suoi file descriptor
vengono chiusi, molti programmi sfruttano questa caratteristica e non usano
passi elencati non comporta il fallimento dell'accesso. Un'ulteriore
differenza rispetto a quanto avviene per i file è che per gli oggetti di IPC
il valore di \var{umask} (si ricordi quanto esposto in
-sez.~\ref{sec:file_umask}) non ha alcun significato.
+sez.~\ref{sec:file_perm_management}) non ha alcun significato.
\subsection{Gli identificatori ed il loro utilizzo}
la caratteristica di duplicare nei figli tutti i file descriptor aperti nel
padre (allo stesso modo in cui lo fa la funzione \func{dup}, trattata in
sez.~\ref{sec:file_dup}), il che comporta che padre e figli condividono le
-stesse voci della \textit{file table} (per la spiegazione di questi termini si
-veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la posizione corrente nel
-file.
+stesse voci della \itindex{file~table} \textit{file table} (per la spiegazione
+di questi termini si veda sez.~\ref{sec:file_sharing}) fra cui c'è anche la
+posizione corrente nel file.
In questo modo se un processo scrive sul file aggiornerà la posizione corrente
-sulla \textit{file table}, e tutti gli altri processi, che vedono la stessa
-\textit{file table}, vedranno il nuovo valore. In questo modo si evita, in
-casi come quello appena mostrato in cui diversi processi scrivono sullo stesso
-file, che l'output successivo di un processo vada a sovrapporsi a quello dei
-precedenti: l'output potrà risultare mescolato, ma non ci saranno parti
-perdute per via di una sovrascrittura.
+sulla \itindex{file~table} \textit{file table}, e tutti gli altri processi,
+che vedono la stessa \itindex{file~table} \textit{file table}, vedranno il
+nuovo valore. In questo modo si evita, in casi come quello appena mostrato in
+cui diversi processi scrivono sullo stesso file, che l'output successivo di un
+processo vada a sovrapporsi a quello dei precedenti: l'output potrà risultare
+mescolato, ma non ci saranno parti perdute per via di una sovrascrittura.
Questo tipo di comportamento è essenziale in tutti quei casi in cui il padre
crea un figlio e attende la sua conclusione per proseguire, ed entrambi
sez.~\ref{sec:sess_proc_group});
\item la directory di lavoro e la directory radice (vedi
sez.~\ref{sec:file_work_dir} e sez.~\ref{sec:file_chroot});
-\item la maschera dei permessi di creazione (vedi sez.~\ref{sec:file_umask});
+\item la maschera dei permessi di creazione (vedi
+ sez.~\ref{sec:file_perm_managemen});
\item la maschera dei segnali bloccati (vedi sez.~\ref{sec:sig_sigmask}) e le
azioni installate (vedi sez.~\ref{sec:sig_gen_beha});
\item i segmenti di memoria condivisa agganciati al processo (vedi
\item la directory radice e la directory di lavoro corrente (vedi
sez.~\ref{sec:file_work_dir});
\item la maschera di creazione dei file (\var{umask}, vedi
- sez.~\ref{sec:file_umask}) ed i \textit{lock} sui file (vedi
+ sez.~\ref{sec:file_perm_management}) ed i \textit{lock} sui file (vedi
sez.~\ref{sec:file_locking});
\item i segnali sospesi (\textit{pending}) e la maschera dei segnali (si veda
sez.~\ref{sec:sig_sigmask});
sez.~\ref{sec:proc_exec}, il programma che si è posto in esecuzione abbia i
bit \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid} impostati
(il significato di questi bit è affrontato in dettaglio in
-sez.~\ref{sec:file_suid_sgid}). In questo caso essi saranno impostati
+sez.~\ref{sec:file_special_perm}). In questo caso essi saranno impostati
all'utente e al gruppo proprietari del file. Questo consente, per programmi in
cui ci sia necessità, di dare a qualunque utente normale privilegi o permessi
di un altro (o dell'amministratore).
Come accennato l'uso principale di queste funzioni è quello di poter
consentire ad un programma con i bit \itindex{suid~bit} \acr{suid} o
-\itindex{sgid~bit} \acr{sgid} impostati (vedi sez.~\ref{sec:file_suid_sgid})
+\itindex{sgid~bit} \acr{sgid} impostati (vedi sez.~\ref{sec:file_special_perm})
di riportare l'\textsl{user-ID effettivo} a quello dell'utente che ha lanciato
il programma, effettuare il lavoro che non necessita di privilegi aggiuntivi,
ed eventualmente tornare indietro.
%
\const{CAP\_CHOWN} & la capacità di cambiare proprietario e gruppo
proprietario di un file (vedi
- sez.~\ref{sec:file_chown}).\\
+ sez.~\ref{sec:file_ownership_management}).\\
\const{CAP\_DAC\_OVERRIDE}& la capacità di evitare il controllo dei
permessi di lettura, scrittura ed esecuzione dei
file, (vedi sez.~\ref{sec:file_access_control})
precedenti \const{CAP\_DAC\_OVERRIDE} e
\const{CAP\_DAC\_READ\_SEARCH}. Queste
comprendono i cambiamenti dei permessi e dei
- tempi del file (vedi sez.~\ref{sec:file_chmod} e
- sez.~\ref{sec:file_utime}), le impostazioni degli
- attributi estesi (con il comando \cmd{chattr}) e
- delle ACL, poter ignorare lo
+ tempi del file (vedi
+ sez.~\ref{sec:file_perm_management} e
+ sez.~\ref{sec:file_file_times}), le impostazioni
+ degli attributi estesi (con il comando
+ \cmd{chattr}) e delle ACL, poter ignorare lo
\itindex{sticky~bit} \textit{sticky bit} nella
cancellazione dei file (vedi
- sez.~\ref{sec:file_sticky}), la possibilità di
- impostare il flag di \const{O\_NOATIME} con
+ sez.~\ref{sec:file_special_perm}), la possibilità
+ di impostare il flag di \const{O\_NOATIME} con
\func{open} e \func{fcntl} (vedi
sez.~\ref{sec:file_open} e
sez.~\ref{sec:file_fcntl}).\\
un processo senza questa capacità e la capacità
di impostare il bit \acr{sgid} su un file anche
quando questo è relativo ad un gruppo cui non si
- appartiene (vedi sez.~\ref{sec:file_chmod}).\\
+ appartiene (vedi
+ sez.~\ref{sec:file_perm_management}).\\
\const{CAP\_KILL} & la capacità di mandare segnali a qualunque
processo (vedi sez.~\ref{sec:sig_kill_raise}).\\
\const{CAP\_SETGID} & la capacità di manipolare i group ID dei
varie funzioni di libreria, che sono identificate aggiungendo il suffisso
\code{\_r} al nome della versione normale.
-
-%%% Local Variables:
-%%% mode: latex
-%%% TeX-master: "gapil"
-%%% End:
-
% LocalWords: multitasking like VMS child process identifier pid sez shell fig
% LocalWords: parent kernel init pstree keventd kswapd table struct linux call
% LocalWords: nell'header scheduler system interrupt timer HZ asm Hertz clock
% LocalWords: get ncap caps CapInh CapPrm fffffeff CapEff getcap STAT dall'I
% LocalWords: inc PRIO SUSv PRGR prio SysV SunOS Ultrix sched timespec len sig
% LocalWords: cpusetsize cpuset atomic
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End:
a zero (con l'eccezione dei \textit{raw socket}).
Si noti che la creazione del socket si limita ad allocare le opportune
-strutture nel kernel (sostanzialmente una voce nella \textit{file table}) e
-non comporta nulla riguardo all'indicazione degli indirizzi remoti o locali
-attraverso i quali si vuole effettuare la comunicazione.
+strutture nel kernel (sostanzialmente una voce nella \itindex{file~table}
+\textit{file table}) e non comporta nulla riguardo all'indicazione degli
+indirizzi remoti o locali attraverso i quali si vuole effettuare la
+comunicazione.
\subsection{Il dominio dei socket}
\label{sec:sock_domain}
projects / gapil.git / commitdiff