From: Simone Piccardi Date: Wed, 11 Jan 2012 18:48:33 +0000 (+0000) Subject: Assunta la convenzione che PID, GID ecc. sono maiuscoli, ed altre X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=08c289c4acd775aabeb5beeb7b08566969e11d9b;p=gapil.git Assunta la convenzione che PID, GID ecc. sono maiuscoli, ed altre piccole convenzioni. --- diff --git a/fileadv.tex b/fileadv.tex index d3c9061..02f0b9f 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -385,7 +385,7 @@ riportate in tab.~\ref{tab:file_flock_type}, che permettono di richiedere rispettivamente uno \textit{shared lock}, un \textit{esclusive lock}, e la rimozione di un blocco precedentemente acquisito. Infine il campo \var{l\_pid} viene usato solo in caso di lettura, quando si chiama \func{fcntl} con -\const{F\_GETLK}, e riporta il \acr{pid} del processo che detiene il +\const{F\_GETLK}, e riporta il \ids{PID} del processo che detiene il \textit{file lock}. Oltre a quanto richiesto tramite i campi di \struct{flock}, l'operazione @@ -462,14 +462,14 @@ fig.~\ref{fig:file_posix_lock}; come si vede esso è molto simile all'analogo di fig.~\ref{fig:file_flock_struct}:\footnote{in questo caso nella figura si sono evidenziati solo i campi di \struct{file\_lock} significativi per la semantica POSIX, in particolare adesso ciascuna struttura contiene, oltre al - \acr{pid} del processo in \var{fl\_pid}, la sezione di file che viene + \ids{PID} del processo in \var{fl\_pid}, la sezione di file che viene bloccata grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è comunque la stessa, solo che in questo caso nel campo \var{fl\_flags} è impostato il bit \const{FL\_POSIX} ed il campo \var{fl\_file} non viene usato.} il blocco è sempre associato \itindex{inode} all'inode, solo che in questo caso la titolarità non viene identificata con il riferimento ad una voce nella \itindex{file~table} \textit{file table}, ma con il valore del -\acr{pid} del processo. +\ids{PID} del processo. \begin{figure}[!htb] \centering \includegraphics[width=12cm]{img/file_posix_lock} @@ -488,19 +488,19 @@ una già bloccata, in caso affermativo decide in base al tipo di blocco, in caso negativo il nuovo blocco viene comunque acquisito ed aggiunto alla lista. Nel caso di rimozione invece questa viene effettuata controllando che il -\acr{pid} del processo richiedente corrisponda a quello contenuto nel blocco. +\ids{PID} del processo richiedente corrisponda a quello contenuto nel blocco. Questa diversa modalità ha delle conseguenze precise riguardo il comportamento dei \textit{file lock} POSIX. La prima conseguenza è che un \textit{file lock} POSIX non viene mai ereditato attraverso una \func{fork}, dato che il processo -figlio avrà un \acr{pid} diverso, mentre passa indenne attraverso una -\func{exec} in quanto il \acr{pid} resta lo stesso. Questo comporta che, al +figlio avrà un \ids{PID} diverso, mentre passa indenne attraverso una +\func{exec} in quanto il \ids{PID} resta lo stesso. Questo comporta che, al contrario di quanto avveniva con la semantica BSD, quando un processo termina tutti i \textit{file lock} da esso detenuti vengono immediatamente rilasciati. La seconda conseguenza è che qualunque file descriptor che faccia riferimento allo stesso file (che sia stato ottenuto con una \func{dup} o con una \func{open} in questo caso non fa differenza) può essere usato per rimuovere -un blocco, dato che quello che conta è solo il \acr{pid} del processo. Da +un blocco, dato che quello che conta è solo il \ids{PID} del processo. Da questo deriva una ulteriore sottile differenza di comportamento: dato che alla chiusura di un file i blocchi ad esso associati vengono rimossi, nella semantica POSIX basterà chiudere un file descriptor qualunque per cancellare @@ -508,11 +508,11 @@ tutti i blocchi relativi al file cui esso faceva riferimento, anche se questi fossero stati creati usando altri file descriptor che restano aperti. Dato che il controllo sull'accesso ai blocchi viene eseguito sulla base del -\acr{pid} del processo, possiamo anche prendere in considerazione un altro +\ids{PID} del processo, possiamo anche prendere in considerazione un altro degli aspetti meno chiari di questa interfaccia e cioè cosa succede quando si richiedono dei blocchi su regioni che si sovrappongono fra loro all'interno stesso processo. Siccome il controllo, come nel caso della rimozione, si basa -solo sul \acr{pid} del processo che chiama la funzione, queste richieste +solo sul \ids{PID} del processo che chiama la funzione, queste richieste avranno sempre successo. Nel caso della semantica BSD, essendo i lock relativi a tutto un file e non @@ -811,7 +811,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_special_perm}), esso viene di norma -utilizzato per cambiare il \acr{gid} effettivo con cui viene eseguito un +utilizzato per cambiare il \ids{GID} 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 esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che @@ -2677,7 +2677,7 @@ Si tenga presente che un processo può mantenere solo un tipo di \textit{lease} su un file, e che un \textit{lease} può essere ottenuto solo su file di dati (pipe e dispositivi sono quindi esclusi). Inoltre un processo non privilegiato può ottenere un \textit{lease} soltanto per un file appartenente ad un -\acr{uid} corrispondente a quello del processo. Soltanto un processo con +\ids{UID} corrispondente a quello del processo. Soltanto un processo con privilegi di amministratore (cioè con la \itindex{capabilities} capability \const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire \textit{lease} su qualunque file. diff --git a/filedir.tex b/filedir.tex index c9fc3c8..d3d7cda 100644 --- a/filedir.tex +++ b/filedir.tex @@ -544,7 +544,7 @@ le seguenti: gruppo primario del processo, eccetto il caso in cui la directory ha il bit di \acr{sgid} impostato (per una descrizione dettagliata del significato di questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso - file e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}. + file e subdirectory ereditano sia il \ids{GID} che lo \acr{sgid}. \item l'amministratore può scegliere la dimensione dei blocchi del filesystem in fase di creazione, a seconda delle sue esigenze: blocchi più grandi permettono un accesso più veloce, ma sprecano più spazio disco. @@ -1454,7 +1454,7 @@ La funzione che permette la cancellazione di una directory è invece \begin{errlist} \item[\errcode{EPERM}] il filesystem non supporta la cancellazione di directory, oppure la directory che contiene \param{dirname} ha lo - \itindex{sticky~bit} \textit{sticky bit} impostato e l'\acr{uid} effettivo + \itindex{sticky~bit} \textit{sticky bit} impostato e l'\ids{UID} effettivo del processo non corrisponde al proprietario della directory. \item[\errcode{EACCES}] non c'è il permesso di scrittura per la directory che contiene la directory che si vuole cancellare, o non c'è il permesso @@ -2359,7 +2359,7 @@ La funzionane genera un nome univoco sostituendo le \code{XXXXXX} finali di funzione non si può usare una stringa costante. Tutte le avvertenze riguardo alle possibili \itindex{race~condition} \textit{race condition} date per \func{tmpnam} continuano a valere; inoltre in alcune vecchie implementazioni -il valore usato per sostituire le \code{XXXXXX} viene formato con il \acr{pid} +il valore usato per sostituire le \code{XXXXXX} viene formato con il \ids{PID} del processo più una lettera, il che mette a disposizione solo 26 possibilità diverse per il nome del file, e rende il nome temporaneo facile da indovinare. Per tutti questi motivi la funzione è deprecata e non dovrebbe mai essere @@ -3078,7 +3078,7 @@ concetti essenziali e le funzioni usate per gestirne i vari aspetti. Ad ogni file Linux associa sempre l'utente che ne è proprietario (il cosiddetto \textit{owner}) ed un gruppo di appartenenza, secondo il meccanismo -degli identificatori di utente e gruppo (\acr{uid} e \acr{gid}). Questi valori +degli identificatori di utente e gruppo (\ids{UID} e \ids{GID}). Questi valori sono accessibili da programma tramite la funzione \func{stat}, e sono mantenuti nei campi \var{st\_uid} e \var{st\_gid} della struttura \struct{stat} (si veda sez.~\ref{sec:file_stat}).\footnote{questo è vero solo @@ -3225,8 +3225,8 @@ 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 l'utente e il gruppo a cui il file appartiene (i valori di \var{st\_uid} e -\var{st\_gid} accennati in precedenza) e l'\acr{uid} effettivo, il \acr{gid} -effettivo e gli eventuali \acr{gid} supplementari del processo.\footnote{in +\var{st\_gid} accennati in precedenza) e l'\ids{UID} effettivo, il \ids{GID} +effettivo e gli eventuali \ids{GID} supplementari del processo.\footnote{in realtà Linux, per quanto riguarda l'accesso ai file, utilizza gli identificatori del gruppo \textit{filesystem} (si ricordi quanto esposto in sez.~\ref{sec:proc_perms}), ma essendo questi del tutto equivalenti ai primi, @@ -3235,19 +3235,19 @@ effettivo e gli eventuali \acr{gid} 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_special_perm}, l'\acr{uid} effettivo e il \acr{gid} effettivo -corrispondono ai valori dell'\acr{uid} e del \acr{gid} dell'utente che ha -lanciato il processo, mentre i \acr{gid} supplementari sono quelli dei gruppi +sez.~\ref{sec:file_special_perm}, l'\ids{UID} effettivo e il \ids{GID} effettivo +corrispondono ai valori dell'\ids{UID} e del \ids{GID} dell'utente che ha +lanciato il processo, mentre i \ids{GID} supplementari sono quelli dei gruppi cui l'utente appartiene. I passi attraverso i quali viene stabilito se il processo possiede il diritto di accesso sono i seguenti: \begin{enumerate} -\item Se l'\acr{uid} effettivo del processo è zero (corrispondente +\item Se l'\ids{UID} effettivo del processo è zero (corrispondente all'amministratore) l'accesso è sempre garantito senza nessun ulteriore controllo. Per questo motivo \textsl{root} ha piena libertà di accesso a tutti i file. -\item Se l'\acr{uid} effettivo del processo è uguale all'\acr{uid} del +\item Se l'\ids{UID} effettivo del processo è uguale all'\ids{UID} del proprietario del file (nel qual caso si dice che il processo è proprietario del file) allora: \begin{itemize*} @@ -3257,8 +3257,8 @@ di accesso sono i seguenti: impostato, l'accesso è consentito \item altrimenti l'accesso è negato \end{itemize*} -\item Se il \acr{gid} effettivo del processo o uno dei \acr{gid} supplementari - dei processi corrispondono al \acr{gid} del file allora: +\item Se il \ids{GID} effettivo del processo o uno dei \ids{GID} supplementari + dei processi corrispondono al \ids{GID} del file allora: \begin{itemize*} \item se il bit dei permessi d'accesso del gruppo è impostato, l'accesso è consentito, @@ -3299,9 +3299,9 @@ corrispondono a quelli dell'utente con cui si è entrati nel sistema. Se però il file del programma (che ovviamente deve essere eseguibile\footnote{per motivi di sicurezza il kernel ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili.}) ha il bit \acr{suid} impostato, il -kernel assegnerà come \acr{uid} effettivo al nuovo processo l'\acr{uid} del -proprietario del file al posto dell'\acr{uid} del processo originario. Avere -il bit \acr{sgid} impostato ha lo stesso effetto sul \acr{gid} effettivo del +kernel assegnerà come \ids{UID} effettivo al nuovo processo l'\ids{UID} del +proprietario del file al posto dell'\ids{UID} del processo originario. Avere +il bit \acr{sgid} impostato ha lo stesso effetto sul \ids{GID} effettivo del processo. I bit \acr{suid} e \acr{sgid} vengono usati per permettere agli utenti normali @@ -3398,10 +3398,10 @@ consapevolmente, cancellare i file temporanei creati degli altri utenti. \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'\acr{uid} ed il \acr{gid} effettivo del processo; -ci sono casi però in cui si può voler effettuare il controllo con l'\acr{uid} -reale ed il \acr{gid} reale, vale a dire usando i valori di \acr{uid} e -\acr{gid} relativi all'utente che ha lanciato il programma, e che, come +file viene fatto utilizzando l'\ids{UID} ed il \ids{GID} effettivo del processo; +ci sono casi però in cui si può voler effettuare il controllo con l'\ids{UID} +reale ed il \ids{GID} reale, vale a dire usando i valori di \ids{UID} e +\ids{GID} relativi all'utente che ha lanciato il programma, e che, come 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. @@ -3491,7 +3491,7 @@ filename e su un file descriptor, i loro prototipi sono: \bodydesc{Le funzioni restituiscono zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del proprietario del file o non è zero. \item[\errcode{EROFS}] il file è su un filesystem in sola lettura. \end{errlist} @@ -3555,7 +3555,7 @@ bit \itindex{suid~bit} \acr{suid} il valore da fornire sarebbe $4755$. Il cambiamento dei permessi di un file eseguito attraverso queste funzioni ha comunque alcune limitazioni, previste per motivi di sicurezza. L'uso delle -funzioni infatti è possibile solo se l'\acr{uid} effettivo del processo +funzioni infatti è possibile solo se l'\ids{UID} effettivo del processo corrisponde a quello del proprietario del file o dell'amministratore, altrimenti esse falliranno con un errore di \errcode{EPERM}. @@ -3565,7 +3565,7 @@ non tutti i valori possibili di \param{mode} sono permessi o hanno effetto; in particolare accade che: \begin{enumerate} \item siccome solo l'amministratore può impostare lo \itindex{sticky~bit} - \textit{sticky bit}, se l'\acr{uid} effettivo del processo non è zero esso + \textit{sticky bit}, se l'\ids{UID} 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_management} riguardo la @@ -3575,7 +3575,7 @@ in particolare accade che: un file appartenente ad 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'\acr{uid} effettivo del processo è zero). + (la cosa non avviene quando l'\ids{UID} effettivo del processo è zero). \end{enumerate} Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2}, @@ -3648,21 +3648,21 @@ 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'\acr{uid} effettivo del processo che lo crea; per il \acr{gid} invece prevede -due diverse possibilità: +Lo standard POSIX prescrive che l'\ids{UID} del nuovo file corrisponda +all'\ids{UID} effettivo del processo che lo crea; per il \ids{GID} invece +prevede due diverse possibilità: \begin{itemize*} -\item il \acr{gid} del file corrisponde al \acr{gid} effettivo del processo. -\item il \acr{gid} del file corrisponde al \acr{gid} della directory in cui +\item il \ids{GID} del file corrisponde al \ids{GID} effettivo del processo. +\item il \ids{GID} del file corrisponde al \ids{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 +\ids{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 +Usare la semantica BSD ha il vantaggio che il \ids{GID} viene sempre automaticamente propagato, restando coerente a quello della directory di partenza, in tutte le sotto-directory. @@ -3671,7 +3671,7 @@ risultato di coerenza che si ha con BSD necessita che quando si creano 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 le varie distribuzioni assicurano che le sotto-directory create -nella home di un utente restino sempre con il \acr{gid} del gruppo primario +nella home di un utente restino sempre con il \ids{GID} del gruppo primario dello stesso. La presenza del bit \acr{sgid} è inoltre molto comoda quando si hanno @@ -3703,7 +3703,7 @@ l'utente che il gruppo a cui un file appartiene; i rispettivi prototipi sono: \bodydesc{Le funzioni restituiscono 0 in caso di successo e -1 per un errore, nel qual caso caso \var{errno} assumerà i valori: \begin{errlist} - \item[\errcode{EPERM}] l'\acr{uid} effettivo non corrisponde a quello del + \item[\errcode{EPERM}] l'\ids{UID} effettivo non corrisponde a quello del proprietario del file o non è zero, o utente e gruppo non sono validi \end{errlist} Oltre a questi entrambe restituiscono gli errori \errval{EROFS} e @@ -4414,15 +4414,15 @@ identificatori del gruppo \textit{effective} del processo, ma in presenza di ACL i passi attraverso i quali viene stabilito se esso ha diritto di accesso sono i seguenti: \begin{enumerate*} -\item Se l'\acr{uid} del processo è nullo l'accesso è sempre garantito senza +\item Se l'\ids{UID} del processo è nullo l'accesso è sempre garantito senza nessun controllo. -\item Se l'\acr{uid} del processo corrisponde al proprietario del file allora: +\item Se l'\ids{UID} del processo corrisponde al proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto, l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se l'\acr{uid} del processo corrisponde ad un qualunque qualificatore +\item Se l'\ids{UID} del processo corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_USER} allora: \begin{itemize*} \item se la voce \const{ACL\_USER} corrispondente e la voce @@ -4430,7 +4430,7 @@ sono i seguenti: consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari +\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari corrisponde al gruppo proprietario del file allora: \begin{itemize*} \item se la voce \const{ACL\_GROUP\_OBJ} e una eventuale voce @@ -4439,7 +4439,7 @@ sono i seguenti: l'accesso è consentito; \item altrimenti l'accesso è negato. \end{itemize*} -\item Se è il \acr{gid} del processo o uno dei \acr{gid} supplementari +\item Se è il \ids{GID} del processo o uno dei \ids{GID} supplementari corrisponde ad un qualunque qualificatore presente in una voce \const{ACL\_GROUP} allora: \begin{itemize*} @@ -4783,7 +4783,7 @@ tab.~\ref{tab:acl_to_text_options}. \hline \const{TEXT\_ABBREVIATE} & stampa le voci in forma abbreviata.\\ \const{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di - \acr{uid} e \acr{gid}.\\ + \ids{UID} e \ids{GID}.\\ \const{TEXT\_SOME\_EFFECTIVE}& per ciascuna voce che contiene permessi che vengono eliminati dalla \const{ACL\_MASK} viene generato un commento con i permessi @@ -5109,7 +5109,7 @@ La funzione richiede che il filesystem sul quale si vuole operare sia montato con il supporto delle quote abilitato; esso deve essere specificato con il nome del file di dispositivo nell'argomento \param{dev}. Per le operazioni che lo richiedono inoltre si dovrà indicare con l'argomento \param{id} l'utente o -il gruppo (specificati rispettivamente per \acr{uid} e \acr{gid}) su cui si +il gruppo (specificati rispettivamente per \ids{UID} e \ids{GID}) su cui si vuole operare. Alcune operazioni usano l'argomento \param{addr} per indicare un indirizzo ad un area di memoria il cui utilizzo dipende dall'operazione stessa. @@ -5218,10 +5218,10 @@ l'amministratore può ottenere i dati di tutti. \hline \const{QFMT\_VFS\_OLD}& il vecchio (ed obsoleto) formato delle quote.\\ \const{QFMT\_VFS\_V0} & la versione 0 usata dal VFS di Linux (supporta - \acr{uid} e \acr{gid} a 32 bit e limiti fino a + \ids{UID} e \ids{GID} a 32 bit e limiti fino a $2^{42}$ byte e $2^{32}$ file.\\ \const{QFMT\_VFS\_V1} & la versione 1 usata dal VFS di Linux (supporta - \acr{uid} e \acr{GID} a 32 bit e limiti fino a + \ids{UID} e \ids{GID} a 32 bit e limiti fino a $2^{64}$ byte e $2^{64}$ file.\\ \hline \end{tabular} @@ -5689,7 +5689,7 @@ nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i privilegi originali dal processo. Per questo motivo se un programma senza \textit{capabilities} assegnate viene -eseguito da un processo con \acr{uid} reale 0, esso verrà trattato come +eseguito da un processo con \ids{UID} reale 0, esso verrà trattato come se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo, col risultato di fornire comunque al processo tutte le capacità presenti nel @@ -5698,19 +5698,19 @@ il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si riesce così a riottenere il comportamento classico di un sistema unix-like. Una seconda circostanza è quella relativa a cosa succede alle -\textit{capabilities} di un processo nelle possibili transizioni da \acr{uid} -nullo a \acr{uid} non nullo o viceversa (corrispondenti rispettivamente a +\textit{capabilities} di un processo nelle possibili transizioni da \ids{UID} +nullo a \ids{UID} non nullo o viceversa (corrispondenti rispettivamente a cedere o riottenere i i privilegi di amministratore) che si possono effettuare con le varie funzioni viste in sez.~\ref{sec:proc_setuid}. In questo caso la casistica è di nuovo alquanto complessa, considerata anche la presenza dei diversi gruppi di identificatori illustrati in tab.~\ref{tab:proc_uid_gid}, si avrà allora che: \begin{enumerate*} -\item se si passa da \acr{uid} effettivo nullo a non nullo +\item se si passa da \ids{UID} effettivo nullo a non nullo l'\textit{effective set} del processo viene totalmente azzerato, se - viceversa si passa da \acr{uid} effettivo non nullo a nullo il + viceversa si passa da \ids{UID} effettivo non nullo a nullo il \textit{permitted set} viene copiato nell'\textit{effective set}; -\item se si passa da \textit{file system} \acr{uid} nullo a non nullo verranno +\item se si passa da \textit{file system} \ids{UID} nullo a non nullo verranno cancellate dall'\textit{effective set} del processo tutte le capacità attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD}, \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH}, @@ -5745,7 +5745,7 @@ Per questo motivo a partire dal kernel 2.6.26, se le \textit{file ulteriore maschera binaria, chiamata \textit{securebits flags}, su cui sono mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui valore consente di modificare queste regole speciali che si applicano ai -processi con \acr{uid} nullo. La maschera viene sempre mantenuta +processi con \ids{UID} nullo. La maschera viene sempre mantenuta attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre cancellato il flag \const{SECURE\_KEEP\_CAPS}. @@ -5759,22 +5759,22 @@ cancellato il flag \const{SECURE\_KEEP\_CAPS}. \hline \const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle sue \textit{capabilities} quando tutti i suoi - \acr{uid} passano ad un valore non + \ids{UID} passano ad un valore non nullo (regola di compatibilità per il cambio - di \acr{uid} n.~3 del precedente + di \ids{UID} n.~3 del precedente elenco), sostituisce il precedente uso dell'operazione \const{PR\_SET\_KEEPCAPS} di \func{prctl}.\\ \const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche delle sue \textit{capabilities} nel passaggio - da nullo a non nullo degli \acr{uid} + da nullo a non nullo degli \ids{UID} dei gruppi \textit{effective} e \textit{file system} (regole di compatibilità - per il cambio di \acr{uid} nn.~1 e 2 del + per il cambio di \ids{UID} nn.~1 e 2 del precedente elenco).\\ \const{SECURE\_NOROOT} & Il processo non assume nessuna capacità aggiuntiva quando esegue un programma, anche - se ha \acr{uid} nullo o il programma ha + se ha \ids{UID} nullo o il programma ha il \acr{suid} bit attivo ed appartiene all'amministratore (regola di compatibilità per l'esecuzione di programmi senza @@ -6010,8 +6010,8 @@ capacità), o di impostare i \textit{securebits} delle \textit{capabilities}. La prima fra le capacità ``\textsl{ampie}'' che occorre dettagliare maggiormente è \const{CAP\_FOWNER}, che rimuove le restrizioni poste ad un processo che non ha la proprietà di un file in un vasto campo di -operazioni;\footnote{vale a dire la richiesta che l'\acr{uid} effettivo del - processo (o meglio l'\acr{uid} di filesystem, vedi +operazioni;\footnote{vale a dire la richiesta che l'\ids{UID} effettivo del + processo (o meglio l'\ids{UID} di filesystem, vedi sez.~\ref{sec:proc_setuid}) coincida con quello del proprietario.} queste comprendono i cambiamenti dei permessi e dei tempi del file (vedi sez.~\ref{sec:file_perm_management} e sez.~\ref{sec:file_file_times}), le @@ -6036,7 +6036,7 @@ disattivare la swap, montare, rimontare e smontare filesystem (vedi sez.~\ref{sec:sys_file_config}), effettuare operazioni di controllo su qualunque oggetto dell'IPC di SysV (vedi sez.~\ref{sec:ipc_sysv}), operare sugli attributi estesi dei file di classe \texttt{security} o \texttt{trusted} -(vedi sez.~\ref{sec:file_xattr}), specificare un \acr{uid} arbitrario +(vedi sez.~\ref{sec:file_xattr}), specificare un \ids{UID} arbitrario nella trasmissione delle credenziali dei socket (vedi sez.~\ref{sec:socket_credential_xxx}), assegnare classi privilegiate (\const{IOPRIO\_CLASS\_RT} e prima del kernel 2.6.25 anche @@ -6705,7 +6705,7 @@ con la funzione \funcd{chroot}, il cui prototipo è: \bodydesc{La funzione restituisce zero in caso di successo e -1 per un errore, in caso di errore \var{errno} può assumere i valori: \begin{errlist} - \item[\errcode{EPERM}] l'\acr{uid} effettivo del processo non è zero. + \item[\errcode{EPERM}] l'\ids{UID} effettivo del processo non è zero. \end{errlist} ed inoltre \errval{EFAULT}, \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOMEM}, \errval{ENOTDIR}, \errval{EACCES}, \errval{ELOOP}; diff --git a/fileunix.tex b/fileunix.tex index 4003f95..50c3008 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -1328,7 +1328,7 @@ il comportamento rispetto a quello ordinario di \func{access}. In questo caso esso può essere specificato come maschera binaria di due valori: \begin{basedescript}{\desclabelwidth{3.0cm}} \item[\const{AT\_EACCESS}] se impostato \funcd{faccessat} esegue il controllo - dei permessi usando l'\acr{uid} effettivo invece di quello reale (il + dei permessi usando l'\ids{UID} effettivo invece di quello reale (il comportamento di default, che riprende quello di \func{access}). \item[\const{AT\_SYMLINK\_NOFOLLOW}] se impostato \funcd{faccessat} non esegue la dereferenziazione dei link simbolici, effettuando il controllo dei @@ -1452,12 +1452,12 @@ per \var{cmd} è riportata di seguito: imposta \var{errno} a \errcode{EINTR}, in caso di successo ritorna un valore nullo. Questa funzionalità è trattata in dettaglio in sez.~\ref{sec:file_posix_lock}. -\item[\const{F\_GETOWN}] restituisce il \acr{pid} del processo o +\item[\const{F\_GETOWN}] restituisce il \ids{PID} del processo o l'identificatore del \itindex{process~group} \textit{process group}\footnote{i \itindex{process~group} \textit{process group} sono (vedi sez.~\ref{sec:sess_proc_group}) raggruppamenti di processi usati nel controllo di sessione; a ciascuno di essi è associato un identificatore - (un numero positivo analogo al \acr{pid}).} che è preposto alla ricezione + (un numero positivo analogo al \ids{PID}).} che è preposto alla ricezione dei segnali \signal{SIGIO}\footnote{o qualunque altro segnale alternativo impostato con \const{F\_FSETSIG}.} per gli eventi associati al file descriptor \param{fd}\footnote{il segnale viene usato sia per il diff --git a/intro.tex b/intro.tex index 1e9423b..d0b23fe 100644 --- a/intro.tex +++ b/intro.tex @@ -343,9 +343,9 @@ la cui corrispondenza ad un nome espresso in caratteri è inserita nei due file \itindex{Name~Service~Switch} \textit{Name Service Switch}, su varie tipologie di supporti, compresi server centralizzati come LDAP.} Questi identificativi sono l'\textit{user identifier}, detto in breve -\textsl{user-ID}, ed indicato dall'acronimo \acr{uid}, e il \textit{group +\textsl{user-ID}, ed indicato dall'acronimo \ids{UID}, e il \textit{group identifier}, detto in breve \textsl{group-ID}, ed identificato dall'acronimo -\acr{gid}, torneremo in dettaglio su questo argomento in +\ids{GID}, torneremo in dettaglio su questo argomento in sez.~\ref{sec:proc_perms}. Il kernel conosce ed utilizza soltanto questi valori numerici, i nomi ad essi associati sono interamente gestiti in \textit{user space} con opportune funzioni di libreria, torneremo su questo @@ -360,7 +360,7 @@ di identificazione. Infine in ogni sistema unix-like è presente uno speciale utente privilegiato, il cosiddetto \textit{superuser}, il cui username è di norma \textit{root}, ed -il cui \acr{uid} è zero. Esso identifica l'amministratore del sistema, che +il cui \ids{UID} è zero. Esso identifica l'amministratore del sistema, che deve essere in grado di fare qualunque operazione; per l'utente \textit{root} infatti i meccanismi di controllo cui si è accennato in precedenza sono disattivati.\footnote{i controlli infatti vengono eseguiti da uno pseudo-codice diff --git a/ipc.tex b/ipc.tex index 4b569aa..ae0cdb7 100644 --- a/ipc.tex +++ b/ipc.tex @@ -619,7 +619,7 @@ principale del programma e le definizioni delle variabili. Il codice completo \end{figure} La prima istruzione (\texttt{\small 12}) compone il nome della fifo che dovrà -essere utilizzata per ricevere la risposta dal server. Si usa il \acr{pid} +essere utilizzata per ricevere la risposta dal server. Si usa il \ids{PID} del processo per essere sicuri di avere un nome univoco; dopo di che (\texttt{\small 13-18}) si procede alla creazione del relativo file, uscendo in caso di errore (a meno che il file non sia già presente sul filesystem). @@ -817,7 +817,7 @@ utilizzando, con tutte le conseguenze (negative) del caso. Un'ulteriore caratteristica negativa è che gli oggetti usati nel \textit{SysV IPC} vengono creati direttamente dal kernel, e sono accessibili solo specificando il relativo \textsl{identificatore}. Questo è un numero -progressivo (un po' come il \acr{pid} dei processi) che il kernel assegna a +progressivo (un po' come il \ids{PID} dei processi) che il kernel assegna a ciascuno di essi quanto vengono creati (sul procedimento di assegnazione torneremo in sez.~\ref{sec:ipc_sysv_id_use}). L'identificatore viene restituito dalle funzioni che creano l'oggetto, ed è quindi locale al processo che le ha @@ -947,7 +947,7 @@ il proprietario, il suo gruppo e tutti gli altri. Quando l'oggetto viene creato i campi \var{cuid} e \var{uid} di \struct{ipc\_perm} ed i campi \var{cgid} e \var{gid} vengono impostati -rispettivamente al valore dell'\acr{uid} e del \acr{gid} effettivo del processo +rispettivamente al valore dell'\ids{UID} e del \ids{GID} effettivo del processo che ha chiamato la funzione, ma, mentre i campi \var{uid} e \var{gid} possono essere cambiati, i campi \var{cuid} e \var{cgid} restano sempre gli stessi. @@ -967,12 +967,12 @@ controlli è simile a quello dei file, ed avviene secondo questa sequenza: \begin{itemize*} \item se il processo ha i privilegi di amministratore l'accesso è sempre consentito. -\item se l'\acr{uid} effettivo del processo corrisponde o al valore del campo +\item se l'\ids{UID} effettivo del processo corrisponde o al valore del campo \var{cuid} o a quello del campo \var{uid} ed il permesso per il proprietario in \var{mode} è appropriato\footnote{per appropriato si intende che è impostato il permesso di scrittura per le operazioni di scrittura e quello di lettura per le operazioni di lettura.} l'accesso è consentito. -\item se il \acr{gid} effettivo del processo corrisponde o al +\item se il \ids{GID} effettivo del processo corrisponde o al valore del campo \var{cgid} o a quello del campo \var{gid} ed il permesso per il gruppo in \var{mode} è appropriato l'accesso è consentito. \item se il permesso per gli altri è appropriato l'accesso è consentito. @@ -1244,7 +1244,7 @@ gli altri campi invece: \item il campo \var{msg\_qnum}, che esprime il numero di messaggi presenti sulla coda, viene inizializzato a 0. \item i campi \var{msg\_lspid} e \var{msg\_lrpid}, che esprimono - rispettivamente il \acr{pid} dell'ultimo processo che ha inviato o ricevuto + rispettivamente il \ids{PID} dell'ultimo processo che ha inviato o ricevuto un messaggio sulla coda, sono inizializzati a 0. \item i campi \var{msg\_stime} e \var{msg\_rtime}, che esprimono rispettivamente il tempo in cui è stato inviato o ricevuto l'ultimo @@ -1303,7 +1303,7 @@ eseguire; i valori possibili sono: riceveranno un errore di \errcode{EIDRM}, e tutti processi in attesa su funzioni di lettura o di scrittura sulla coda saranno svegliati ricevendo il medesimo errore. Questo comando può essere eseguito solo da un processo - con \acr{uid} effettivo corrispondente al creatore o al proprietario della + con \ids{UID} effettivo corrispondente al creatore o al proprietario della coda, o all'amministratore. \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario della coda, ed il limite massimo sulle dimensioni del totale dei messaggi in @@ -1416,7 +1416,7 @@ Una volta completato con successo l'invio del messaggio sulla coda, la funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare vengono modificati: \begin{itemize*} -\item Il valore di \var{msg\_lspid}, che viene impostato al \acr{pid} del +\item Il valore di \var{msg\_lspid}, che viene impostato al \ids{PID} del processo chiamante. \item Il valore di \var{msg\_qnum}, che viene incrementato di uno. \item Il valore \var{msg\_stime}, che viene impostato al tempo corrente. @@ -1502,7 +1502,7 @@ Una volta completata con successo l'estrazione del messaggio dalla coda, la funzione aggiorna i dati mantenuti in \struct{msqid\_ds}, in particolare vengono modificati: \begin{itemize*} -\item Il valore di \var{msg\_lrpid}, che viene impostato al \acr{pid} del +\item Il valore di \var{msg\_lrpid}, che viene impostato al \ids{PID} del processo chiamante. \item Il valore di \var{msg\_qnum}, che viene decrementato di uno. \item Il valore \var{msg\_rtime}, che viene impostato al tempo corrente. @@ -1547,7 +1547,7 @@ principali del codice del nuovo server (il codice completo è nel file \file{MQFortuneServer.c} nei sorgenti allegati). Il programma è basato su un uso accorto della caratteristica di poter associate un ``tipo'' ai messaggi per permettere una comunicazione indipendente fra il server ed i vari client, -usando il \acr{pid} di questi ultimi come identificativo. Questo è possibile +usando il \ids{PID} di questi ultimi come identificativo. Questo è possibile in quanto, al contrario di una fifo, la lettura di una coda di messaggi può non essere sequenziale, proprio grazie alla classificazione dei messaggi sulla base del loro tipo. @@ -1581,9 +1581,9 @@ il ciclo principale (\texttt{\small 33--40}). Questo inizia (\texttt{\small 34}) con il porsi in attesa di un messaggio di richiesta da parte di un client; si noti infatti come \func{msgrcv} richieda un messaggio con \var{mtype} uguale a 1: questo è il valore usato per le richieste dato che -corrisponde al \acr{pid} di \cmd{init}, che non può essere un client. L'uso +corrisponde al \ids{PID} di \cmd{init}, che non può essere un client. L'uso del flag \const{MSG\_NOERROR} è solo per sicurezza, dato che i messaggi di -richiesta sono di dimensione fissa (e contengono solo il \acr{pid} del +richiesta sono di dimensione fissa (e contengono solo il \ids{PID} del client). Se non sono presenti messaggi di richiesta \func{msgrcv} si bloccherà, @@ -1595,7 +1595,7 @@ calcolandone (\texttt{\small 37}) la dimensione. Per poter permettere a ciascun client di ricevere solo la risposta indirizzata a lui il tipo del messaggio in uscita viene inizializzato (\texttt{\small 38}) -al valore del \acr{pid} del client ricevuto nel messaggio di richiesta. +al valore del \ids{PID} del client ricevuto nel messaggio di richiesta. L'ultimo passo del ciclo (\texttt{\small 39}) è inviare sulla coda il messaggio di risposta. Si tenga conto che se la coda è piena anche questa funzione potrà bloccarsi fintanto che non venga liberato dello spazio. @@ -1633,13 +1633,13 @@ il programma termina immediatamente. Una volta acquisito l'identificatore della coda il client compone il messaggio di richiesta (\texttt{\small 12--13}) in \var{msg\_read}, usando 1 -per il tipo ed inserendo il proprio \acr{pid} come dato da passare al server. +per il tipo ed inserendo il proprio \ids{PID} come dato da passare al server. Calcolata (\texttt{\small 14}) la dimensione, provvede (\texttt{\small 15}) ad immettere la richiesta sulla coda. A questo punto non resta che (\texttt{\small 16}) rileggere dalla coda la risposta del server richiedendo a \func{msgrcv} di selezionare i messaggi di -tipo corrispondente al valore del \acr{pid} inviato nella richiesta. L'ultimo +tipo corrispondente al valore del \ids{PID} inviato nella richiesta. L'ultimo passo (\texttt{\small 17}) prima di uscire è quello di stampare a video il messaggio ricevuto. @@ -1687,7 +1687,7 @@ della risposta, quest'ultima resta nella coda (così come per le fifo si aveva il problema delle fifo che restavano nel filesystem). In questo caso però il problemi sono maggiori, sia perché è molto più facile esaurire la memoria dedicata ad una coda di messaggi che gli \itindex{inode} inode di un filesystem, -sia perché, con il riutilizzo dei \acr{pid} da parte dei processi, un client +sia perché, con il riutilizzo dei \ids{PID} da parte dei processi, un client eseguito in un momento successivo potrebbe ricevere un messaggio non indirizzato a lui. @@ -1851,7 +1851,7 @@ I dati mantenuti nella struttura, ed elencati in fig.~\ref{fig:ipc_sem}, indicano rispettivamente: \begin{description*} \item[\var{semval}] il valore numerico del semaforo. -\item[\var{sempid}] il \acr{pid} dell'ultimo processo che ha eseguito una +\item[\var{sempid}] il \ids{PID} dell'ultimo processo che ha eseguito una operazione sul semaforo. \item[\var{semncnt}] il numero di processi in attesa che esso venga incrementato. @@ -1957,14 +1957,14 @@ seguenti: \item[\const{IPC\_RMID}] Rimuove l'insieme di semafori e le relative strutture dati, con effetto immediato. Tutti i processi che erano stato di \textit{sleep} vengono svegliati, ritornando con un errore di - \errcode{EIDRM}. L'\acr{uid} effettivo del processo deve corrispondere o al + \errcode{EIDRM}. L'\ids{UID} effettivo del processo deve corrispondere o al creatore o al proprietario dell'insieme, o all'amministratore. L'argomento \param{semnum} viene ignorato. \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario dell'insieme. I valori devono essere passati in una struttura \struct{semid\_ds} puntata da \param{arg.buf} di cui saranno usati soltanto i campi \var{sem\_perm.uid}, \var{sem\_perm.gid} e i nove bit meno - significativi di \var{sem\_perm.mode}. L'\acr{uid} effettivo del processo deve + significativi di \var{sem\_perm.mode}. L'\ids{UID} effettivo del processo deve corrispondere o al creatore o al proprietario dell'insieme, o all'amministratore. L'argomento \param{semnum} viene ignorato. \item[\const{GETALL}] Restituisce il valore corrente di ciascun semaforo @@ -1977,7 +1977,7 @@ seguenti: \struct{sem}); va invocata con tre argomenti. Occorre avere il permesso di lettura. \item[\const{GETPID}] Restituisce come valore di ritorno della funzione il - \acr{pid} dell'ultimo processo che ha compiuto una operazione sul semaforo + \ids{PID} dell'ultimo processo che ha compiuto una operazione sul semaforo \param{semnum} dell'insieme \param{semid} (corrispondente al campo \var{sempid} di \struct{sem}); va invocata con tre argomenti. Occorre avere il permesso di lettura. @@ -2159,7 +2159,7 @@ possibili: \end{basedescript} In caso di successo della funzione viene aggiornato il campo \var{sempid} per -ogni semaforo modificato al valore del \acr{pid} del processo chiamante; +ogni semaforo modificato al valore del \ids{PID} del processo chiamante; inoltre vengono pure aggiornati al tempo corrente i campi \var{sem\_otime} e \var{sem\_ctime}. @@ -2405,10 +2405,10 @@ invece: \item i campi \var{shm\_atime} e \var{shm\_dtime}, che esprimono rispettivamente il tempo dell'ultima volta che il segmento è stato agganciato o sganciato da un processo, vengono inizializzati a zero. -\item il campo \var{shm\_lpid}, che esprime il \acr{pid} del processo che ha +\item il campo \var{shm\_lpid}, che esprime il \ids{PID} del processo che ha eseguito l'ultima operazione, viene inizializzato a zero. -\item il campo \var{shm\_cpid}, che esprime il \acr{pid} del processo che ha - creato il segmento, viene inizializzato al \acr{pid} del processo chiamante. +\item il campo \var{shm\_cpid}, che esprime il \ids{PID} del processo che ha + creato il segmento, viene inizializzato al \ids{PID} del processo chiamante. \item il campo \var{shm\_nattac}, che esprime il numero di processi agganciati al segmento viene inizializzato a zero. \end{itemize} @@ -2485,7 +2485,7 @@ un segmento di memoria condivisa è \funcd{shmctl}; il suo prototipo è: \item[\errcode{EPERM}] si è specificato un comando con \const{IPC\_SET} o \const{IPC\_RMID} senza i permessi necessari. \item[\errcode{EOVERFLOW}] si è tentato il comando \const{IPC\_STAT} ma il - valore del \acr{gid} o dell'\acr{uid} è troppo grande per essere + valore del \ids{GID} o dell'\ids{UID} è troppo grande per essere memorizzato nella struttura puntata da \param{buf}. \item[\errcode{EFAULT}] l'indirizzo specificato con \param{buf} non è valido. @@ -2504,7 +2504,7 @@ corrispondente comportamento della funzione, sono i seguenti: \item[\const{IPC\_RMID}] Marca il segmento di memoria condivisa per la rimozione, questo verrà cancellato effettivamente solo quando l'ultimo processo ad esso agganciato si sarà staccato. Questo comando può essere - eseguito solo da un processo con \acr{uid} effettivo corrispondente o al + eseguito solo da un processo con \ids{UID} effettivo corrispondente o al creatore del segmento, o al proprietario del segmento, o all'amministratore. \item[\const{IPC\_SET}] Permette di modificare i permessi ed il proprietario del segmento. Per modificare i valori di \var{shm\_perm.mode}, @@ -2618,7 +2618,7 @@ In caso di successo la funzione aggiorna anche i seguenti campi di \begin{itemize*} \item il tempo \var{shm\_atime} dell'ultima operazione di aggancio viene impostato al tempo corrente. -\item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul +\item il \ids{PID} \var{shm\_lpid} dell'ultimo processo che ha operato sul segmento viene impostato a quello del processo corrente. \item il numero \var{shm\_nattch} di processi agganciati al segmento viene aumentato di uno. @@ -2659,7 +2659,7 @@ In caso di successo la funzione aggiorna anche i seguenti campi di \begin{itemize*} \item il tempo \var{shm\_dtime} dell'ultima operazione di sganciamento viene impostato al tempo corrente. -\item il \acr{pid} \var{shm\_lpid} dell'ultimo processo che ha operato sul +\item il \ids{PID} \var{shm\_lpid} dell'ultimo processo che ha operato sul segmento viene impostato a quello del processo corrente. \item il numero \var{shm\_nattch} di processi agganciati al segmento viene decrementato di uno. @@ -3324,7 +3324,7 @@ quella particolare (si ricordi quanto visto in sez.~\ref{sec:ipc_sysv_access_control}) che viene usata per gli oggetti del SysV IPC. Per quanto riguarda l'attribuzione dell'utente e del gruppo proprietari dell'oggetto alla creazione di quest'ultimo essa viene effettuata -secondo la semantica SysV: corrispondono cioè a \acr{uid} e \acr{gid} effettivi +secondo la semantica SysV: corrispondono cioè a \ids{UID} e \ids{GID} effettivi del processo che esegue la creazione. @@ -3772,7 +3772,7 @@ questa operazione prima di estrarre i messaggi presenti dalla coda. L'invio del segnale di notifica avvalora alcuni campi di informazione restituiti al gestore attraverso la struttura \struct{siginfo\_t} (definita in fig.~\ref{fig:sig_siginfo_t}). In particolare \var{si\_pid} viene impostato al -valore del \acr{pid} del processo che ha emesso il segnale, \var{si\_uid} +valore del \ids{PID} del processo che ha emesso il segnale, \var{si\_uid} all'userid effettivo, \var{si\_code} a \const{SI\_MESGQ}, e \var{si\_errno} a 0. Questo ci dice che, se si effettua la ricezione dei messaggi usando esclusivamente il meccanismo di notifica, è possibile ottenere le informazioni @@ -4055,8 +4055,8 @@ presente che, come accennato in sez.~\ref{sec:ipc_posix_generic}, i semafori usano la semantica standard dei file per quanto riguarda i controlli di accesso. -Questo significa che un nuovo semaforo viene sempre creato con l'\acr{uid} ed il -\acr{gid} effettivo del processo chiamante, e che i permessi indicati con +Questo significa che un nuovo semaforo viene sempre creato con l'\ids{UID} ed +il \ids{GID} effettivo del processo chiamante, e che i permessi indicati con \param{mode} vengono filtrati dal valore della \itindex{umask} \textit{umask} del processo. Inoltre per poter aprire un semaforo è necessario avere su di esso sia il permesso di lettura che quello di scrittura. diff --git a/macro.tex b/macro.tex index 939cc74..b557308 100644 --- a/macro.tex +++ b/macro.tex @@ -215,7 +215,13 @@ %\index{#1@{{\tt {#1}} (struttura dati)}!definizione di}\texttt{#1}% } % struttura dati \newcommand{\param}[1]{\texttt{#1}} % function parameter -\newcommand{\acr}[1]{\textsl{#1}} % acrostic (for pid, suid, ecc.) +\newcommand{\acr}[1]{\textsl{#1}} % acrostic (for glibc, ext2, ecc.) + +\newcommand{\ids}[1]{\textsl{#1}} % Identifier (PID, GID, UID, TID, ecc.) + + + + \newcommand{\itindex}[1]{% \index{#1@{\textit{#1}}}% diff --git a/prochand.tex b/prochand.tex index 7d4f474..933a828 100644 --- a/prochand.tex +++ b/prochand.tex @@ -44,8 +44,9 @@ generazione di nuovi processi è un'operazione privilegiata, una delle caratteristiche fondanti di Unix, che esamineremo in dettaglio più avanti, è che qualunque processo può a sua volta generarne altri. Ogni processo è identificato presso il sistema da un numero univoco, il cosiddetto -\textit{process identifier} o, più brevemente, \acr{pid}, assegnato in forma -progressiva (vedi sez.~\ref{sec:proc_pid}) quando il processo viene creato. +\itindex{Process~ID~(PID)} \textit{Process ID} o, più brevemente, \ids{PID}, +assegnato in forma progressiva (vedi sez.~\ref{sec:proc_pid}) quando il +processo viene creato. Una seconda caratteristica di un sistema unix-like è che la generazione di un processo è un'operazione separata rispetto al lancio di un programma. In @@ -62,7 +63,7 @@ per tutti i processi, con una sola eccezione, dato che ci deve essere un punto di partenza esiste un processo speciale (che normalmente è \cmd{/sbin/init}), che come abbiamo accennato in sez.~\ref{sec:intro_kern_and_sys} viene lanciato dal kernel alla conclusione della fase di avvio. Essendo questo il primo -processo lanciato dal sistema ha sempre il \acr{pid} uguale a 1 e non è figlio +processo lanciato dal sistema ha sempre il \ids{PID} uguale a 1 e non è figlio di nessun altro processo. Ovviamente \cmd{init} è un processo speciale che in genere si occupa di far @@ -130,7 +131,7 @@ che è progenitore di tutti gli altri processi.\footnote{in realtà questo non del tutto vero, in Linux, specialmente nelle versioni più recenti del kernel, ci sono alcuni processi speciali (come \cmd{keventd}, \cmd{kswapd}, ecc.) che pur comparendo nei comandi come figli di \cmd{init}, o con - \acr{pid} successivi ad uno, sono in realtà processi interni al kernel e che + \ids{PID} successivi ad uno, sono in realtà processi interni al kernel e che non rientrano in questa classificazione.} Il kernel mantiene una tabella dei processi attivi, la cosiddetta @@ -191,41 +192,41 @@ esecuzione fino alla successiva invocazione. Come accennato nella sezione precedente ogni processo viene identificato dal sistema da un numero identificativo univoco, il \textit{process ID} o -\acr{pid}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un +\ids{PID}. Questo è un tipo di dato standard, \type{pid\_t} che in genere è un intero con segno (nel caso di Linux e delle \acr{glibc} il tipo usato è \ctyp{int}). -Il \acr{pid} viene assegnato in forma progressiva ogni volta che un nuovo +Il \ids{PID} viene assegnato in forma progressiva ogni volta che un nuovo processo viene creato,\footnote{in genere viene assegnato il numero successivo a quello usato per l'ultimo processo creato, a meno che questo numero non - sia già utilizzato per un altro \acr{pid}, \acr{pgid} o \acr{sid} (vedi + sia già utilizzato per un altro \ids{PID}, \acr{pgid} o \acr{sid} (vedi sez.~\ref{sec:sess_proc_group}).} fino ad un limite che, essendo il -tradizionalmente il \acr{pid} un numero positivo memorizzato in un intero a 16 +tradizionalmente il \ids{PID} un numero positivo memorizzato in un intero a 16 bit, arriva ad un massimo di 32768. Oltre questo valore l'assegnazione riparte dal numero più basso disponibile a partire da un minimo di 300,\footnote{questi valori, fino al kernel 2.4.x, erano definiti dalla macro \const{PID\_MAX} nei file \file{threads.h} e \file{fork.c} dei sorgenti del kernel, con il 2.6.x e la nuova interfaccia per i \itindex{thread} - \textit{thread} anche il meccanismo di allocazione dei \acr{pid} è stato + \textit{thread} anche il meccanismo di allocazione dei \ids{PID} è stato modificato ed il valore massimo è impostabile attraverso il file \sysctlfile{kernel/pid\_max} e di default vale 32768.} che serve a -riservare i \acr{pid} più bassi ai processi eseguiti direttamente dal kernel. +riservare i \ids{PID} più bassi ai processi eseguiti direttamente dal kernel. Per questo motivo, come visto in sez.~\ref{sec:proc_hierarchy}, il processo di -avvio (\cmd{init}) ha sempre il \acr{pid} uguale a uno. +avvio (\cmd{init}) ha sempre il \ids{PID} uguale a uno. -Tutti i processi inoltre memorizzano anche il \acr{pid} del genitore da cui -sono stati creati, questo viene chiamato in genere \acr{ppid} (da -\textit{parent process ID}). Questi due identificativi possono essere -ottenuti usando le due funzioni \funcd{getpid} e \funcd{getppid}, i cui -prototipi sono: +Tutti i processi inoltre memorizzano anche il \ids{PID} del genitore da cui +sono stati creati, questo viene chiamato in genere \ids{PPID} (da +\itindex{Parent~Process~ID~(PPID)} \textit{Parent Process ID}). Questi due +identificativi possono essere ottenuti usando le due funzioni \funcd{getpid} e +\funcd{getppid}, i cui prototipi sono: \begin{funcproto}{ \fhead{sys/types.h} \fhead{unistd.h} \fdecl{pid\_t getpid(void)} -\fdesc{Restituisce il \acr{pid} del processo corrente..} +\fdesc{Restituisce il \ids{PID} del processo corrente..} \fdecl{pid\_t getppid(void)} -\fdesc{Restituisce il \acr{pid} del padre del processo corrente.} +\fdesc{Restituisce il \ids{PID} del padre del processo corrente.} } {Entrambe le funzioni non riportano condizioni di errore.} \end{funcproto} @@ -233,13 +234,13 @@ prototipi sono: \noindent esempi dell'uso di queste funzioni sono riportati in fig.~\ref{fig:proc_fork_code}, nel programma \file{ForkTest.c}. -Il fatto che il \acr{pid} sia un numero univoco per il sistema lo rende un +Il fatto che il \ids{PID} sia un numero univoco per il sistema lo rende un candidato per generare ulteriori indicatori associati al processo di cui diventa possibile garantire l'unicità: ad esempio in alcune implementazioni la funzione \func{tempnam} (si veda sez.~\ref{sec:file_temp_file}) usa il -\acr{pid} per generare un \itindex{pathname} \textit{pathname} univoco, che +\ids{PID} per generare un \itindex{pathname} \textit{pathname} univoco, che non potrà essere replicato da un altro processo che usi la stessa -funzione. Questo utilizzo però può risultare pericoloso, un \acr{pid} infatti +funzione. Questo utilizzo però può risultare pericoloso, un \ids{PID} infatti è univoco solo fintanto che un processo è attivo, una volta terminato esso potrà essere riutilizzato da un processo completamente diverso, e di questo bisogna essere ben consapevoli. @@ -252,7 +253,7 @@ cap.~\ref{cha:session}, dove esamineremo gli altri identificativi associati ad un processo e le varie relazioni fra processi utilizzate per definire una sessione. -Oltre al \acr{pid} e al \acr{ppid}, e a quelli che vedremo in +Oltre al \ids{PID} e al \ids{PPID}, e a quelli che vedremo in sez.~\ref{sec:sess_proc_group}, relativi al controllo di sessione, ad ogni processo vengono associati degli ulteriori identificatori ed in particolare quelli che vengono usati per il controllo di accesso. Questi servono per @@ -284,7 +285,7 @@ multitasking.\footnote{oggi questa rilevanza, con la diffusione dell'uso dei \fdecl{pid\_t fork(void)} \fdesc{Crea un nuovo processo.} } -{La funzione ritorna il \acr{pid} del figlio al padre e $0$ al figlio in caso +{La funzione ritorna il \ids{PID} del figlio al padre e $0$ al figlio in caso di successo e $-1$ al padre senza creare il figlio per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} @@ -319,7 +320,7 @@ degli indirizzi virtuali del padre, ma solo delle pagine di memoria che sono state modificate, e solo al momento della modifica stessa. La differenza che si ha nei due processi è che nel processo padre il valore di -ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre +ritorno della funzione \func{fork} è il \ids{PID} del processo figlio, mentre nel figlio è zero; in questo modo il programma può identificare se viene eseguito dal padre o dal figlio. Si noti come la funzione \func{fork} ritorni due volte, una nel padre e una nel figlio. @@ -327,9 +328,9 @@ due volte, una nel padre e una nel figlio. La scelta di questi valori di ritorno non è casuale, un processo infatti può avere più figli, ed il valore di ritorno di \func{fork} è l'unico modo che gli permette di identificare quello appena creato. Al contrario un figlio ha -sempre un solo padre, il cui \acr{pid} può sempre essere ottenuto con +sempre un solo padre, il cui \ids{PID} può sempre essere ottenuto con \func{getppid}, come spiegato in sez.~\ref{sec:proc_pid}, per cui si usa il -valore nullo, che non è il \acr{pid} di nessun processo. +valore nullo, che non è il \ids{PID} di nessun processo. Normalmente la chiamata a \func{fork} può fallire solo per due ragioni: o ci sono già troppi processi nel sistema, il che di solito è sintomo che @@ -427,7 +428,7 @@ Esaminiamo questo risultato: una prima conclusione che si può trarre è che non si può dire quale processo fra il padre ed il figlio venga eseguito per primo dopo la chiamata a \func{fork}; dall'esempio si può notare infatti come nei primi due cicli sia stato eseguito per primo il padre (con la stampa del -\acr{pid} del nuovo processo) per poi passare all'esecuzione del figlio +\ids{PID} del nuovo processo) per poi passare all'esecuzione del figlio (completata con i due avvisi di esecuzione ed uscita), e tornare all'esecuzione del padre (con la stampa del passaggio al ciclo successivo), mentre la terza volta è stato prima eseguito il figlio (fino alla conclusione) @@ -637,10 +638,10 @@ una \func{fork} invece sono:\footnote{a parte le ultime quattro, relative a dallo standard POSIX.1-2001.} \begin{itemize*} \item il valore di ritorno di \func{fork}; -\item il \acr{pid} (\textit{process id}), quello del figlio viene assegnato ad +\item il \ids{PID} (\textit{process id}), quello del figlio viene assegnato ad un nuovo valore univoco; -\item il \acr{ppid} (\textit{parent process id}), quello del figlio viene - impostato al \acr{pid} del padre; +\item il \ids{PPID} (\textit{parent process id}), quello del figlio viene + impostato al \ids{PID} del padre; \item i valori dei tempi di esecuzione (vedi sez.~\ref{sec:sys_cpu_times}) e delle risorse usate (vedi sez.~\ref{sec:sys_resource_use}), che nel figlio sono posti a zero; @@ -764,7 +765,7 @@ terminato; si potrebbe avere cioè quello che si chiama un processo \textsl{orfano}. Questa complicazione viene superata facendo in modo che il processo orfano -venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \acr{pid} 1, +venga \textsl{adottato} da \cmd{init}, o meglio dal processo con \ids{PID} 1, cioè quello lanciato direttamente dal kernel all'avvio, che sta alla base dell'albero dei processi visto in sez.~\ref{sec:proc_hierarchy} e che anche per questo motivo ha un ruolo essenziale nel sistema e non può mai @@ -774,8 +775,8 @@ terminare.\footnote{almeno non senza un blocco completo del sistema, in caso fatale.} Come già accennato quando un processo termina, il kernel controlla se è il -padre di altri processi in esecuzione: in caso positivo allora il \acr{ppid} -di tutti questi processi verrà sostituito dal kernel con il \acr{pid} di +padre di altri processi in esecuzione: in caso positivo allora il \ids{PPID} +di tutti questi processi verrà sostituito dal kernel con il \ids{PID} di \cmd{init}, cioè con 1. In questo modo ogni processo avrà sempre un padre (nel caso possiamo parlare di un padre \textsl{adottivo}) cui riportare il suo stato di terminazione. @@ -806,7 +807,7 @@ come si può notare in questo caso il processo padre si conclude prima dei figli, tornando alla shell, che stampa il prompt sul terminale: circa due secondi dopo viene stampato a video anche l'output dei tre figli che terminano, e come si può notare in questo caso, al contrario di quanto visto -in precedenza, essi riportano 1 come \acr{ppid}. +in precedenza, essi riportano 1 come \ids{PPID}. Altrettanto rilevante è il caso in cui il figlio termina prima del padre, perché non è detto che il padre possa ricevere immediatamente lo stato di @@ -814,7 +815,7 @@ terminazione, quindi il kernel deve comunque conservare una certa quantità di informazioni riguardo ai processi che sta terminando. Questo viene fatto mantenendo attiva la voce nella tabella dei processi, e -memorizzando alcuni dati essenziali, come il \acr{pid}, i tempi di CPU usati +memorizzando alcuni dati essenziali, come il \ids{PID}, i tempi di CPU usati dal processo (vedi sez.~\ref{sec:sys_unix_time}) e lo stato di terminazione, mentre la memoria in uso ed i file aperti vengono rilasciati immediatamente. @@ -903,7 +904,7 @@ la prima è \funcd{wait} ed il suo prototipo è: \fdecl{pid\_t wait(int *status)} \fdesc{Attende la terminazione di un processo.} } -{La funzione ritorna il \acr{pid} del figlio in caso di successo e $-1$ per un +{La funzione ritorna il \ids{PID} del figlio in caso di successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{ECHILD}] il processo non ha nessun figlio di cui attendere @@ -925,7 +926,7 @@ Al ritorno della funzione lo stato di terminazione del figlio viene salvato variabile puntata da \param{status} e tutte le risorse del kernel relative al processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate. Nel caso un processo abbia più figli il valore di ritorno della funzione sarà impostato -al \acr{pid} del processo di cui si è ricevuto lo stato di terminazione, cosa +al \ids{PID} del processo di cui si è ricevuto lo stato di terminazione, cosa che permette di identificare qual è il figlio che è terminato. \itindend{termination~status} @@ -955,7 +956,7 @@ comportamento di \func{wait}\footnote{in effetti il codice \fdecl{pid\_t waitpid(pid\_t pid, int *status, int options)} \fdesc{Attende il cambiamento di stato di un processo figlio.} } -{La funzione ritorna il \acr{pid} del processo che ha cambiato stato in caso +{La funzione ritorna il \ids{PID} del processo che ha cambiato stato in caso di successo, o 0 se è stata specificata l'opzione \const{WNOHANG} e il processo non è uscito e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori: @@ -994,7 +995,7 @@ sono riportate anche le costanti definite per indicare alcuni di essi. \itindex{process~group} \textit{process group} (vedi sez.~\ref{sec:sess_proc_group}) è uguale a quello del processo chiamante.\\ - $>0$& -- & Attende per un figlio il cui \acr{pid} è uguale + $>0$& -- & Attende per un figlio il cui \ids{PID} è uguale al valore di \param{pid}.\\ \hline \end{tabular} @@ -1058,7 +1059,7 @@ sez.~\ref{sec:thread_xxx}). L'uso dell'opzione \const{WNOHANG} consente di prevenire il blocco della funzione qualora nessun figlio sia uscito o non si siano verificate le altre condizioni per l'uscita della funzione. in tal caso. In tal caso la funzione, -invece di restituire il \acr{pid} del processo (che è sempre un intero +invece di restituire il \ids{PID} del processo (che è sempre un intero positivo) ritornerà un valore nullo. Le altre due opzioni, \const{WUNTRACED} e \const{WCONTINUED}, consentono @@ -1066,7 +1067,7 @@ rispettivamente di tracciare non la terminazione di un processo, ma il fatto che esso sia stato fermato, o fatto ripartire, e sono utilizzate per la gestione del controllo di sessione (vedi sez.~\ref{sec:sess_job_control}). -Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \acr{pid}, +Nel caso di \const{WUNTRACED} la funzione ritorna, restituendone il \ids{PID}, quando un processo figlio entra nello stato \textit{stopped}\footnote{in realtà viene notificato soltanto il caso in cui il processo è stato fermato da un segnale di stop (vedi sez.~\ref{sec:sess_ctrl_term}), e non quello in @@ -1105,7 +1106,7 @@ nello stesso modo,\footnote{lo standard POSIX.1 originale infatti lascia indefinito il comportamento di queste funzioni quando \signal{SIGCHLD} viene ignorato.} indipendentemente dal fatto \signal{SIGCHLD} sia ignorato o meno: attendono la terminazione di un processo figlio e ritornano il relativo -\acr{pid} e lo stato di terminazione nell'argomento \param{status}. +\ids{PID} e lo stato di terminazione nell'argomento \param{status}. In generale in un programma non si vuole essere forzati ad attendere la conclusione di un processo figlio per proseguire l'esecuzione, specie se tutto @@ -1239,7 +1240,7 @@ primo, quale processo o quale gruppo di processi selezionare. \hline \hline \const{P\_PID} & Indica la richiesta di attendere per un processo figlio - il cui \acr{pid} corrisponda al valore dell'argomento + il cui \ids{PID} corrisponda al valore dell'argomento \param{id}.\\ \const{P\_PGID}& Indica la richiesta di attendere per un processo figlio appartenente al \textit{process group} (vedi @@ -1306,7 +1307,7 @@ suoi vari campi in sez.~\ref{sec:sig_sigaction}, per quanto ci interessa qui basta dire che al ritorno di \func{waitid} verranno avvalorati i seguenti campi: \begin{basedescript}{\desclabelwidth{2.0cm}} -\item[\var{si\_pid}] con il \acr{pid} del figlio. +\item[\var{si\_pid}] con il \ids{PID} del figlio. \item[\var{si\_uid}] con l'\textsl{user-ID reale} (vedi sez.~\ref{sec:proc_perms}) del figlio. \item[\var{si\_signo}] con \signal{SIGCHLD}. @@ -1365,7 +1366,7 @@ Abbiamo già detto che una delle modalità principali con cui si utilizzano i processi in Unix è quella di usarli per lanciare nuovi programmi: questo viene fatto attraverso una delle funzioni della famiglia \func{exec}. Quando un processo chiama una di queste funzioni esso viene completamente sostituito dal -nuovo programma, il \acr{pid} del processo non cambia, dato che non viene +nuovo programma, il \ids{PID} del processo non cambia, dato che non viene creato un nuovo processo, la funzione semplicemente rimpiazza lo \itindex{stack} \textit{stack}, i \index{segmento!dati} dati ed il \index{segmento!testo} testo del processo corrente con un nuovo programma @@ -1530,13 +1531,13 @@ usano il valore della variabile \var{environ} (vedi sez.~\ref{sec:proc_environ}) del processo di partenza per costruire l'ambiente. -Oltre a mantenere lo stesso \acr{pid}, il nuovo programma fatto partire da una +Oltre a mantenere lo stesso \ids{PID}, il nuovo programma fatto partire da una delle funzioni della famiglia \func{exec} mantiene la gran parte delle proprietà del processo chiamante; una lista delle più significative è la seguente: \begin{itemize*} -\item il \textit{process id} (\acr{pid}) ed il \textit{parent process id} - (\acr{ppid}); +\item il \textit{process id} (\ids{PID}) ed il \textit{parent process id} + (\ids{PPID}); \item l'\textsl{user-ID reale}, il \textit{group-ID reale} ed i \textsl{group-ID supplementari} (vedi sez.~\ref{sec:proc_access_id}); \item la directory radice e la directory di lavoro corrente (vedi @@ -1714,14 +1715,15 @@ restrizioni, ed il resto degli utenti, per i quali invece vengono effettuati i vari controlli di accesso. Abbiamo già accennato come il sistema associ ad ogni utente e gruppo due -identificatori univoci, lo \textsl{user-ID} (abbreviato in \acr{uid}) ed il -\textsl{group-ID} (abbreviato in \acr{gid}). Questi servono al kernel per -identificare uno specifico utente o un gruppo di utenti, per poi poter -controllare che essi siano autorizzati a compiere le operazioni richieste. Ad -esempio in sez.~\ref{sec:file_access_control} vedremo come ad ogni file -vengano associati un utente ed un gruppo (i suoi \textsl{proprietari}, -indicati appunto tramite un \acr{uid} ed un \acr{gid}) che vengono controllati -dal kernel nella gestione dei permessi di accesso. +identificatori univoci, lo \itindex{User~ID~(PID)} \textsl{User-ID} +(abbreviato in \ids{UID}) ed il \itindex{Group~ID~(PID)} \textsl{Group-ID} +(abbreviato in \ids{GID}). Questi servono al kernel per identificare uno +specifico utente o un gruppo di utenti, per poi poter controllare che essi +siano autorizzati a compiere le operazioni richieste. Ad esempio in +sez.~\ref{sec:file_access_control} vedremo come ad ogni file vengano associati +un utente ed un gruppo (i suoi \textsl{proprietari}, indicati appunto tramite +un \ids{UID} ed un \ids{GID}) che vengono controllati dal kernel nella +gestione dei permessi di accesso. Dato che tutte le operazioni del sistema vengono compiute dai processi, è evidente che per poter implementare un controllo sulle operazioni occorre @@ -1742,34 +1744,34 @@ in tab.~\ref{tab:proc_uid_gid}. \begin{table}[htb] \footnotesize \centering - \begin{tabular}[c]{|c|c|l|p{7.3cm}|} + \begin{tabular}[c]{|c|c|l|p{7cm}|} \hline \textbf{Suffisso} & \textbf{Gruppo} & \textbf{Denominazione} & \textbf{Significato} \\ \hline \hline - \acr{uid} & \textit{real} & \textsl{user-ID reale} - & Indica l'utente che ha lanciato il programma.\\ - \acr{gid} & '' &\textsl{group-ID reale} - & Indica il gruppo principale dell'utente che ha lanciato - il programma.\\ + \texttt{uid} & \textit{real} & \textsl{user-ID reale} + & Indica l'utente che ha lanciato il programma.\\ + \texttt{gid} & '' &\textsl{group-ID reale} + & Indica il gruppo principale dell'utente che ha lanciato + il programma.\\ \hline - \acr{euid} & \textit{effective} &\textsl{user-ID effettivo} - & Indica l'utente usato nel controllo di accesso.\\ - \acr{egid} & '' & \textsl{group-ID effettivo} - & Indica il gruppo usato nel controllo di accesso.\\ - -- & -- & \textsl{group-ID supplementari} - & Indicano gli ulteriori gruppi cui l'utente appartiene.\\ + \texttt{euid}& \textit{effective} &\textsl{user-ID effettivo} + & Indica l'utente usato nel controllo di accesso.\\ + \texttt{egid}& '' & \textsl{group-ID effettivo} + & Indica il gruppo usato nel controllo di accesso.\\ + -- & -- & \textsl{group-ID supplementari} + & Indicano gli ulteriori gruppi cui l'utente appartiene.\\ \hline - -- & \textit{saved} & \textsl{user-ID salvato} - & È una copia dell'\acr{euid} iniziale.\\ - -- & '' & \textsl{group-ID salvato} - & È una copia dell'\acr{egid} iniziale.\\ + -- & \textit{saved} & \textsl{user-ID salvato} + & Mantiene una copia dell'\acr{euid} iniziale.\\ + -- & '' & \textsl{group-ID salvato} + & Mantiene una copia dell'\acr{egid} iniziale.\\ \hline - \acr{fsuid} & \textit{filesystem} &\textsl{user-ID di filesystem} - & Indica l'utente effettivo per l'accesso al filesystem. \\ - \acr{fsgid} & '' & \textsl{group-ID di filesystem} - & Indica il gruppo effettivo per l'accesso al filesystem.\\ + \texttt{fsuid}& \textit{filesystem} &\textsl{user-ID di filesystem} + & Indica l'utente effettivo per l'accesso al filesystem. \\ + \texttt{fsgid}& '' & \textsl{group-ID di filesystem} + & Indica il gruppo effettivo per l'accesso al filesystem.\\ \hline \end{tabular} \caption{Identificatori di utente e gruppo associati a ciascun processo con @@ -1777,7 +1779,7 @@ in tab.~\ref{tab:proc_uid_gid}. \label{tab:proc_uid_gid} \end{table} -Al primo gruppo appartengono l'\acr{uid} \textsl{reale} ed il \acr{gid} +Al primo gruppo appartengono l'\ids{UID} \textsl{reale} ed il \ids{GID} \textsl{reale}: questi vengono impostati al login ai valori corrispondenti all'utente con cui si accede al sistema (e relativo gruppo principale). Servono per l'identificazione dell'utente e normalmente non vengono mai @@ -1788,8 +1790,8 @@ completata la procedura di autenticazione, lancia una shell per la quale imposta questi identificatori ai valori corrispondenti all'utente che entra nel sistema. -Al secondo gruppo appartengono l'\acr{uid} \textsl{effettivo} e il \acr{gid} -\textsl{effettivo}, a cui si aggiungono gli eventuali \acr{gid} +Al secondo gruppo appartengono l'\ids{UID} \textsl{effettivo} e il \ids{GID} +\textsl{effettivo}, a cui si aggiungono gli eventuali \ids{GID} \textsl{supplementari} dei gruppi dei quali l'utente fa parte. Questi sono invece gli identificatori usati nelle verifiche dei permessi del processo e per il controllo di accesso ai file (argomento affrontato in dettaglio in @@ -1805,7 +1807,7 @@ all'utente e al gruppo proprietari del file. Questo consente, per programmi in cui ci sia questa necessità, di dare a qualunque utente i privilegi o i permessi di un altro, compreso l'amministratore. -Come nel caso del \acr{pid} e del \acr{ppid}, anche tutti questi +Come nel caso del \ids{PID} e del \ids{PPID}, anche tutti questi identificatori possono essere ottenuti da un programma attraverso altrettante funzioni di lettura, queste sono \funcd{getuid}, \funcd{geteuid}, \funcd{getgid} e \funcd{getegid}, ed i loro prototipi sono: @@ -1814,19 +1816,19 @@ funzioni di lettura, queste sono \funcd{getuid}, \funcd{geteuid}, \fhead{unistd.h} \fhead{sys/types.h} \fdecl{uid\_t getuid(void)} -\fdesc{Legge l'\acr{uid} reale del processo corrente.} +\fdesc{Legge l'\ids{UID} reale del processo corrente.} \fdecl{uid\_t geteuid(void)} -\fdesc{Legge l'\acr{uid} effettivo del processo corrente.} +\fdesc{Legge l'\ids{UID} effettivo del processo corrente.} \fdecl{gid\_t getgid(void)} -\fdesc{Legge il \acr{gid} reale del processo corrente.} +\fdesc{Legge il \ids{GID} reale del processo corrente.} \fdecl{gid\_t getegid(void)} -\fdesc{Legge il \acr{gid} effettivo del processo corrente.} +\fdesc{Legge il \ids{GID} effettivo del processo corrente.} } {Le funzioni ritornano i rispettivi identificativi del processo corrente, e non sono previste condizioni di errore.} \end{funcproto} -In generale l'uso di privilegi superiori, ottenibile con un \acr{uid} +In generale l'uso di privilegi superiori, ottenibile con un \ids{UID} \textsl{effettivo} diverso da quello reale, deve essere limitato il più possibile, per evitare abusi e problemi di sicurezza, per questo occorre anche un meccanismo che consenta ad un programma di rilasciare gli eventuali @@ -1844,16 +1846,16 @@ SVr4, e previsto dallo standard POSIX quando è definita la costante migliorare la sicurezza con NFS (il \textit{Network File System}, protocollo che consente di accedere ai file via rete). -L'\acr{uid} \textsl{salvato} ed il \acr{gid} \textsl{salvato} sono copie -dell'\acr{uid} \textsl{effettivo} e del \acr{gid} \textsl{effettivo} del +L'\ids{UID} \textsl{salvato} ed il \ids{GID} \textsl{salvato} sono copie +dell'\ids{UID} \textsl{effettivo} e del \ids{GID} \textsl{effettivo} del processo padre, e vengono impostati dalla funzione \func{exec} all'avvio del -processo, come copie dell'\acr{uid} \textsl{effettivo} e del \acr{gid} +processo, come copie dell'\ids{UID} \textsl{effettivo} e del \ids{GID} \textsl{effettivo} dopo che questi sono stati impostati tenendo conto di eventuali \itindex{suid~bit} \acr{suid} o \itindex{sgid~bit} \acr{sgid}. Essi quindi consentono di tenere traccia di quale fossero utente e gruppo effettivi all'inizio dell'esecuzione di un nuovo programma. -L'\acr{uid} \textsl{di filesystem} e il \acr{gid} \textsl{di filesystem} sono +L'\ids{UID} \textsl{di filesystem} e il \ids{GID} \textsl{di filesystem} sono un'estensione introdotta in Linux per rendere più sicuro l'uso di NFS (torneremo sull'argomento in sez.~\ref{sec:proc_setuid}). Essi sono una replica dei corrispondenti identificatori del gruppo \textit{effective}, ai @@ -1871,16 +1873,16 @@ Le due funzioni più comuni che vengono usate per cambiare identità (cioè utente e gruppo di appartenenza) ad un processo sono rispettivamente \funcd{setuid} e \funcd{setgid}; come accennato in sez.~\ref{sec:proc_access_id} in Linux esse seguono la semantica POSIX che -prevede l'esistenza dell'\acr{uid} salvato e del \acr{gid} salvato; i loro +prevede l'esistenza dell'\ids{UID} salvato e del \ids{GID} salvato; i loro prototipi sono: \begin{funcproto}{ \fhead{unistd.h} \fhead{sys/types.h} \fdecl{int setuid(uid\_t uid)} -\fdesc{Imposta l'\acr{uid} del processo corrente.} +\fdesc{Imposta l'\ids{UID} del processo corrente.} \fdecl{int setgid(gid\_t gid)} -\fdesc{Imposta il \acr{gid} del processo corrente.} +\fdesc{Imposta il \ids{GID} del processo corrente.} } {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} può assumere solo il valore \errcode{EPERM}. @@ -1889,21 +1891,21 @@ caso \var{errno} può assumere solo il valore \errcode{EPERM}. Il funzionamento di queste due funzioni è analogo, per cui considereremo solo la prima, la seconda si comporta esattamente allo stesso modo facendo -riferimento al \acr{gid} invece che all'\acr{uid}. Gli eventuali \acr{gid} +riferimento al \ids{GID} invece che all'\ids{UID}. Gli eventuali \ids{GID} supplementari non vengono modificati. L'effetto della chiamata è diverso a seconda dei privilegi del processo; se -l'\acr{uid} effettivo è zero (cioè è quello dell'amministratore di sistema) +l'\ids{UID} effettivo è zero (cioè è quello dell'amministratore di sistema) allora tutti gli identificatori (\textit{real}, \textit{effective} e \textit{saved}) vengono impostati al valore specificato da \param{uid}, -altrimenti viene impostato solo l'\acr{uid} effettivo, e soltanto se il valore -specificato corrisponde o all'\acr{uid} reale o all'\acr{uid} salvato. Negli +altrimenti viene impostato solo l'\ids{UID} effettivo, e soltanto se il valore +specificato corrisponde o all'\ids{UID} reale o all'\ids{UID} salvato. Negli altri casi viene segnalato un errore con \errcode{EPERM}. 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_special_perm}) di riportare l'\acr{uid} effettivo a quello +sez.~\ref{sec:file_special_perm}) di riportare l'\ids{UID} effettivo a quello dell'utente che ha lanciato il programma, effettuare il lavoro che non necessita di privilegi aggiuntivi, ed eventualmente tornare indietro. @@ -1922,7 +1924,7 @@ Quando uno di questi programmi (ad esempio \cmd{xterm}) viene lanciato, la situazione degli identificatori è la seguente: \begin{eqnarray*} \label{eq:1} - \textsl{group-ID reale} &=& \textrm{\acr{gid} (del chiamante)} \\ + \textsl{group-ID reale} &=& \textrm{\ids{GID} (del chiamante)} \\ \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\ \textsl{group-ID salvato} &=& \textrm{\acr{utmp}} \end{eqnarray*} @@ -1935,11 +1937,11 @@ non sarà possibile lanciare dal terminale programmi che modificano detto file, in tal caso infatti la situazione degli identificatori sarebbe: \begin{eqnarray*} \label{eq:2} - \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\ - \textsl{group-ID effettivo} &=& \textrm{\acr{gid}} \\ + \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\ + \textsl{group-ID effettivo} &=& \textrm{\ids{GID}} \\ \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)} \end{eqnarray*} -e ogni processo lanciato dal terminale avrebbe comunque \acr{gid} come +e ogni processo lanciato dal terminale avrebbe comunque \ids{GID} come \textsl{group-ID effettivo}. All'uscita dal terminale, per poter di nuovo aggiornare lo stato di \sysfile{/var/run/utmp} il programma eseguirà una \code{setgid(utmp)} (dove \var{utmp} è il valore numerico associato al gruppo @@ -1948,7 +1950,7 @@ in questo caso il valore richiesto corrisponde al \textsl{group-ID salvato} la funzione avrà successo e riporterà la situazione a: \begin{eqnarray*} \label{eq:3} - \textsl{group-ID reale} &=& \textrm{\acr{gid} (invariato)} \\ + \textsl{group-ID reale} &=& \textrm{\ids{GID} (invariato)} \\ \textsl{group-ID effettivo} &=& \textrm{\acr{utmp}} \\ \textsl{group-ID salvato} &=& \textrm{\acr{utmp} (invariato)} \end{eqnarray*} @@ -1960,7 +1962,7 @@ i privilegi di amministratore, in tal caso infatti l'esecuzione di una processo, rendendo impossibile riguadagnare i privilegi di amministratore. Questo comportamento è corretto per l'uso che ne fa \cmd{login} una volta che crea una nuova shell per l'utente, ma quando si vuole cambiare soltanto -l'\acr{uid} effettivo del processo per cedere i privilegi occorre +l'\ids{UID} effettivo del processo per cedere i privilegi occorre ricorrere ad altre funzioni. Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non @@ -1972,9 +1974,9 @@ supportando (almeno fino alla versione 4.3+BSD) gli identificatori del gruppo \fhead{unistd.h} \fhead{sys/types.h} \fdecl{int setreuid(uid\_t ruid, uid\_t euid)} -\fdesc{Imposta \acr{uid} reale e \acr{uid} effettivo del processo corrente.} +\fdesc{Imposta \ids{UID} reale e \ids{UID} effettivo del processo corrente.} \fdecl{int setregid(gid\_t rgid, gid\_t egid)} -\fdesc{Imposta \acr{gid} reale e \acr{gid} effettivo del processo corrente.} +\fdesc{Imposta \ids{GID} reale e \ids{GID} effettivo del processo corrente.} } {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} può assumere solo il valore \errcode{EPERM}. @@ -1982,17 +1984,17 @@ caso \var{errno} può assumere solo il valore \errcode{EPERM}. \end{funcproto} Le due funzioni sono identiche, quanto diremo per la prima riguardo gli -\acr{uid} si applica alla seconda per i \acr{gid}. La funzione -\func{setreuid} imposta rispettivamente l'\acr{uid} reale e l'\acr{uid} +\ids{UID} si applica alla seconda per i \ids{GID}. La funzione +\func{setreuid} imposta rispettivamente l'\ids{UID} reale e l'\ids{UID} effettivo del processo corrente ai valori specificati da \param{ruid} e \param{euid}. I processi non privilegiati possono impostare solo valori che -corrispondano o al loro \acr{uid} effettivo o a quello reale o a quello +corrispondano o al loro \ids{UID} effettivo o a quello reale o a quello salvato, valori diversi comportano il fallimento della chiamata. L'amministratore invece può specificare un valore qualunque. Specificando un argomento di valore $-1$ l'identificatore corrispondente verrà lasciato inalterato. -Con queste funzioni si possono scambiare fra loro gli \acr{uid} reale ed +Con queste funzioni si possono scambiare fra loro gli \ids{UID} reale ed effettivo, e pertanto è possibile implementare un comportamento simile a quello visto in precedenza per \func{setgid}, cedendo i privilegi con un primo scambio, e recuperandoli, una volta eseguito il lavoro non privilegiato, con @@ -2000,20 +2002,20 @@ un secondo scambio. In questo caso però occorre porre molta attenzione quando si creano nuovi processi nella fase intermedia in cui si sono scambiati gli identificatori, in -questo caso infatti essi avranno un \acr{uid} reale privilegiato, che dovrà +questo caso infatti essi avranno un \ids{UID} reale privilegiato, che dovrà essere esplicitamente eliminato prima di porre in esecuzione un nuovo programma, occorrerà cioè eseguire un'altra chiamata dopo la \func{fork} e -prima della \func{exec} per uniformare l'\acr{uid} reale a quello effettivo, +prima della \func{exec} per uniformare l'\ids{UID} reale a quello effettivo, perché in caso contrario il nuovo programma potrebbe a sua volta effettuare uno scambio e riottenere dei privilegi non previsti. Lo stesso problema di propagazione dei privilegi ad eventuali processi figli -si pone anche per l'\acr{uid} salvato. Ma la funzione \func{setreuid} deriva +si pone anche per l'\ids{UID} salvato. Ma la funzione \func{setreuid} deriva da un'implementazione di sistema che non ne prevede la presenza, e quindi non è possibile usarla per correggere la situazione come nel caso precedente. Per questo motivo in Linux tutte le volte che si imposta un qualunque valore -diverso da quello dall'\acr{uid} reale corrente, l'\acr{uid} salvato viene -automaticamente uniformato al valore dell'\acr{uid} effettivo. +diverso da quello dall'\ids{UID} reale corrente, l'\ids{UID} salvato viene +automaticamente uniformato al valore dell'\ids{UID} effettivo. Altre due funzioni, \funcd{seteuid} e \funcd{setegid}, sono un'estensione dello standard POSIX.1, ma sono comunque supportate dalla maggior parte degli @@ -2024,9 +2026,9 @@ Unix, esse vengono usate per cambiare gli identificatori del gruppo \fhead{unistd.h} \fhead{sys/types.h} \fdecl{int seteuid(uid\_t uid)} -\fdesc{Imposta l'\acr{uid} effettivo del processo corrente.} +\fdesc{Imposta l'\ids{UID} effettivo del processo corrente.} \fdecl{int setegid(gid\_t gid)} -\fdesc{Imposta il \acr{gid} effettivo del processo corrente.} +\fdesc{Imposta il \ids{GID} effettivo del processo corrente.} } {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} può assumere solo il valore \errcode{EPERM}. @@ -2034,11 +2036,11 @@ caso \var{errno} può assumere solo il valore \errcode{EPERM}. \end{funcproto} Ancora una volta le due funzioni sono identiche, e quanto diremo per la prima -riguardo gli \acr{uid} si applica allo stesso modo alla seconda per i -\acr{gid}. Con \func{seteuid} gli utenti normali possono impostare l'\acr{uid} -effettivo solo al valore dell'\acr{uid} reale o dell'\acr{uid} salvato, +riguardo gli \ids{UID} si applica allo stesso modo alla seconda per i +\ids{GID}. Con \func{seteuid} gli utenti normali possono impostare l'\ids{UID} +effettivo solo al valore dell'\ids{UID} reale o dell'\ids{UID} salvato, l'amministratore può specificare qualunque valore. Queste funzioni sono usate -per permettere all'amministratore di impostare solo l'\acr{uid} effettivo, +per permettere all'amministratore di impostare solo l'\ids{UID} effettivo, dato che l'uso normale di \func{setuid} comporta l'impostazione di tutti gli identificatori. @@ -2051,9 +2053,9 @@ un completo controllo su tutti e tre i gruppi di identificatori \fhead{unistd.h} \fhead{sys/types.h} \fdecl{int setresuid(uid\_t ruid, uid\_t euid, uid\_t suid)} -\fdesc{Imposta l'\acr{uid} reale, effettivo e salvato del processo corrente.} +\fdesc{Imposta l'\ids{UID} reale, effettivo e salvato del processo corrente.} \fdecl{int setresgid(gid\_t rgid, gid\_t egid, gid\_t sgid)} -\fdesc{Imposta il \acr{gid} reale, effettivo e salvato del processo corrente.} +\fdesc{Imposta il \ids{GID} reale, effettivo e salvato del processo corrente.} } {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} può assumere solo il valore \errcode{EPERM}. @@ -2061,12 +2063,12 @@ caso \var{errno} può assumere solo il valore \errcode{EPERM}. \end{funcproto} Di nuovo le due funzioni sono identiche e quanto detto per la prima riguardo -gli \acr{uid} si applica alla seconda per i \acr{gid}. La funzione -\func{setresuid} imposta l'\acr{uid} reale, l'\acr{uid} effettivo e -l'\acr{uid} salvato del processo corrente ai valori specificati +gli \ids{UID} si applica alla seconda per i \ids{GID}. La funzione +\func{setresuid} imposta l'\ids{UID} reale, l'\ids{UID} effettivo e +l'\ids{UID} salvato del processo corrente ai valori specificati rispettivamente dagli argomenti \param{ruid}, \param{euid} e \param{suid}. I -processi non privilegiati possono cambiare uno qualunque degli\acr{uid} solo -ad un valore corrispondente o all'\acr{uid} reale, o a quello effettivo o a +processi non privilegiati possono cambiare uno qualunque degli\ids{UID} solo +ad un valore corrispondente o all'\ids{UID} reale, o a quello effettivo o a quello salvato, l'amministratore può specificare i valori che vuole. Un valore di $-1$ per un qualunque argomento lascia inalterato l'identificatore corrispondente. @@ -2082,9 +2084,9 @@ identificatori; i loro prototipi sono: \fhead{unistd.h} \fhead{sys/types.h} \fdecl{int getresuid(uid\_t *ruid, uid\_t *euid, uid\_t *suid)} -\fdesc{Legge l'\acr{uid} reale, effettivo e salvato del processo corrente.} +\fdesc{Legge l'\ids{UID} reale, effettivo e salvato del processo corrente.} \fdecl{int getresgid(gid\_t *rgid, gid\_t *egid, gid\_t *sgid)} -\fdesc{Legge il \acr{gid} reale, effettivo e salvato del processo corrente.} +\fdesc{Legge il \ids{GID} reale, effettivo e salvato del processo corrente.} } {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual caso \var{errno} può assumere solo il valore \errcode{EFAULT} se gli @@ -2113,9 +2115,9 @@ implementare un server NFS. Il server NFS infatti deve poter cambiare l'identificatore con cui accede ai file per assumere l'identità del singolo utente remoto, ma se questo viene -fatto cambiando l'\acr{uid} effettivo o l'\acr{uid} reale il server si espone +fatto cambiando l'\ids{UID} effettivo o l'\ids{UID} reale il server si espone alla ricezione di eventuali segnali ostili da parte dell'utente di cui ha -temporaneamente assunto l'identità. Cambiando solo l'\acr{uid} di filesystem +temporaneamente assunto l'identità. Cambiando solo l'\ids{UID} di filesystem si ottengono i privilegi necessari per accedere ai file, mantenendo quelli originari per quanto riguarda tutti gli altri controlli di accesso, così che l'utente non possa inviare segnali al server NFS. @@ -2127,9 +2129,9 @@ usate se si intendono scrivere programmi portabili; i loro prototipi sono: \begin{funcproto}{ \fhead{sys/fsuid.h} \fdecl{int setfsuid(uid\_t fsuid)} -\fdesc{Imposta l'\acr{uid} di filesystem del processo corrente.} +\fdesc{Imposta l'\ids{UID} di filesystem del processo corrente.} \fdecl{int setfsgid(gid\_t fsgid)} -\fdesc{Legge il \acr{gid} di filesystem del processo corrente.} +\fdesc{Legge il \ids{GID} di filesystem del processo corrente.} } {Le funzioni restituiscono il nuovo valore dell'identificativo in caso di successo e quello corrente per un errore, in questo caso non viene però @@ -2175,7 +2177,7 @@ POSIX.1, ed il suo prototipo è: La funzione legge gli identificatori dei gruppi supplementari del processo sul vettore \param{list} che deve essere di dimensione pari a \param{size}. Non è -specificato se la funzione inserisca o meno nella lista il \acr{gid} effettivo +specificato se la funzione inserisca o meno nella lista il \ids{GID} effettivo del processo. Se si specifica un valore di \param{size} uguale a $0$ allora l'argomento \param{list} non viene modificato, ma si ottiene il numero di gruppi supplementari. @@ -2197,9 +2199,9 @@ prototipo è: La funzione esegue una scansione del database dei gruppi (si veda sez.~\ref{sec:sys_user_group}) per leggere i gruppi supplementari dell'utente -specificato per nome (e non con un \acr{uid}) nella stringa passata con +specificato per nome (e non con un \ids{UID}) nella stringa passata con l'argomento \param{user}. Ritorna poi nel vettore \param{groups} la lista dei -\acr{gid} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups}, +\ids{GID} dei gruppi a cui l'utente appartiene. Si noti che \param{ngroups}, che in ingresso deve indicare la dimensione di \param{group}, è passato come \itindex{value~result~argument} \textit{value result argument} perché, qualora il valore specificato sia troppo piccolo, la funzione ritorna $-1$, passando @@ -2256,7 +2258,7 @@ caso \var{errno} assumerà uno dei valori: La funzione esegue la scansione del database dei gruppi (usualmente \conffile{/etc/group}) cercando i gruppi di cui è membro l'utente \param{user} -(di nuovo specificato per nome e non per \acr{uid}) con cui costruisce una +(di nuovo specificato per nome e non per \ids{UID}) con cui costruisce una lista di gruppi supplementari, a cui aggiunge anche \param{group}, infine imposta questa lista per il processo corrente usando \func{setgroups}. Si tenga presente che sia \func{setgroups} che @@ -2631,12 +2633,12 @@ possibilità di modificare arbitrariamente le priorità di qualunque processo. Un utente normale infatti può modificare solo la priorità dei suoi processi ed in genere soltanto diminuirla. Fino alla versione di kernel 2.6.12 Linux ha seguito le specifiche dello standard SUSv3, e come per tutti i -sistemi derivati da SysV veniva richiesto che l'\acr{uid} reale o quello -effettivo del processo chiamante corrispondessero all'\acr{uid} reale (e solo +sistemi derivati da SysV veniva richiesto che l'\ids{UID} reale o quello +effettivo del processo chiamante corrispondessero all'\ids{UID} reale (e solo a quello) del processo di cui si intendeva cambiare la priorità. A partire dalla versione 2.6.12 è stata adottata la semantica in uso presso i sistemi derivati da BSD (SunOS, Ultrix, *BSD), in cui la corrispondenza può essere -anche con l'\acr{uid} effettivo. +anche con l'\ids{UID} effettivo. Sempre a partire dal kernel 2.6.12 è divenuto possibile anche per gli utenti ordinari poter aumentare la priorità dei propri processi specificando un @@ -2876,8 +2878,8 @@ Solo un processo con i privilegi di amministratore\footnote{più precisamente sez.~\ref{sec:proc_capabilities}.} può impostare senza restrizioni priorità assolute diverse da zero o politiche \const{SCHED\_FIFO} e \const{SCHED\_RR}. Un utente normale può modificare solo le priorità di -processi che gli appartengono; è cioè richiesto che l'\acr{uid} effettivo del -processo chiamante corrisponda all'\acr{uid} reale o effettivo del processo +processi che gli appartengono; è cioè richiesto che l'\ids{UID} effettivo del +processo chiamante corrisponda all'\ids{UID} reale o effettivo del processo indicato con \param{pid}. Fino al kernel 2.6.12 gli utenti normali non potevano impostare politiche @@ -2981,10 +2983,10 @@ ed inoltre anche \errval{EFAULT} nel suo significato generico.} La funzione restituisce nell'argomento \param{tp} come una struttura \struct{timespec}, (la cui definizione si può trovare in fig.~\ref{fig:sys_timeval_struct}) il valore dell'intervallo di tempo usato -per la politica \textit{round robin} dal processo indicato da \acr{pid}. Il +per la politica \textit{round robin} dal processo indicato da \ids{PID}. Il valore dipende dalla versione del kernel, a lungo infatti questo intervallo di tempo era prefissato e non modificabile ad un valore di 150 millisecondi, -restituito indipendentemente dal \acr{pid} indicato. +restituito indipendentemente dal \ids{PID} indicato. Con kernel recenti però è possibile ottenere una variazione della \textit{time-slice}, modificando il valore di \textit{nice} del processo @@ -3549,7 +3551,7 @@ utente ordinario può modificare con \func{ioprio\_set} soltanto le priorità dei processi che gli appartengono,\footnote{per la modifica delle priorità di altri processi occorrono privilegi amministrativi, ed in particolare la capacità \const{CAP\_SYS\_NICE} (vedi sez.~\ref{sec:proc_capabilities}).} -cioè quelli il cui \acr{uid} reale corrisponde all'\acr{uid} reale o effettivo +cioè quelli il cui \ids{UID} reale corrisponde all'\ids{UID} reale o effettivo del chiamante. Data la possibilità di ottenere un blocco totale del sistema, solo l'amministratore\footnote{o un processo con la capacità \const{CAP\_SYS\_ADMIN} (vedi sez.~\ref{sec:proc_capabilities}).} può @@ -3639,7 +3641,7 @@ momento:\footnote{alla stesura di questa sezione, cioè con il kernel 3.2.} per sovrascriverne altri) viene cancellato quando si mette in esecuzione un programma con i bit \acr{suid} e \acr{sgid} attivi (vedi sez.~\ref{sec:file_special_perm}) o con l'uso delle funzioni per la modifica - degli \acr{uid} dei processi (vedi sez.~\ref{sec:proc_setuid}). + degli \ids{UID} dei processi (vedi sez.~\ref{sec:proc_setuid}). L'operazione è stata introdotta a partire dal kernel 2.3.20, fino al kernel 2.6.12 e per i kernel successivi al 2.6.17 era possibile usare solo un @@ -3711,7 +3713,7 @@ Introdotta a partire dal kernel 2.4.21, solo su PowerPC. \item[\const{PR\_SET\_KEEPCAPS}] Consente di controllare quali \itindex{capabilities} \textit{capabilities} vengono cancellate quando si - esegue un cambiamento di \acr{uid} del processo (per i dettagli si veda + esegue un cambiamento di \ids{UID} del processo (per i dettagli si veda sez.~\ref{sec:proc_capabilities}, in particolare quanto illustrato a pag.~\pageref{sec:capability-uid-transition}). Un valore nullo (il default) per \param{arg2} comporta che vengano cancellate, il valore 1 che vengano @@ -4017,18 +4019,24 @@ le funzioni di gestione dei \textit{thread} (la \textit{Native Thread Posix Library}, vedi sez.~\ref{sec:linux_ntpl}) nella \acr{glibc}, essi vengono utilizzati soltanto se si sono specificati rispettivamente i flag \const{CLONE\_PARENT\_SETTID}, \const{CLONE\_SETTLS} e -\const{CLONE\_CHILD\_CLEARTID}. +\const{CLONE\_CHILD\_SETTID}. + +La funzione ritorna un l'identificatore del nuovo \textit{task}, denominato +\texttt{Thread ID} (da qui in avanti \ids{TID}) il cui significato è analogo +al \ids{PID} dei normali processi e che a questo corrisponde qualora si crei +un processo. Il comportamento di \func{clone}, che si riflette sulle caratteristiche del -nuovo processo da essa creato, è controllato dall'argomento \param{flags}, che -deve essere specificato come maschera binaria, ottenuta con un OR aritmetico -di una delle costanti del seguente elenco, che illustra quelle attualmente -disponibili:\footnote{si fa riferimento al momento della stesura di questa - sezione, cioè con il kernel 3.2.} +nuovo processo da essa creato, è controllato principalmente +dall'argomento \param{flags}, che deve essere specificato come maschera +binaria, ottenuta con un OR aritmetico di una delle costanti del seguente +elenco, che illustra quelle attualmente disponibili:\footnote{si fa + riferimento al momento della stesura di questa sezione, cioè con il kernel + 3.2.} \begin{basedescript}{\desclabelstyle{\pushlabel}} -\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il +\item[\const{CLONE\_CHILD\_CLEARTID}] cancella il valore del \ids{TID} \item[\const{CLONE\_CHILD\_SETTID}] \item[\const{CLONE\_FILES}] \item[\const{CLONE\_FS}] diff --git a/session.tex b/session.tex index 2d1b69e..eb7809e 100644 --- a/session.tex +++ b/session.tex @@ -170,7 +170,7 @@ i cui prototipi sono: esiste.} \end{functions} -La funzione \func{getpgid} permette di specificare il \acr{pid} del processo +La funzione \func{getpgid} permette di specificare il \ids{PID} del processo di cui si vuole sapere il \acr{pgid}; un valore nullo per \param{pid} restituisce il \acr{pgid} del processo corrente; \func{getpgrp} è di norma equivalente a \code{getpgid(0)}. @@ -207,7 +207,7 @@ processi dall'uno all'altro, ma sempre all'interno di una stessa sessione. Ciascun raggruppamento di processi ha sempre un processo principale, il cosiddetto \itindex{process~group~leader} \textit{process group leader}, che è -identificato dall'avere un \acr{pgid} uguale al suo \acr{pid}, in genere +identificato dall'avere un \acr{pgid} uguale al suo \ids{PID}, in genere questo è il primo processo del raggruppamento, che si incarica di lanciare tutti gli altri. Un nuovo raggruppamento si crea con la funzione \funcd{setpgrp},\footnote{questa è la definizione di POSIX.1, BSD definisce @@ -216,13 +216,13 @@ tutti gli altri. Un nuovo raggruppamento si crea con la funzione richiedere esplicitamente la compatibilità all'indietro con BSD, definendo la macro \macro{\_BSD\_SOURCE}.} il cui prototipo è: \begin{prototype}{unistd.h}{int setpgrp(void)} - Modifica il \acr{pgid} al valore del \acr{pid} del processo corrente. + Modifica il \acr{pgid} al valore del \ids{PID} del processo corrente. \bodydesc{La funzione restituisce il valore del nuovo \textit{process group}.} \end{prototype} -La funzione, assegnando al \acr{pgid} il valore del \acr{pid} processo +La funzione, assegnando al \acr{pgid} il valore del \ids{PID} processo corrente, rende questo \itindex{process~group~leader} \textit{group leader} di un nuovo raggruppamento, tutti i successivi processi da esso creati apparterranno (a meno di non cambiare di nuovo il \acr{pgid}) al nuovo @@ -251,7 +251,7 @@ ancora eseguito una \func{exec}.\footnote{questa caratteristica è implementata dal kernel che mantiene allo scopo un altro campo, \var{did\_exec}, in \struct{task\_struct}.} Specificando un valore nullo per \param{pid} si indica il processo corrente, mentre specificando un valore nullo per -\param{pgid} si imposta il \textit{process group} al valore del \acr{pid} del +\param{pgid} si imposta il \textit{process group} al valore del \ids{PID} del processo selezionato; pertanto \func{setpgrp} è equivalente a \code{setpgid(0, 0)}. @@ -275,15 +275,15 @@ sessione ad un processo è quello di crearne una nuova con l'uso di \bodydesc{La funzione ritorna il valore del nuovo \acr{sid}, e -1 in caso di errore, il solo errore possibile è \errval{EPERM}, che si ha quando il - \acr{pgid} e \acr{pid} del processo coincidono.} + \acr{pgid} e \ids{PID} del processo coincidono.} \end{prototype} La funzione imposta il \acr{pgid} ed il \acr{sid} del processo corrente al -valore del suo \acr{pid}, creando così una nuova sessione ed un nuovo +valore del suo \ids{PID}, creando così una nuova sessione ed un nuovo \textit{process group} di cui esso diventa leader (come per i \textit{process group} un processo si dice leader di sessione\footnote{in Linux la proprietà è mantenuta in maniera indipendente con un apposito campo \var{leader} in - \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \acr{pid}) ed + \struct{task\_struct}.} se il suo \acr{sid} è uguale al suo \ids{PID}) ed unico componente. Inoltre la funzione distacca il processo da ogni terminale di controllo (torneremo sull'argomento in sez.~\ref{sec:sess_ctrl_term}) cui fosse in precedenza associato. @@ -292,13 +292,13 @@ La funzione ha successo soltanto se il processo non è già \itindex{process~group~leader} leader di un \textit{process group}, per cui per usarla di norma si esegue una \func{fork} e si esce, per poi chiamare \func{setsid} nel processo figlio, in modo che, avendo questo lo stesso -\acr{pgid} del padre ma un \acr{pid} diverso, non ci siano possibilità di +\acr{pgid} del padre ma un \ids{PID} diverso, non ci siano possibilità di errore.\footnote{potrebbe sorgere il dubbio che, per il riutilizzo dei valori - dei \acr{pid} fatto nella creazione dei nuovi processi (vedi + dei \ids{PID} fatto nella creazione dei nuovi processi (vedi sez.~\ref{sec:proc_pid}), il figlio venga ad assumere un valore corrispondente ad un \textit{process group} esistente; questo viene evitato - dal kernel che considera come disponibili per un nuovo \acr{pid} solo valori - che non corrispondono ad altri \acr{pid}, \acr{pgid} o \acr{sid} in uso nel + dal kernel che considera come disponibili per un nuovo \ids{PID} solo valori + che non corrispondono ad altri \ids{PID}, \acr{pgid} o \acr{sid} in uso nel sistema.} Questa funzione viene usata di solito nel processo di login (per i dettagli vedi sez.~\ref{sec:sess_login}) per raggruppare in una sessione tutti i comandi eseguiti da un utente dalla sua shell. @@ -601,8 +601,8 @@ provvede a costruire gli opportuni valori per le variabili di ambiente, come \texttt{HOME}, \texttt{SHELL}, ecc. Infine attraverso l'uso di \func{setuid}, \func{setgid} e \func{initgroups} verrà cambiata l'identità del proprietario del processo, infatti, come spiegato in sez.~\ref{sec:proc_setuid}, avendo -invocato tali funzioni con i privilegi di amministratore, tutti gli \acr{uid} -ed i \acr{gid} (reali, effettivi e salvati) saranno impostati a quelli +invocato tali funzioni con i privilegi di amministratore, tutti gli \ids{UID} +ed i \ids{GID} (reali, effettivi e salvati) saranno impostati a quelli dell'utente. A questo punto \cmd{login} provvederà (fatte salve eventuali altre azioni @@ -660,7 +660,7 @@ occorrerà predisporlo in modo che esso compia le seguenti azioni: \item Eseguire una \func{fork} e terminare immediatamente il processo padre proseguendo l'esecuzione nel figlio. In questo modo si ha la certezza che il figlio non è un \itindex{process~group~leader} \textit{process group - leader}, (avrà il \acr{pgid} del padre, ma un \acr{pid} diverso) e si può + leader}, (avrà il \acr{pgid} del padre, ma un \ids{PID} diverso) e si può chiamare \func{setsid} con successo. Inoltre la shell considererà terminato il comando all'uscita del padre. \item Eseguire \func{setsid} per creare una nuova sessione ed un nuovo @@ -852,7 +852,7 @@ tab.~\ref{tab:sess_openlog_option}. sistema del \textit{syslog}.\\ \const{LOG\_PERROR} & Stampa anche su \file{stderr} (non previsto in POSIX.1-2001).\\ -\const{LOG\_PID} & Inserisce nei messaggi il \acr{pid} del processo +\const{LOG\_PID} & Inserisce nei messaggi il \ids{PID} del processo chiamante.\\ \hline \end{tabular} diff --git a/signal.tex b/signal.tex index 64beb3f..7ebe8b7 100644 --- a/signal.tex +++ b/signal.tex @@ -1015,7 +1015,7 @@ specificare il segnale nullo. Se la funzione viene chiamata con questo valore non viene inviato nessun segnale, ma viene eseguito il controllo degli errori, in tal caso si otterrà un errore \errcode{EPERM} se non si hanno i permessi necessari ed un errore \errcode{ESRCH} se il processo specificato non esiste. -Si tenga conto però che il sistema ricicla i \acr{pid} (come accennato in +Si tenga conto però che il sistema ricicla i \ids{PID} (come accennato in sez.~\ref{sec:proc_pid}) per cui l'esistenza di un processo non significa che esso sia realmente quello a cui si intendeva mandare il segnale. @@ -1051,7 +1051,7 @@ Una seconda funzione che può essere definita in termini di \func{kill} è \textbf{Valore} & \textbf{Significato} \\ \hline \hline - $>0$ & Il segnale è mandato al processo con il \acr{pid} indicato.\\ + $>0$ & Il segnale è mandato al processo con il \ids{PID} indicato.\\ 0 & Il segnale è mandato ad ogni processo del \itindex{process~group} \textit{process group} del chiamante.\\ $-1$ & Il segnale è mandato ad ogni processo (eccetto \cmd{init}).\\ @@ -1065,8 +1065,8 @@ Una seconda funzione che può essere definita in termini di \func{kill} è \end{table} Solo l'amministratore può inviare un segnale ad un processo qualunque, in -tutti gli altri casi l'\acr{uid} reale o l'\acr{uid} effettivo del processo -chiamante devono corrispondere all'\acr{uid} reale o all'\acr{uid} salvato +tutti gli altri casi l'\ids{UID} reale o l'\ids{UID} effettivo del processo +chiamante devono corrispondere all'\ids{UID} reale o all'\ids{UID} salvato della destinazione. Fa eccezione il caso in cui il segnale inviato sia \signal{SIGCONT}, nel quale occorre che entrambi i processi appartengano alla stessa sessione. Inoltre, dato il ruolo fondamentale che riveste nel sistema @@ -2423,7 +2423,7 @@ fig.~\ref{fig:sig_siginfo_t}, nella trattazione dei gestori in forma estesa. In particolare i campi utilizzati dai segnali \textit{real-time} sono \var{si\_pid} e \var{si\_uid} in cui vengono memorizzati rispettivamente il -\acr{pid} e l'\acr{uid} effettivo del processo che ha inviato il segnale, mentre +\ids{PID} e l'\ids{UID} effettivo del processo che ha inviato il segnale, mentre per la restituzione dei dati viene usato il campo \var{si\_value}. \begin{figure}[!htb] diff --git a/sockctrl.tex b/sockctrl.tex index 5ec3d43..57d568b 100644 --- a/sockctrl.tex +++ b/sockctrl.tex @@ -145,7 +145,7 @@ tab.~\ref{tab:sys_NSS_classes}. \hline \hline \texttt{passwd} & Corrispondenze fra nome dell'utente e relative - proprietà (\acr{uid}, gruppo principale, ecc.).\\ + proprietà (\ids{UID}, gruppo principale, ecc.).\\ \texttt{shadow} & Corrispondenze fra username e password dell'utente (e altre informazioni relative alle password).\\ \texttt{group} & Corrispondenze fra nome del gruppo e proprietà dello @@ -3585,7 +3585,7 @@ identificano le operazioni sono le seguenti: \signal{SIGURG} quando viene completata una operazione di I/O asincrono o arrivano dei dati urgenti \itindex{out-of-band} (\texttt{out-of-band}). Il terzo argomento deve essere un puntatore ad una variabile di tipo - \type{pid\_t}; un valore positivo indica direttamente il \acr{pid} del + \type{pid\_t}; un valore positivo indica direttamente il \ids{PID} del processo, mentre un valore negativo indica (col valore assoluto) il \textit{process group}. Senza privilegi di amministratore o la capability \const{CAP\_KILL} si può impostare solo se stessi o il proprio diff --git a/socket.tex b/socket.tex index 058c4e4..ce9db0a 100644 --- a/socket.tex +++ b/socket.tex @@ -249,7 +249,7 @@ tab.~\ref{tab:net_pf_names}.\footnote{l'elenco indica tutti i protocolli Si tenga presente che non tutte le famiglie di protocolli sono utilizzabili dall'utente generico, ad esempio in generale tutti i socket di tipo \const{SOCK\_RAW} possono essere creati solo da processi che hanno i privilegi -di amministratore (cioè con \acr{uid} effettivo uguale a zero) o dotati della +di amministratore (cioè con \ids{UID} effettivo uguale a zero) o dotati della \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}. @@ -474,7 +474,7 @@ Il membro \var{sin\_family} deve essere sempre impostato a \const{AF\_INET}, altrimenti si avrà un errore di \errcode{EINVAL}; il membro \var{sin\_port} specifica il \textsl{numero di porta}. I numeri di porta sotto il 1024 sono chiamati \textsl{riservati} in quanto utilizzati da servizi standard e -soltanto processi con i privilegi di amministratore (con \acr{uid} effettivo +soltanto processi con i privilegi di amministratore (con \ids{UID} effettivo uguale a zero) o con la \itindex{capabilities} \textit{capability} \const{CAP\_NET\_BIND\_SERVICE} possono usare la funzione \func{bind} (che vedremo in sez.~\ref{sec:TCP_func_bind}) su queste porte. @@ -655,7 +655,7 @@ simboliche definite nel file \file{linux/if\_ether.h}. Se si usa il valore speciale \const{ETH\_P\_ALL} passeranno sul \textit{packet socket} tutti i pacchetti, qualunque sia il loro protocollo di collegamento. Ovviamente l'uso di questi socket è una operazione privilegiata e può essere effettuati solo da -un processo con i privilegi di amministratore (\acr{uid} effettivo nullo) o con +un processo con i privilegi di amministratore (\ids{UID} effettivo nullo) o con la \itindex{capabilities} \textit{capability} \const{CAP\_NET\_RAW}. Una volta aperto un \textit{packet socket}, tutti i pacchetti del protocollo diff --git a/system.tex b/system.tex index ffae3ab..2786f61 100644 --- a/system.tex +++ b/system.tex @@ -692,7 +692,7 @@ ed \conffile{/etc/group},\footnote{in realtà oltre a questi nelle \conffile{/etc/gshadow}, in cui sono state spostate le informazioni di autenticazione (ed inserite alcune estensioni) per toglierle dagli altri file che devono poter essere letti per poter effettuare l'associazione fra - username e \acr{uid}.} il cui formato è descritto dalle relative pagine del + username e \ids{UID}.} il cui formato è descritto dalle relative pagine del manuale\footnote{nella quinta sezione, quella dei file di configurazione, occorre cioè usare \cmd{man 5 passwd} dato che altrimenti si avrebbe la pagina di manuale del comando \cmd{passwd}.} e tutte le funzioni che @@ -729,7 +729,7 @@ completamente quelle relative all'autenticazione. % \acr{glibc} per modularizzare l'accesso a tutti i servizi in cui sia % necessario trovare una corrispondenza fra un nome ed un numero (od altra % informazione) ad esso associato, come appunto, quella fra uno username ed un -% \acr{uid} o fra un \acr{gid} ed il nome del gruppo corrispondente. +% \ids{UID} o fra un \ids{GID} ed il nome del gruppo corrispondente. Le prime funzioni che vedremo sono quelle previste dallo standard POSIX.1; queste sono del tutto generiche e si appoggiano direttamente al \textit{Name Service Switch}, per cui sono in grado di ricevere informazioni qualunque @@ -752,7 +752,7 @@ relative ad un utente si possono usare due funzioni, \funcd{getpwuid} e Le due funzioni forniscono le informazioni memorizzate nel registro degli utenti (che nelle versioni più recenti possono essere ottenute attraverso PAM) -relative all'utente specificato attraverso il suo \acr{uid} o il nome di +relative all'utente specificato attraverso il suo \ids{UID} o il nome di login. Entrambe le funzioni restituiscono un puntatore ad una struttura di tipo \struct{passwd} la cui definizione (anch'essa eseguita in \file{pwd.h}) è riportata in fig.~\ref{fig:sys_passwd_struct}, dove è pure brevemente @@ -932,7 +932,7 @@ I dati vengono usualmente\footnote{questa è la locazione specificata dal \file{/var/log/btmp} dove invece vengono memorizzati dal programma di login tutti tentativi di accesso fallito.} Quando un utente si collega viene aggiunta una voce a \file{/var/run/utmp} in cui viene memorizzato il nome di -login, il terminale da cui ci si collega, l'\acr{uid} della shell di login, +login, il terminale da cui ci si collega, l'\ids{UID} della shell di login, l'orario della connessione ed altre informazioni. La voce resta nel file fino al logout, quando viene cancellata e spostata in \file{/var/log/wtmp}.