Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
-dei file descriptor il cui significato emergerà più avanti, il puntatore
-\var{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga per
-i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
-fornite dal VFS per i file. Si sono riportate in
-tab.~\ref{tab:file_file_operations} le più significative.
+dei file descriptor il cui significato emergerà più avanti (vedi
+sez.~\ref{sec:file_unix_interface}), il puntatore \var{f\_op} ad una struttura
+\kstruct{file\_operation}. Questa è l'analoga per i file di
+\kstruct{inode\_operation}, e definisce le operazioni generiche fornite dal
+VFS per i file. Si sono riportate in tab.~\ref{tab:file_file_operations} le
+più significative.
\begin{table}[htb]
\centering
distribuzioni più recenti) la risoluzione dei nomi attraverso un collegamento
simbolico può fallire per una serie di restrizione di sicurezza aggiuntive
imposte dal meccanismo (si consulti sez.~\ref{sec:procadv_security_misc} per i
-dettagli del meccanismo).
+dettagli).
Dato che, come indicato in tab.~\ref{tab:file_symb_effect}, funzioni come la
\func{open} seguono i collegamenti simbolici, occorrono funzioni apposite per
\textit{stream} sulla prima voce contenuta nella directory.
Si tenga presente che comunque la funzione opera associando il
-\textit{directory stream} ad un opportuno file descriptor sottostante, sul
-quale vengono compiute le operazioni. Questo viene sempre aperto impostando il
-flag di \textit{close-on-exec} (si ricordi quanto detto in
-sez.~\ref{sec:proc_exec}), così da evitare che resti aperto in caso di
-esecuzione di un altro programma.
-
-Nel caso in cui sia necessario conoscere il \textit{file descriptor} associato
-ad un \textit{directory stream} si può usare la funzione
+\textit{directory stream} ad un opportuno file descriptor (vedi
+sez.~\ref{sec:file_fd}) sottostante, sul quale vengono compiute le
+operazioni. Questo viene sempre aperto impostando il flag di
+\textit{close-on-exec} (si ricordi quanto detto in sez.~\ref{sec:proc_exec}),
+così da evitare che resti aperto in caso di esecuzione di un altro programma.
+
+Nel caso in cui sia necessario conoscere il file descriptor associato ad un
+\textit{directory stream} si può usare la funzione
\funcd{dirfd},\footnote{questa funzione è una estensione introdotta con BSD
4.3-Reno ed è presente in Linux con le libc5 (a partire dalla versione
5.1.2) e con la \acr{glibc} ma non presente in POSIX fino alla revisione
\end{figure}
-Oltre ad \func{utimes} su Linux sono presenti altre due funzioni per la
-manipolazione dei tempi dei file,\footnote{le due funzioni non sono definite
- in nessuno standard, ma sono presenti, oltre che su Linux, anche su BSD;
- sono accessibili definendo \macro{\_DEFAULT\_SOURCE} dalla \acr{glibc} 2.19
- o \macro{\_GNU\_SOURCE} prima.} la prima è \funcd{futimes} e consente di
-effettuare la modifica utilizzando un file già aperto, il suo prototipo è:
+% Oltre ad \func{utimes} su Linux sono presenti altre due funzioni per la
+% manipolazione dei tempi dei file,\footnote{le due funzioni non sono definite
+% in nessuno standard, ma sono presenti, oltre che su Linux, anche su BSD;
+% sono accessibili definendo \macro{\_DEFAULT\_SOURCE} dalla \acr{glibc} 2.19
+% o \macro{\_GNU\_SOURCE} prima.} la prima è \funcd{futimes} e consente di
+% effettuare la modifica utilizzando un file già aperto, il suo prototipo è:
+
+% \begin{funcproto}{
+% \fhead{sys/time.h}
+% \fdecl{int futimes(int fd, const struct timeval tv[2])}
+% \fdesc{Cambia i tempi di un file già aperto.}
+% }
+
+% {La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+% caso \var{errno} assumerà uno gli stessi valori di \func{utimes} ed inoltre:
+% \begin{errlist}
+% \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
+% \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
+% \end{errlist}}
+% \end{funcproto}
+
+% La seconda funzione, introdotta a partire dal kernel 2.6.22, è
+% \funcd{lutimes}, e consente rispettivamente di modificare i tempi di un
+% collegamento simbolico; il suo prototipo è:
+
+% \begin{funcproto}{
+% \fhead{sys/time.h}
+% \fdecl{int lutimes(const char *filename, const struct timeval tv[2])}
+% \fdesc{Cambia i tempi di un collegamento simbolico.}
+% }
+
+% {La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+% caso \var{errno} assumerà uno gli stessi valori di \func{utimes}, con in più:
+% \begin{errlist}
+% \item[\errcode{ENOSYS}] la funzione non è supportata.
+% \end{errlist}}
+% \end{funcproto}
+
+% Le due funzioni hanno lo stesso comportamento di \texttt{utimes} e richiedono
+% gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
+% si può indicare il file su cui operare se questo è già aperto facendo
+% riferimento al suo file descriptor, mentre con \func{lutimes}, nel caso in cui
+% \param{filename} sia un collegamento simbolico, saranno modificati i suoi
+% tempi invece di quelli del file a cui esso punta.
+
+Oltre ad \func{utimes} su Linux sono presenti altre due funzioni,\footnote{le
+ due funzioni non sono definite in nessuno standard, ma sono presenti, oltre
+ che su Linux, anche su BSD; sono accessibili definendo
+ \macro{\_DEFAULT\_SOURCE} dalla \acr{glibc} 2.19 o \macro{\_GNU\_SOURCE}
+ prima.} \funcd{futimes} e \funcd{lutimes}, che consentono rispettivamente
+di effettuare la modifica utilizzando un file già aperto o di eseguirla
+direttamente su un collegamento simbolico. I relativi prototipi sono:
\begin{funcproto}{
\fhead{sys/time.h}
\fdecl{int futimes(int fd, const struct timeval tv[2])}
\fdesc{Cambia i tempi di un file già aperto.}
-}
-
-{La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà uno gli stessi valori di \func{utimes} ed inoltre:
- \begin{errlist}
- \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
- \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile.
- \end{errlist}}
-\end{funcproto}
-
-La seconda funzione, introdotta a partire dal kernel 2.6.22, è
-\funcd{lutimes}, e consente rispettivamente di modificare i tempi di un
-collegamento simbolico; il suo prototipo è:
-
-\begin{funcproto}{
-\fhead{sys/time.h}
\fdecl{int lutimes(const char *filename, const struct timeval tv[2])}
\fdesc{Cambia i tempi di un collegamento simbolico.}
}
-{La funzione ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
- caso \var{errno} assumerà uno gli stessi valori di \func{utimes}, con in più:
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno gli stessi valori di \func{utimes}, con in più
+ per \func{futimes}:
\begin{errlist}
- \item[\errcode{ENOSYS}] la funzione non è supportata.
- \end{errlist}}
+ \item[\errcode{EBADF}] \param{fd} non è un file descriptor.
+ \item[\errcode{ENOSYS}] il filesystem \texttt{/proc} non è accessibile per
+ \func{futimes} o la funzione non è supportata per \func{lutimes}.
+ \end{errlist}}
\end{funcproto}
Le due funzioni hanno lo stesso comportamento di \texttt{utimes} e richiedono
gli stessi privilegi per poter operare, la differenza è che con \func{futimes}
si può indicare il file su cui operare se questo è già aperto facendo
-riferimento al suo file descriptor, mentre con \func{lutimes}, nel caso in cui
-\param{filename} sia un collegamento simbolico, saranno modificati i suoi
+riferimento al suo file descriptor, mentre con \func{lutimes} nel caso in
+cui \param{filename} sia un collegamento simbolico saranno modificati i suoi
tempi invece di quelli del file a cui esso punta.
Nonostante il kernel nelle versioni più recenti supporti, come accennato,
Una delle caratteristiche fondamentali di tutti i sistemi unix-like è quella
del controllo di accesso ai file, che viene implementato per qualunque
-filesystem standard.\footnote{per standard si intende che implementa le
- caratteristiche previste dallo standard POSIX; in Linux sono utilizzabili
- anche filesystem di altri sistemi operativi, che non supportano queste
- caratteristiche.} In questa sezione ne esamineremo i concetti essenziali e
-le funzioni usate per gestirne i vari aspetti.
+filesystem standard.\footnote{per filesystem standard si intende un filesystem
+ che implementi le caratteristiche previste dallo standard POSIX; in Linux
+ sono utilizzabili anche filesystem di altri sistemi operativi, che non
+ supportano queste caratteristiche.} In questa sezione ne esamineremo i
+concetti essenziali e le funzioni usate per gestirne i vari aspetti.
\subsection{I permessi per l'accesso ai file}
\begin{figure}[htb]
\centering
- \includegraphics[width=6cm]{img/fileperm}
+ \includegraphics[width=8cm]{img/fileperm}
\caption{Lo schema dei bit utilizzati per specificare i permessi di un file
contenuti nel campo \var{st\_mode} di \struct{stat}.}
\label{fig:file_perm_bit}
del campo \var{st\_mode} della struttura \struct{stat} (si veda di nuovo
fig.~\ref{fig:file_stat_struct}).
-In genere ci si riferisce ai tre livelli dei privilegi usando le lettere
-\texttt{u} (per \textit{user}), \texttt{g} (per \textit{group}) e \texttt{o}
-(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
-insieme si usa la lettera \texttt{a} (per \textit{all}). Si tenga ben presente
-questa distinzione dato che in certi casi, mutuando la terminologia in uso a
-suo tempo nel VMS, si parla dei permessi base come di permessi per
-\textit{owner}, \textit{group} ed \textit{all}, le cui iniziali possono dar
-luogo a confusione. Le costanti che permettono di accedere al valore numerico
-di questi bit nel campo \var{st\_mode}, già viste in
-tab.~\ref{tab:file_mode_flags}, sono riportate per chiarezza una seconda volta
-in tab.~\ref{tab:file_bit_perm}.
-
\begin{table}[htb]
\centering
\footnotesize
\label{tab:file_bit_perm}
\end{table}
+
+In genere ci si riferisce ai tre livelli dei privilegi usando le lettere
+\texttt{u} (per \textit{user}), \texttt{g} (per \textit{group}) e \texttt{o}
+(per \textit{other}), inoltre se si vuole indicare tutti i raggruppamenti
+insieme si usa la lettera \texttt{a} (per \textit{all}). Si tenga ben presente
+questa distinzione dato che in certi casi, mutuando la terminologia in uso a
+suo tempo nel VMS, si parla dei permessi base come di permessi per
+\textit{owner}, \textit{group} ed \textit{all}, le cui iniziali possono dar
+luogo a confusione. Le costanti che permettono di accedere al valore numerico
+di questi bit nel campo \var{st\_mode}, già viste in
+tab.~\ref{tab:file_mode_flags}, sono riportate per chiarezza una seconda volta
+in tab.~\ref{tab:file_bit_perm}.
+
I permessi vengono usati in maniera diversa dalle varie funzioni, e a seconda
che si riferiscano a dei file, dei collegamenti simbolici o delle directory;
qui ci limiteremo ad un riassunto delle regole generali, entrando nei dettagli
esecuzione e di quello di scrittura per la directory di destinazione. Gli
stessi permessi occorrono per cancellare un file da una directory (si ricordi
che questo non implica necessariamente la rimozione del contenuto del file dal
-disco). Per la cancellazione non è necessario nessun tipo di permesso per il
-file stesso dato che, come illustrato in sez.~\ref{sec:link_symlink_rename}
-esso non viene toccato, nella cancellazione infatti viene solo modificato il
+disco).
+
+Per la cancellazione non è necessario nessun tipo di permesso per il file
+stesso dato che, come illustrato in sez.~\ref{sec:link_symlink_rename} esso
+non viene toccato, nella cancellazione infatti viene solo modificato il
contenuto della directory, rimuovendo la voce che ad esso fa riferimento. Lo
stesso vale per poter rinominare o spostare il file in altra directory, in
entrambi i casi occorrerà il permesso di scrittura sulle directory che si
tratteremo insieme alle altre \textit{at-functions} in
sez.~\ref{sec:file_openat}.
+
Del tutto analoghe a \func{access} sono le due funzioni \funcm{euidaccess} e
\funcm{eaccess} che ripetono lo stesso controllo usando però gli
identificatori del gruppo effettivo, verificando quindi le effettive capacità
anche gli stessi valori e restituiscono gli stessi risultati e gli stessi
codici di errore.
-Per cambiare i permessi di un file il sistema mette ad disposizione due
-funzioni \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente su un
-filename e su un file descriptor, i loro prototipi sono:
+Le due funzioni non sono previste da nessuno standard, ed utilizzabili solo
+avendo definito \macro{\_GNU\_SOURCE}; inoltre qualora le si vogliano
+utilizzare per verificare che un processo abbia i permessi per accedere ad un
+file prima di farlo effettivamente, ci si esporrebbe ad una \textit{race
+ condition}, dato che i permessi potrebbero cambiare nell'intervallo fra il
+controllo e l'accesso effettivo. Per questo motivo in questo caso è molto più
+semplice e sicuro tentare direttamente l'accesso, e trattare opportunamente
+l'eventuale fallimento per mancanza di permessi.
+
+Per cambiare i permessi di un file sono invece disponibili due funzioni di
+sistema \funcd{chmod} e \funcd{fchmod}, che operano rispettivamente usando il
+\textit{pathname} di un file o se questo è già aperto sul relativo file
+descriptor; i loro prototipi sono:
\begin{funcproto}{
\fhead{sys/types.h}
Entrambe le funzioni utilizzano come secondo argomento \param{mode}, una
variabile dell'apposito tipo primitivo \type{mode\_t} (vedi
-tab.~\ref{tab:intro_primitive_types}) utilizzato per specificare i permessi
-sui file.
+tab.~\ref{tab:intro_primitive_types}), che è una maschera binaria da
+utilizzare per specificare i permessi sui file.
\begin{table}[!htb]
\centering
\label{tab:file_permission_const}
\end{table}
-Le costanti con cui specificare i singoli bit di \param{mode} sono riportate
-in tab.~\ref{tab:file_permission_const}, e corrispondono agli stessi valori
-usati per \var{st\_mode} in tab.~\ref{tab:file_mode_flags}. Il valore
-di \param{mode} può essere ottenuto combinando fra loro con un OR binario le
-costanti simboliche relative ai vari bit, o specificato direttamente, come per
-l'omonimo comando di shell, con un valore numerico (la shell lo vuole in
-ottale, dato che i bit dei permessi sono divisibili in gruppi di tre), che si
-può calcolare direttamente usando lo schema di utilizzo dei bit illustrato in
+Si sono riportate in tab.~\ref{tab:file_permission_const} le costanti con cui
+indicare i singoli bit di \param{mode}; si noti come corrispondano agli stessi
+valori usati per \var{st\_mode} già visti in tab.~\ref{tab:file_mode_flags}.
+Il valore di \param{mode} può essere ottenuto combinando fra loro con un OR
+binario le costanti simboliche relative ai vari bit, o specificato
+direttamente, come per l'omonimo comando di shell \texttt{chmod}, con un
+valore numerico (con la shell in genere lo si scrive in ottale, dato che i bit
+dei permessi sono divisibili in gruppi di tre), che si può calcolare
+direttamente usando lo schema di utilizzo dei bit illustrato in
fig.~\ref{fig:file_perm_bit}.
Ad esempio i permessi standard assegnati ai nuovi file (lettura e scrittura
per il proprietario, sola lettura per il gruppo e gli altri) sono
-corrispondenti al valore ottale $0644$, un programma invece avrebbe anche il
-bit di esecuzione attivo, con un valore di $0755$, se si volesse attivare il
-bit \acr{suid} il valore da fornire sarebbe $4755$.
+corrispondenti al valore ottale \texttt{0644}, un programma invece avrebbe
+anche il bit di esecuzione attivo, con un valore ottale di \texttt{0755}, se
+infine si volesse attivare anche il bit \acr{suid} il valore ottale da fornire
+sarebbe \texttt{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'\ids{UID} effettivo del processo
-corrisponde a quello del proprietario del file o dell'amministratore,
-altrimenti esse falliranno con un errore di \errcode{EPERM}.
+chiamante corrisponde a quello del proprietario del file o se il processo ha i
+privilegi di amministratore,\footnote{per la precisione la capacità
+ \const{CAP\_FOWNER}, vedi sez.~\ref{sec:proc_capabilities}.} in caso
+contrario esse falliranno con un errore di \errcode{EPERM}.
Ma oltre a questa regola generale, di immediata comprensione, esistono delle
limitazioni ulteriori. Per questo motivo, anche se si è proprietari del file,
\end{enumerate*}
Per alcuni filesystem\footnote{i filesystem più comuni (\textsl{ext2},
- \textsl{ext3}, \textsl{ext4}, \textsl{ReiserFS}) supportano questa
- caratteristica, che è mutuata da BSD.} è inoltre prevista un'ulteriore
-misura di sicurezza, volta a scongiurare l'abuso dei bit \acr{suid} e
-\acr{sgid}; essa consiste nel cancellare automaticamente questi bit dai
-permessi di un file qualora un processo che non appartenga
+ \textsl{ext3}, \textsl{ext4}, \textsl{xfs}, \texttt{btrfs}) supportano
+ questa caratteristica, che è mutuata da BSD.} è inoltre prevista
+un'ulteriore misura di sicurezza, volta a scongiurare l'abuso dei bit
+\acr{suid} e \acr{sgid}; essa consiste nel cancellare automaticamente questi
+bit dai permessi di un file qualora un processo che non appartenga
all'amministratore\footnote{per la precisione un processo che non dispone
della capacità \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.}
effettui una scrittura. In questo modo anche se un utente malizioso scopre un
relativa all'uso degli \textit{extended user attributes} nessuno è mai stato
capace di indicare una qualche forma sensata di utilizzo degli stessi per
collegamenti simbolici o file di dispositivo, e neanche per le \textit{fifo}
- o i socket. Per questo motivo essi sono stati completamente disabilitati
- per tutto ciò che non sia un file regolare o una directory.\footnote{si può
- verificare la semantica adottata consultando il file \texttt{fs/xattr.c}
- dei sorgenti del kernel.} Inoltre per le directory è stata introdotta una
- ulteriore restrizione, dovuta di nuovo alla presenza ordinaria di permessi
- di scrittura completi su directory come \texttt{/tmp}. Per questo motivo,
- per evitare eventuali abusi, se una directory ha lo \textit{sticky bit}
- attivo sarà consentito scrivere i suoi \textit{extended user attributes}
- soltanto se si è proprietari della stessa, o si hanno i privilegi
- amministrativi della capacità \const{CAP\_FOWNER}.
+ o i socket.
+
+ Per questo motivo essi sono stati completamente disabilitati per tutto ciò
+ che non sia un file regolare o una directory.\footnote{si può verificare la
+ semantica adottata consultando il file \texttt{fs/xattr.c} dei sorgenti
+ del kernel.} Inoltre per le directory è stata introdotta una ulteriore
+ restrizione, dovuta di nuovo alla presenza ordinaria di permessi di
+ scrittura completi su directory come \texttt{/tmp}. Per questo motivo, per
+ evitare eventuali abusi, se una directory ha lo \textit{sticky bit} attivo
+ sarà consentito scrivere i suoi \textit{extended user attributes} soltanto
+ se si è proprietari della stessa, o si hanno i privilegi amministrativi
+ della capacità \const{CAP\_FOWNER}.
\end{basedescript}
Le funzioni per la gestione degli attributi estesi, come altre funzioni di
restituiscono la dimensione esatta dell'attributo al momento in cui sono
eseguite, questa potrebbe essere modificata in qualunque momento da un
successivo accesso eseguito da un altro processo, pertanto si verifichi sempre
-il valore di ritorni ed il codice di errore della funzione usata, senza dare
+il valore di ritorno ed il codice di errore della funzione usata, senza dare
per scontato che essa abbia sempre successo.
Un secondo gruppo di funzioni sono quelle che consentono di impostare il
Le tre funzioni prendono come primo argomento un valore adeguato al loro scopo
(un \textit{pathname} le prime due, un file descriptor la terza), usato in
maniera del tutto identica a quanto visto in precedenza per le analoghe che
-leggono gli attributi estesi. Il secondo argomento, \param{name}, deve
-indicare, anche in questo caso con gli stessi criteri appena visti per le
-analoghe \func{getxattr}, \func{lgetxattr} e \func{fgetxattr}, il nome
-(completo di suffisso) dell'attributo su cui si vuole operare. Il valore che
-verrà assegnato all'attributo dovrà essere preparato nel buffer puntato da
-\param{value}, e la sua dimensione totale (in byte) dovrà essere indicata
-dall'argomento \param{size}.
+leggono gli attributi estesi.
+
+Il secondo argomento, \param{name}, deve indicare, anche in questo caso con
+gli stessi criteri appena visti per le analoghe \func{getxattr},
+\func{lgetxattr} e \func{fgetxattr}, il nome (completo di suffisso)
+dell'attributo su cui si vuole operare. Il valore che verrà assegnato
+all'attributo dovrà essere preparato nel buffer puntato da \param{value}, e la
+sua dimensione totale (in byte) dovrà essere indicata dall'argomento
+\param{size}.
Infine l'argomento \param{flag} consente di controllare le modalità di
sovrascrittura dell'attributo esteso, esso può prendere due valori: con
\constd{XATTR\_REPLACE} si richiede che l'attributo esista, nel qual caso
-verrà sovrascritto, altrimenti si avrà errore, mentre con
-\constd{XATTR\_CREATE} si richiede che l'attributo non esista, nel qual caso
-verrà creato, altrimenti si avrà errore ed il valore attuale non sarà
-modificato. Utilizzando per \param{flag} un valore nullo l'attributo verrà
-modificato se è già presente, o creato se non c'è.
+verrà sovrascritto ed altrimenti si avrà errore; con \constd{XATTR\_CREATE} si
+richiede che l'attributo non esista, nel qual caso verrà creato, altrimenti si
+avrà errore ed il valore attuale non sarà modificato. Utilizzando per
+\param{flag} un valore nullo l'attributo verrà modificato se è già presente, o
+creato se non c'è.
Le funzioni finora illustrate permettono di leggere o scrivere gli attributi
estesi presenti su un file, ma sarebbe altrettanto utile poter sapere quali
compilatore con l'opzione \texttt{-lacl}. Si tenga presente inoltre che le ACL
devono essere attivate esplicitamente montando il filesystem\footnote{che deve
supportarle, ma questo è ormai vero per praticamente tutti i filesystem più
- comuni, con l'eccezione di NFS per il quale esiste però un supporto
- sperimentale.} su cui le si vogliono utilizzare con l'opzione \texttt{acl}
+ comuni, con l'eccezione di NFS per il quale esiste però il supporto per le
+ versioni NFSv2 e NFSv3 del protocollo, con NFSv4 esistono invece delle ACL
+ native che hannno una semantica diversa, su cui si possono mappare le ACL
+ POSIX, su quelle di NFSv4, ma l'inverso è possibile solo in forma
+ incompleta.} su cui le si vogliono utilizzare con l'opzione \texttt{acl}
attiva. Dato che si tratta di una estensione è infatti opportuno utilizzarle
soltanto laddove siano necessarie.
vengono sempre utilizzati gli identificatori del gruppo \textit{effective} del
processo, ma in caso di presenza di una ACL sul file, i passi attraverso i
quali viene stabilito se il processo ha il diritto di accesso sono i seguenti:
-\begin{enumerate}
+\begin{enumerate*}
\item Se l'\ids{UID} del processo è nullo (se cioè si è l'amministratore)
l'accesso è sempre garantito senza nessun controllo.\footnote{più
precisamente se si devono avere le capacità \const{CAP\_DAC\_OVERRIDE} per
\end{itemize*}
\item Se la voce \const{ACL\_USER\_OBJ} contiene il permesso richiesto,
l'accesso è consentito, altrimenti l'accesso è negato.
-\end{enumerate}
+\end{enumerate*}
I passi di controllo vengono eseguiti esattamente in questa sequenza, e la
decisione viene presa non appena viene trovata una corrispondenza con gli
projects / gapil.git / commitdiff