From: Simone Piccardi Date: Sun, 17 Sep 2006 00:20:34 +0000 (+0000) Subject: Correzioni agli errori, indicizzazioni e riorganizzata la sezione sul X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=7281907d38ca9d916bff5a3579c61d805a33c71d;p=gapil.git Correzioni agli errori, indicizzazioni e riorganizzata la sezione sul controllo di accesso ai file. --- diff --git a/errors.tex b/errors.tex index 885c94a..ab119c8 100644 --- a/errors.tex +++ b/errors.tex @@ -39,10 +39,10 @@ gestione dei 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 @@ -57,13 +57,14 @@ gestione dei file. 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 @@ -80,29 +81,37 @@ gestione dei file. \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 è @@ -142,15 +151,16 @@ attinenti ad errori che riguardano operazioni specifiche relative alla 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 @@ -255,27 +265,29 @@ specificati nelle sezioni precedenti. \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: @@ -322,8 +334,9 @@ specificati nelle sezioni precedenti. 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{}. @@ -333,26 +346,51 @@ specificati nelle sezioni precedenti. %\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} diff --git a/fileadv.tex b/fileadv.tex index 5717640..75f299f 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -300,11 +300,11 @@ contestualmente all'esecuzione della funzione,\footnote{in Linux per \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 @@ -597,11 +597,10 @@ il segnale \const{SIGIO}, ma questo segnale pu 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 @@ -703,7 +702,7 @@ chiamata \textit{dnotify}, che consente di richiedere una notifica quando una 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|)} @@ -1342,7 +1341,7 @@ multiplo della dimensione di una pagina di memoria. 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 @@ -2073,38 +2072,42 @@ piuttosto degli ulteriori riferimenti allo stesso. Questo viene realizzato dal 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 @@ -2296,7 +2299,8 @@ di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si 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} @@ -2626,7 +2630,7 @@ opportune verifiche nei processi, questo verrebbe comunque rispettato. 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 @@ -2635,9 +2639,10 @@ quest'ultimo venga attivato per il file in questione. In questo modo una 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 diff --git a/filedir.tex b/filedir.tex index ed7c7bc..67476c9 100644 --- a/filedir.tex +++ b/filedir.tex @@ -163,10 +163,10 @@ Per cancellare una voce in una directory 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 @@ -527,9 +527,9 @@ standard (\file{.} e \file{..}), con il nome indicato dall'argomento 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 è: @@ -611,7 +611,7 @@ creare file regolari e fifo; l'argomento \param{mode} specifica il tipo di 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 @@ -629,8 +629,8 @@ agli utenti normali. 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 @@ -1210,7 +1210,7 @@ la prima valida delle seguenti: \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}. @@ -1336,14 +1336,14 @@ gestione del controllo di accesso, trattate in in 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} @@ -1398,8 +1398,9 @@ tab.~\ref{tab:intro_primitive_types}, e dichiarati in \file{sys/types.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, @@ -1493,9 +1494,10 @@ poi si effettua il confronto con la combinazione di tipi scelta. \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 @@ -1600,13 +1602,15 @@ infatti fa riferimento ad una modifica del contenuto di un file, mentre il 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 @@ -1708,10 +1712,6 @@ esiste. Per questo motivo quando si copia un file, a meno di preservare 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} @@ -1827,12 +1827,12 @@ rispettivamente al proprietario, al gruppo, a tutti gli altri. \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 @@ -1922,7 +1922,7 @@ simbolico tutti i permessi come concessi; utente e gruppo a cui esso 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 @@ -1937,7 +1937,7 @@ effettivo e gli eventuali group-ID supplementari del processo.\footnote{in 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. @@ -1978,8 +1978,8 @@ processo appartiene ad un gruppo appropriato, in questo caso i permessi per 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} @@ -2032,8 +2032,8 @@ riportati in tab.~\ref{tab:file_mode_flags}. 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 @@ -2045,8 +2045,6 @@ sez.~\ref{sec:file_mand_locking}). \itindend{suid~bit} \itindend{sgid~bit} -\subsection{Il bit \textsl{sticky}} -\label{sec:file_sticky} \itindbeg{sticky~bit} @@ -2090,7 +2088,7 @@ $ ls -ld /tmp 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 @@ -2098,52 +2096,15 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti. \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 è: @@ -2206,10 +2167,6 @@ eseguendo un programma coi privilegi di un altro utente (ad esempio attraverso 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: @@ -2303,18 +2260,18 @@ in particolare accade che: \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 @@ -2324,9 +2281,6 @@ qualora un processo che non appartenga all'amministratore\footnote{per la 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 @@ -2368,8 +2322,41 @@ voluti. Di norma questo valore viene impostato una volta per tutte al login a $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 @@ -2522,6 +2509,8 @@ non 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} diff --git a/filestd.tex b/filestd.tex index a3301ad..b2a3c18 100644 --- a/filestd.tex +++ b/filestd.tex @@ -326,10 +326,11 @@ di errore e di fine del file (vedi sez.~\ref{sec:file_io}) sono cancellate. Il 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 diff --git a/fileunix.tex b/fileunix.tex index 953bdcb..95dc184 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -55,7 +55,8 @@ valore come argomento alle varie funzioni dell'interfaccia. 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 è @@ -68,15 +69,15 @@ che il processo ha aperto, ed in particolare: \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 @@ -228,9 +229,9 @@ un file descriptor, il suo prototipo 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 @@ -261,8 +262,9 @@ descriptor con il valore pi \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 @@ -392,7 +394,7 @@ L'argomento \param{mode} indica i permessi con cui il file viene creato; i 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 @@ -462,8 +464,9 @@ La chiusura di un file rilascia ogni blocco (il \textit{file locking} \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 diff --git a/ipc.tex b/ipc.tex index 35e1990..7c7b503 100644 --- a/ipc.tex +++ b/ipc.tex @@ -977,7 +977,7 @@ a differenza di quanto avviene per i permessi dei file, fallire in uno dei 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} diff --git a/prochand.tex b/prochand.tex index 1f97963..2d509d6 100644 --- a/prochand.tex +++ b/prochand.tex @@ -543,17 +543,17 @@ lo stesso avviene anche per tutti i figli; la funzione \func{fork} infatti ha 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 @@ -597,7 +597,8 @@ comune dopo l'esecuzione di una \func{fork} 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 @@ -1224,7 +1225,7 @@ la lista completa \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}); @@ -1411,7 +1412,7 @@ Questi identificatori normalmente sono identici ai corrispondenti del gruppo 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). @@ -1513,7 +1514,7 @@ all'\textsl{user-ID salvato}. Negli altri casi viene segnalato un errore (con 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. @@ -1928,7 +1929,7 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.13, e % \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}) @@ -1950,14 +1951,15 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.13, e 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}).\\ @@ -1968,7 +1970,8 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.13, e 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 @@ -3440,12 +3443,6 @@ disposizione due macro di compilatore, \macro{\_REENTRANT} e 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 @@ -3489,3 +3486,8 @@ varie funzioni di libreria, che sono identificate aggiungendo il suffisso % 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: diff --git a/socket.tex b/socket.tex index e0f283e..052e8c5 100644 --- a/socket.tex +++ b/socket.tex @@ -149,9 +149,10 @@ implicitamente dal tipo di socket, per cui di norma questo valore viene messo 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}