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
\cmd{-t}) mostra i tempi dei file secondo lo schema riportato nell'ultima
colonna di tab.~\ref{tab:file_file_times}. Si noti anche come in
tab.~\ref{tab:file_file_times} non venga riportato il \textsl{tempo di
- creazione} di un file. In un sistema unix-like infatti questo tempo
-tradizionalmente non esiste, e non è previsto dall'interfaccia classica, ma è
-usato da altri sistemi operativi (in particolare Windows) per cui in tutti i
-filesystem più recenti ne viene supportata la registrazione, ed a partire dal
-kernel 4.11 è divento possibile anche ottenerne la lettura con la nuova
-\textit{system call} \func{statx} (che tratteremo in
-sez.~\ref{sec:file_openat}).
+ creazione} di un file; in un sistema unix-like infatti questo non esiste, e
+non è previsto dall'interfaccia classica, ma essendo usato da altri sistemi
+operativi (in particolare Windows) in tutti i filesystem più recenti ne viene
+supportata la registrazione, ed a partire dal kernel 4.11 è diventato
+possibile anche ottenerne la lettura con la nuova \textit{system call}
+\func{statx} (che tratteremo in sez.~\ref{sec:file_openat}).
L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un
difetto progettuale di Unix, questo infatti comporta la necessità di
\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
semantica BSD. Linux invece segue normalmente quella che viene chiamata
semantica SVr4: di norma un nuovo file viene creato, seguendo la prima
opzione, con il \ids{GID} del processo, se però la directory in cui viene
-creato ha il bit \acr{sgid} impostato allora viene usata la seconda
-opzione. L'adozione di questa semantica però può essere controllata,
+creato ha il bit \acr{sgid} dei permessi impostato allora viene usata la
+seconda opzione. L'adozione di questa semantica però può essere controllata,
all'interno di alcuni filesystem,\footnote{con il kernel 2.6.25 questi erano
- \acr{ext2}, \acr{ext3}, \acr{ext4}, e XFS.} con l'uso dell'opzione di
+ \acr{ext2}, \acr{ext3}, \acr{ext4}, e \acr{XFS}.} con l'uso dell'opzione di
montaggio \texttt{grpid}, che se attivata fa passare all'uso della semantica
BSD.
stata creata una nuova \textit{system call} per \func{chown} che seguisse i
collegamenti simbolici.} La funzione \func{fchown} opera su un file aperto,
essa è mutuata da BSD, ma non è nello standard POSIX. Un'altra estensione
-rispetto allo standard POSIX è che specificando -1 come valore
-per \param{owner} e \param{group} i valori restano immutati.
+rispetto allo standard POSIX è che specificando $-1$ come valore per
+\param{owner} e \param{group} i valori restano immutati.
Quando queste funzioni sono chiamate con successo da un processo senza i
privilegi di amministratore entrambi i bit \acr{suid} e \acr{sgid} vengono
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
Il modello classico dei permessi di Unix, per quanto funzionale ed efficiente,
è comunque piuttosto limitato e per quanto possa aver coperto per lunghi anni
le esigenze più comuni con un meccanismo semplice e potente, non è in grado di
-rispondere in maniera adeguata a situazioni che richiedono una gestione
+rispondere in maniera adeguata a situazioni che richiedono una gestione più
complessa dei permessi di accesso.\footnote{già un requisito come quello di
dare accesso in scrittura ad alcune persone ed in sola lettura ad altre non
si può soddisfare in maniera semplice.}
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}
-attiva. Dato che si tratta di una estensione è infatti opportuno utilizzarle
-soltanto laddove siano necessarie.
+ 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 di esse possono mappare le ACL
+ POSIX, 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.
Una ACL è composta da un insieme di voci, e ciascuna voce è a sua volta
-costituita da un \textsl{tipo}, da un eventuale
-\textsl{qualificatore},\footnote{deve essere presente soltanto per le voci di
- tipo \const{ACL\_USER} e \const{ACL\_GROUP}.} e da un insieme di permessi.
-Ad ogni oggetto sul filesystem si può associare una ACL che ne governa i
-permessi di accesso, detta \textit{access ACL}. Inoltre per le directory si
-può impostare una ACL aggiuntiva, detta ``\textit{Default ACL}'', che serve ad
-indicare quale dovrà essere la ACL assegnata di default nella creazione di un
-file all'interno della directory stessa. Come avviene per i permessi le ACL
-possono essere impostate solo del proprietario del file, o da un processo con
-la capacità \const{CAP\_FOWNER}.
+costituita da un \textsl{tipo}, da un eventuale \textsl{qualificatore} (deve
+essere presente soltanto per le voci di tipo \const{ACL\_USER} e
+\const{ACL\_GROUP}) e da un insieme di permessi. Ad ogni oggetto sul
+filesystem si può associare una ACL che ne governa i permessi di accesso,
+detta \textit{access ACL}. Inoltre per le directory si può impostare una ACL
+aggiuntiva, detta ``\textit{Default ACL}'', che serve ad indicare quale dovrà
+essere la ACL assegnata di default nella creazione di un file all'interno
+della directory stessa. Come avviene per i permessi le ACL possono essere
+impostate solo del proprietario del file, o da un processo con la capacità
+\const{CAP\_FOWNER}.
\begin{table}[htb]
\centering
Una ACL può poi contenere un numero arbitrario di voci di tipo
\const{ACL\_USER} e \const{ACL\_GROUP}, ciascuna delle quali indicherà i
permessi assegnati all'utente e al gruppo indicato dal relativo qualificatore.
-Ovviamente ciascuna di queste voci dovrà fare riferimento ad un utente o ad un
+Ovviamente ciascuna di queste voci dovrà fare riferimento a un utente o a un
gruppo diverso, e non corrispondenti a quelli proprietari del file. Inoltre se
in una ACL esiste una voce di uno di questi due tipi, è obbligatoria anche la
presenza di una ed una sola voce di tipo \const{ACL\_MASK}, che negli altri
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
\const{ACL\_GROUP\_OBJ}).
Per la gestione delle ACL lo standard \textit{POSIX 1003.1e Draft 17} ha
-previsto delle apposite funzioni ed tutta una serie di tipi di dati
-dedicati;\footnote{fino a definire un tipo di dato e delle costanti apposite
- per identificare i permessi standard di lettura, scrittura ed esecuzione.}
-tutte le operazioni devono essere effettuate attraverso tramite questi tipi di
-dati, che incapsulano tutte le informazioni contenute nelle ACL. La prima di
-queste funzioni che prendiamo in esame è \funcd{acl\_init}, il cui prototipo
-è:
+previsto delle apposite funzioni ed tutta una serie di tipi di dati dedicati,
+arrivando fino a definire un tipo di dato e delle costanti apposite per
+identificare i permessi standard di lettura, scrittura ed esecuzione. Tutte
+le operazioni devono essere effettuate attraverso tramite questi tipi di dati,
+che incapsulano tutte le informazioni contenute nelle ACL.
+
+La prima di queste funzioni che prendiamo in esame (si ricordi che come per
+tutte le altre per poterla usare occorre invocare il compilatore con l'opzione
+\texttt{-l acl}) è \funcd{acl\_init}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
in caso di fallimento verrà restituito un puntatore nullo di tipo
``\code{(acl\_t) NULL}'' e si dovrà, in questa come in tutte le funzioni
seguenti che restituiscono un oggetto di tipo \type{acl\_t}, confrontare il
-valore di ritorno della funzione con \val{NULL}.\footnote{a voler essere
- estremamente pignoli si dovrebbe usare ``\code{(acl\_t) NULL}'', ma è
- sufficiente fare un confronto direttamente con \val{NULL} essendo cura del
- compilatore fare le conversioni necessarie.}
+valore di ritorno della funzione con \val{NULL} (anche se, a voler essere
+estremamente pignoli, si dovrebbe usare ``\code{(acl\_t) NULL}'', ma è
+sufficiente fare un confronto direttamente con \val{NULL} essendo cura del
+compilatore fare le conversioni necessarie).
Una volta che si siano completate le operazioni sui dati di una ACL la memoria
allocata per un oggetto \type{acl\_t} dovrà essere liberata esplicitamente
Le due funzioni ritornano, con un oggetto di tipo \type{acl\_t}, il valore
della ACL correntemente associata ad un file, che può essere identificato
tramite un file descriptor usando \func{acl\_get\_fd} o con un
-\textit{pathname} usando \func{acl\_get\_file}. Nel caso di quest'ultima
-funzione, che può richiedere anche la ACL relativa ad una directory, il
-secondo argomento \param{type} consente di specificare se si vuole ottenere la
-ACL di default o quella di accesso. Questo argomento deve essere di tipo
-\typed{acl\_type\_t} e può assumere solo i due valori riportati in
-tab.~\ref{tab:acl_type}.
+\textit{pathname} usando \func{acl\_get\_file}.
+
+Nel caso di quest'ultima funzione, che può richiedere anche la ACL relativa ad
+una directory, il secondo argomento \param{type} consente di specificare se si
+vuole ottenere la ACL di default o quella di accesso. Questo argomento deve
+essere di tipo \typed{acl\_type\_t} e può assumere solo i due valori riportati
+in tab.~\ref{tab:acl_type}.
\begin{table}[htb]
\centering
verrà restituita una ACL vuota.
Infine si potrà creare una ACL direttamente dalla sua rappresentazione
-testuale con la funzione \funcd{acl\_from\_text}, il cui prototipo è:
+testuale con la funzione \funcd{acl\_from\_text}, il cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
la rappresentazione testuale della ACL che si vuole creare, la memoria
necessaria viene automaticamente allocata ed in caso di successo viene
restituito come valore di ritorno un oggetto di tipo \type{acl\_t} con il
-contenuto della stessa, che come per le precedenti funzioni, dovrà essere
+contenuto della stessa, che, come per le precedenti funzioni, dovrà essere
disallocato esplicitamente al termine del suo utilizzo.
La rappresentazione testuale di una ACL è quella usata anche dai comandi
\end{Example}
dove il tipo può essere uno fra \texttt{user}, \texttt{group}, \texttt{other}
e \texttt{mask}. Il qualificatore è presente solo per \texttt{user} e
-\texttt{group} e indica l'utente o il gruppo a cui la voce si riferisce; i
-permessi sono espressi con una tripletta di lettere analoga a quella usata per
-i permessi dei file.\footnote{vale a dire ``\texttt{r}'' per il permesso di
- lettura, ``\texttt{w}'' per il permesso di scrittura, ``\texttt{x}'' per il
- permesso di esecuzione (scritti in quest'ordine) e ``\texttt{-}'' per
- l'assenza del permesso.}
+\texttt{group} ed indica l'utente o il gruppo a cui la voce si riferisce,
+mentrei permessi sono espressi con una tripletta di lettere analoga a quella
+usata per i permessi dei file, vale a dire ``\texttt{r}'' per il permesso di
+lettura, ``\texttt{w}'' per il permesso di scrittura, ``\texttt{x}'' per il
+permesso di esecuzione (scritti in quest'ordine) e ``\texttt{-}'' per
+l'assenza del permesso.
Un possibile esempio di rappresentazione della ACL di un file ordinario a cui,
oltre ai permessi ordinari, si è aggiunto un altro utente con un accesso in
group::r--
other::r--
user:piccardi:r--
+group:gapil:r--
\end{Example}
Va precisato che i due tipi \texttt{user} e \texttt{group} sono usati
-rispettivamente per indicare delle voci relative ad utenti e
-gruppi,\footnote{cioè per voci di tipo \const{ACL\_USER\_OBJ} e
- \const{ACL\_USER} per \texttt{user} e \const{ACL\_GROUP\_OBJ} e
- \const{ACL\_GROUP} per \texttt{group}.} applicate sia a quelli proprietari
-del file che a quelli generici; quelle dei proprietari si riconoscono per
-l'assenza di un qualificatore, ed in genere si scrivono per prima delle altre.
-Il significato delle voci di tipo \texttt{mask} e \texttt{mark} è evidente. In
-questa forma si possono anche inserire dei commenti precedendoli con il
-carattere ``\texttt{\#}''.
+rispettivamente per indicare delle voci relative ad utenti e gruppi (cioè per
+voci di tipo \const{ACL\_USER\_OBJ} e \const{ACL\_USER} per \texttt{user} e
+\const{ACL\_GROUP\_OBJ} e \const{ACL\_GROUP} per \texttt{group}) applicate sia
+a quelli proprietari del file che a quelli generici. Quelle dei proprietari si
+riconoscono per l'assenza di un qualificatore, ed in genere si scrivono per
+prima delle altre. Il significato delle voci di tipo \texttt{mask} e
+\texttt{mark} è evidente. Usando questa forma estesa si possono anche inserire
+dei commenti nel testo precedendoli con il carattere ``\texttt{\#}''.
La forma breve prevede invece la scrittura delle singole voci su una riga,
separate da virgole; come specificatori del tipo di voce si possono usare le
testuale della ACL in caso di successo e \var{NULL} per un errore, nel qual
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida.
+ \item[\errcode{EINVAL}] o \param{acl} non è un puntatore ad una ACL o la ACL
+ che esso indica non è valida o non può esser tradotta in forma testuale.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per allocare i dati.
\end{errlist}
}
\end{funcproto}
-La funzione restituisce il puntatore ad una stringa terminata da NUL
-contenente la rappresentazione in forma estesa della ACL passata come
+La funzione restituisce il puntatore ad una stringa, terminata da un NUL,
+contenente la rappresentazione testuale in forma estesa della ACL passata come
argomento, ed alloca automaticamente la memoria necessaria. Questa dovrà poi
-essere liberata, quando non più necessaria, con \func{acl\_free}. Se
-nell'argomento \param{len\_p} si passa un valore puntatore ad una variabile
-intera in questa verrà restituita (come \textit{value result argument}) la
-dimensione della stringa con la rappresentazione testuale, non comprendente il
-carattere nullo finale.
+essere liberata, quando non più necessaria, con \func{acl\_free}. Se
+nell'argomento \param{len\_p} si passa come valore il puntatore ad una
+variabile intera, in questa verrà restituita (come \textit{value result
+ argument}) la dimensione della stringa con la rappresentazione testuale, non
+comprendente il carattere nullo finale.
La seconda funzione, che permette di controllare con una gran dovizia di
particolari la generazione della stringa contenente la rappresentazione
\hline
\hline
\constd{TEXT\_ABBREVIATE} & Stampa le voci in forma abbreviata.\\
- \constd{TEXT\_NUMERIC\_IDS} & non effettua la risoluzione numerica di
- \ids{UID} e \ids{GID}.\\
+ \constd{TEXT\_NUMERIC\_IDS} & Non effettua la risoluzione di
+ \ids{UID} e \ids{GID} lasciando i valori
+ numerici.\\
\constd{TEXT\_SOME\_EFFECTIVE}&Per ciascuna voce che contiene permessi che
vengono eliminati dalla \const{ACL\_MASK}
viene generato un commento con i permessi
}
\end{funcproto}
-Ottenuta con \func{acl\_size} la dimensione per il buffer di una ACL lo si
-potrà allocare direttamente con \func{malloc}. La rappresentazione binaria di
-una ACL si potrà invece ottenere con la funzione \funcd{acl\_copy\_ext}, il
-cui prototipo è:
+Ottenuta con \func{acl\_size} la dimensione del buffer necessaria per potervi
+memorizzare una ACL questo dovrà potrà essere allocato direttamente con
+\func{malloc}, ed a questo punto vi si potrà salvare la rappresentazione
+binaria della precedente ACL utilizzando la funzione \funcd{acl\_copy\_ext},
+il cui prototipo è:
\begin{funcproto}{
\fhead{sys/types.h}
della ACL in caso di successo e $-1$ per un errore, nel qual caso
\var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida o
- \param{size} è negativo o nullo.
+ \item[\errcode{EINVAL}] la ACL indicata da \param{acl} non è valida, o
+ \param{acl} non è un puntatore ad una ACL o \param{size} è negativo o
+ nullo.
\item[\errcode{ERANGE}] il valore di \param{size} è più piccolo della
- dimensione della rappresentazione della ACL.
+ dimensione della rappresentazione binaria della ACL.
\end{errlist}
}
\end{funcproto}
La funzione scriverà la rappresentazione binaria della ACL indicata da
-\param{acl} sul buffer di dimensione \param{size}
-all'indirizzo \param{buf\_p}, restituendo la dimensione della stessa come
-valore di ritorno. Qualora la dimensione della rappresentazione ecceda il
-valore di \param{size} la funzione fallirà con un errore di
-\errcode{ERANGE}. La funzione non ha nessun effetto sulla ACL indicata
-da \param{acl}.
+\param{acl} sul buffer di dimensione \param{size} all'indirizzo
+\param{buf\_p}, restituendo la dimensione della stessa come valore di
+ritorno. Qualora la dimensione della rappresentazione ecceda il valore di
+\param{size} la funzione fallirà con un errore di \errcode{ERANGE}. La
+funzione non ha nessun effetto sulla ACL indicata da \param{acl}.
Viceversa se si vuole ripristinare una ACL a partire da una rappresentazione
binaria si potrà usare la funzione \funcd{acl\_copy\_int}, il cui prototipo è:
% LocalWords: member scan attack EOVERFLOW BITS blkcnt rdev FDCWD functions
% LocalWords: faccessat grpid lacl AppArmor capsetp mygetfacl table Tb MSK
% LocalWords: LAZYTIME submount peer protected hardlink symlinks silly RDWR
+% LocalWords: renames unreachable CLOEXEC mkstemps mkostemps suffixlen Aug
+% LocalWords: prefissoXXXXXXsuffisso nell'I fstatat statx sull' drwxrwxrwt
+% LocalWords: Disalloca
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
-% LocalWords: renames unreachable CLOEXEC mkstemps mkostemps suffixlen Aug
-% LocalWords: prefissoXXXXXXsuffisso nell'I fstatat statx sull' drwxrwxrwt
-% LocalWords: Disalloca
projects / gapil.git / blobdiff