X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=blobdiff_plain;f=filedir.tex;h=d3d7cdaae1419e21ed63c8c30a7ab241144ef8d7;hb=08c289c4acd775aabeb5beeb7b08566969e11d9b;hp=8e317862cf1ed7b01f7d793b0b4f9dc5f5a24468;hpb=bacb94a4e700a52b66cb5808f7e99b8a4b8be828;p=gapil.git diff --git a/filedir.tex b/filedir.tex index 8e31786..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. @@ -721,49 +721,48 @@ significativi sono un \itindex{magic~number} \textit{magic al \textit{magic number}.} mentre i 16 meno significativi sono usati per specificare le opzioni; essi sono usati come maschera binaria e vanno impostati con un OR aritmetico della costante \const{MS\_MGC\_VAL} con i -valori riportati in tab.~\ref{tab:sys_mount_flags}. +valori riportati nell'elenco seguente: -\begin{table}[htb] - \footnotesize - \centering - \begin{tabular}[c]{|l|p{8cm}|} - \hline - \textbf{Parametro} & \textbf{Significato}\\ - \hline - \hline - \const{MS\_BIND} & Monta il filesystem altrove.\\ - \const{MS\_DIRSYNC} & .\\ - \const{MS\_MANDLOCK} & Consente il \textit{mandatory locking} - \itindex{mandatory~locking} (vedi - sez.~\ref{sec:file_mand_locking}).\\ - \const{MS\_MOVE} & Sposta atomicamente il punto di montaggio.\\ - \const{MS\_NOATIME} & Non aggiorna gli \textit{access time} (vedi - sez.~\ref{sec:file_file_times}).\\ - \const{MS\_NODEV} & Impedisce l'accesso ai file di dispositivo.\\ - \const{MS\_NODIRATIME} & Non aggiorna gli \textit{access time} delle - directory.\\ - \const{MS\_NOEXEC} & Impedisce di eseguire programmi.\\ - \const{MS\_NOSUID} & Ignora i bit \itindex{suid~bit} \acr{suid} e - \itindex{sgid~bit} \acr{sgid}.\\ - \const{MS\_RDONLY} & Monta in sola lettura.\\ - \const{MS\_RELATIME} & .\\ - \const{MS\_REMOUNT} & Rimonta il filesystem cambiando le opzioni.\\ - \const{MS\_SILENT} & .\\ - \const{MS\_STRICTATIME}& .\\ - \const{MS\_SYNCHRONOUS}& Abilita la scrittura sincrona.\\ - % \const{S\_WRITE} & Scrive normalmente.\\ - % \const{S\_APPEND} & Consente la scrittura solo in - % \itindex{append~mode} \textit{append mode} - % (vedi sez.~\ref{sec:file_sharing}).\\ - % \const{S\_IMMUTABLE} & Impedisce che si possano modificare i file.\\ - \hline - \end{tabular} - \caption{Tabella dei codici dei flag di montaggio di un filesystem.} - \label{tab:sys_mount_flags} -\end{table} +\begin{basedescript}{\desclabelstyle{\pushlabel}} + +\item[\const{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in + sostanza . + +\item[\const{MS\_DIRSYNC}] . + +\item[\const{MS\_MANDLOCK}] Consente il \textit{mandatory locking} + \itindex{mandatory~locking} (vedi + sez.~\ref{sec:file_mand_locking}). + +\item[\const{MS\_MOVE}] Sposta atomicamente il punto di montaggio. + +\item[\const{MS\_NOATIME}] Non aggiorna gli \textit{access time} (vedi + sez.~\ref{sec:file_file_times}). + +\item[\const{MS\_NODEV}] Impedisce l'accesso ai file di dispositivo. + +\item[\const{MS\_NODIRATIME}] Non aggiorna gli \textit{access time} delle + directory. +\item[\const{MS\_NOEXEC}] Impedisce di eseguire programmi. + +\item[\const{MS\_NOSUID}] Ignora i bit \itindex{suid~bit} \acr{suid} e + \itindex{sgid~bit} \acr{sgid}. + +\item[\const{MS\_RDONLY}] Monta in sola lettura. + +\item[\const{MS\_RELATIME}] . + +\item[\const{MS\_REMOUNT}] Rimonta il filesystem cambiando le opzioni. + +\item[\const{MS\_SILENT}] . + +\item[\const{MS\_STRICTATIME}] . + +\item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona. % TODO aggiornare con i nuovi flag di man mount % verificare i readonly mount bind del 2.6.26 +\end{basedescript} La funzione \func{mount} può essere utilizzata anche per effettuare il \textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo @@ -1455,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 @@ -2360,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 @@ -3079,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 @@ -3226,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, @@ -3236,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*} @@ -3258,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, @@ -3300,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 @@ -3399,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. @@ -3492,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} @@ -3556,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}. @@ -3566,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 @@ -3576,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}, @@ -3649,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. @@ -3672,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 @@ -3704,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 @@ -4415,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 @@ -4431,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 @@ -4440,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*} @@ -4784,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 @@ -5110,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. @@ -5219,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} @@ -5690,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 @@ -5699,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}, @@ -5746,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}. @@ -5760,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 @@ -6011,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 @@ -6037,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 @@ -6706,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};