\subsection{I permessi per l'accesso ai file}
\label{sec:file_perm_overview}
-Il controllo di accesso ai file in unix segue un modello abbastanza semplice,
-ma adatto alla gran parte delle esigenze, in cui si dividono i permessi su tre
-livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem di
-tipo unix, e non è detto che sia applicabile a un filesystem
+Il controllo di accesso ai file in unix segue un modello abbastanza semplice
+(ma adatto alla gran parte delle esigenze) in cui si dividono i permessi su
+tre livelli. Si tenga conto poi che quanto diremo è vero solo per filesystem
+di tipo unix, e non è detto che sia applicabile a un filesystem
qualunque\footnote{ed infatti non è vero per il filesystem vfat di Windows,
per il quale i permessi vengono assegnati in maniera fissa con un opzione in
fase di montaggio}. Esistono inoltre estensioni che permettono di
Ad ogni file unix associa sempre l'utente che ne è proprietario (il cosiddetto
\textit{owner}) e il gruppo di appartenenza, secondo il meccanismo degli
-identificatori di utenti e gruppi (\textsl{uid} e \textsl{gid}). Questi valori
+identificatori di utenti e gruppi (\acr{uid} e \acr{gid}). Questi valori
sono accessibili da programma tramite i campi \var{st\_uid} e \var{st\_gid}
della struttura \var{stat} (si veda \secref{sec:file_stat}). Ad ogni file
viene inoltre associato un insieme di permessi che sono divisi in tre classi,
usati a gruppi di tre per indicare i permessi base di lettura, scrittura ed
esecuzione (indicati nei comandi di sistema con le lettere \cmd{w}, \cmd{r} e
\cmd{x}) ed applicabili rispettivamente al proprietario, al gruppo, a tutti
-gli altri. I restanti tre bit (\textsl{suid}, \textsl{sgid}, e
+gli altri. I restanti tre bit (\acr{suid}, \acr{sgid}, e
\textsl{sticky}) sono usati per indicare alcune caratteristiche più complesse
su cui torneremo in seguito (vedi \secref{sec:file_suid_sgid} e
\secref{sec:file_sticky}).
Per una spiegazione dettagliata degli identificatori associati ai processi si
veda \secref{sec:proc_perms}; normalmente, a parte quanto vedremo in
\secref{sec:file_suid_sgid}, l'\textit{effective user id} e
-l'\textit{effective group id} corrispondono a uid e gid dell'utente che ha
-lanciato il processo, mentre i \textit{supplementary group id} sono quelli dei
-gruppi cui l'utente appartiene.
-
-% Quando un processo cerca l'accesso al file esso controlla i propri uid e gid
-% confrontandoli con quelli del file e se l'operazione richiesta è compatibile
-% con i permessi associati al file essa viene eseguita, altrimenti viene
-% bloccata ed è restituito un errore di \texttt{EPERM}. Questo procedimento non
-% viene eseguito per l'amministratore di sistema (il cui uid è zero) il quale
-% a
-% pertanto accesso senza restrizione a qualunque file del sistema.
-
-% In realtà il procedimento è più complesso di quanto descritto in maniera
-% elementare qui; inoltre ad un processo sono associati diversi identificatori,
-% torneremo su questo in maggiori dettagli in seguito in
-% \secref{sec:proc_perms}.
+l'\textit{effective group id} corrispondono a \acr{uid} e \acr{gid}
+dell'utente che ha lanciato il processo, mentre i \textit{supplementary group
+ id} 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:
\item altrimenti l'accesso è negato
\end{itemize}
\item Se l'\textit{effective group id} del processo o uno dei
- \textit{supplementary group id} dei processi corrispondono al gid del file
- allora:
+ \textit{supplementary group id} dei processi corrispondono al \acr{gid} del
+ file allora:
\begin{itemize}
\item se il bit dei permessi d'accesso del gruppo è settato, l'accesso è
consentito,
\item altrimenti l'accesso è negato
\end{itemize}
\item se il bit dei permessi d'accesso per tutti gli altri è settato,
- l'accesso è consentito, altrimenti l'accesso è negato.
+ l'accesso è consentito, altrimenti l'accesso è negato.
\end{itemize}
Si tenga presente che questi passi vengono eseguiti esattamente in
tutti gli altri non vengono controllati.
-\subsection{I bit \textsl{suid} e \textsl{sgid}}
+\subsection{I bit \acr{suid} e \acr{sgid}}
\label{sec:file_suid_sgid}
Come si è accennato (in \secref{sec:file_perm_overview}) nei dodici bit del
campo \var{st\_mode} usati per il controllo di accesso oltre ai bit dei
permessi veri e propri, ci sono altri tre bit che vengono usati per indicare
alcune proprietà speciali dei file. Due di questi sono i bit detti
-\textsl{suid} (o \textit{set-user-ID bit}) e \textsl{sgid} (o
+\acr{suid} (o \textit{set-user-ID bit}) e \acr{sgid} (o
\textit{set-group-ID bit}) che sono identificati dalle constanti
\macro{S\_ISUID} e \macro{S\_ISGID}.
Come spiegato in dettaglio in \secref{sec:proc_exec}, quando si lancia un
programma il comportamendo normale del kernel è quello di settare
l'\textit{effective user id} e l'\textit{effective group id} del nuovo
-processo all'uid e al gid del processo corrente, che normalmente corrispondono
-dell'utente con cui si è entrati nel sistema.
+processo all'\acr{uid} e al \acr{gid} del processo corrente, che normalmente
+corrispondono dell'utente con cui si è entrati nel sistema.
Se però il file del programma\footnote{per motivi di sicurezza il kernel
ignora i bit \acr{suid} e \acr{sgid} per gli script eseguibili} (che
veda \secref{sec:file_ownership} per una spiegazione dettagliata al
proposito).
-Infine Linux utilizza il bit \textsl{sgid} per una ulteriore estensione
-mutuata da SVR4. Il caso in cui il file abbia il bit \textsl{sgid} settato ma
+Infine Linux utilizza il bit \acr{sgid} per una ulteriore estensione
+mutuata da SVR4. Il caso in cui il file abbia il bit \acr{sgid} settato ma
non il corrispondente bit di esecuzione viene utilizzato per attivare per
quel file il \textit{mandatory locking} (argomento che affronteremo nei
dettagli in \secref{sec:xxx_mandatory_lock}).
descritto in \secref{sec:file_dir_creat_rem}).
Lo standard POSIX prescrive che l'uid del nuovo file corrisponda
-all'\textit{effective user id} del processo che lo crea; per il gid invece
-prevede due diverse possibilità:
+all'\textit{effective user id} del processo che lo crea; per il \acr{gid}
+invece prevede due diverse possibilità:
\begin{itemize}
-\item il gid del file corrisponde all'\textit{effective group id} del processo.
-\item il gid del file corrisponde al gid della directory in cui esso è creato.
+\item il \acr{gid} del file corrisponde all'\textit{effective group id} del
+ processo.
+\item il \acr{gid} del file corrisponde al 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 gid
-del processo, se però la directory in cui viene creato il file ha il bit
-\textsl{sgid} settato allora viene usata la seconda opzione..
+norma cioè il nuovo file viene creato, seguendo la prima opzione, con il
+\acr{gid} del processo, se però la directory in cui viene creato il file ha il
+bit \acr{sgid} settato allora viene usata la seconda opzione..
-Usare la semantica BSD ha il vantaggio che il gid viene sempre automaticamente
-propagato, restando coerente a quello della directory di partenza, in tutte le
-sottodirectory. La semantica SVR4 offre una maggiore possibilità di scelta, ma
-per ottenere lo stesso risultato necessita che per le nuove directory venga
-anche propagato anche il bit sgid. Questo è comunque il comportamento di
-default di \func{mkdir}, ed é in questo modo ad esempio che Debian assicura
-che le sottodirectory create nelle home di un utente restino sempre con il gid
-del gruppo primario dello stesso.
+Usare la semantica BSD ha il vantaggio che il \acr{gid} viene sempre
+automaticamente propagato, restando coerente a quello della directory di
+partenza, in tutte le sottodirectory. La semantica SVR4 offre una maggiore
+possibilità di scelta, ma per ottenere lo stesso risultato necessita che per
+le nuove directory venga anche propagato anche il bit \acr{sgid}. Questo è
+comunque il comportamento di default di \func{mkdir}, ed é in questo modo ad
+esempio che Debian assicura che le sottodirectory create nelle home di un
+utente restino sempre con il \acr{gid} del gruppo primario dello stesso.
\subsection{La funzione \texttt{access}}
\item per via della semantica SVR4 nella creazione dei nuovi file, si può
avere il caso in cui il file creato da un processo è assegnato a un gruppo
per il quale il processo non ha privilegi. Per evitare che si possa
- assegnare il bit \textsl{sgid} ad un file appartenente a un gruppo per cui
+ assegnare il bit \acr{sgid} ad un file appartenente a un gruppo per cui
non si hanno diritti, questo viene automaticamente cancellato (senza
notifica di errore) da \var{mode} qualora il gruppo del file non corrisponda
a quelli associati al processo (la cosa non avviene quando
valore per \var{owner} e \var{group} i valori restano immutati.
Quando queste funzioni sono chiamate con successo da un processo senza i
-privilegi di root entrambi i bit \textsl{suid} e \textsl{sgid} vengono
-cancellati. Questo non avviene per il bit \textsl{sgid} nel caso in cui esso
+privilegi di root entrambi i bit \acr{suid} e \acr{sgid} vengono
+cancellati. Questo non avviene per il bit \acr{sgid} nel caso in cui esso
sia usato (in assenza del corrispondente permesso di esecuzione) per indicare
che per il file è attivo il \textit{mandatory locking}.
standard POSIX definisce un insieme di macro per verificare il tipo di files,
queste vengono usate anche da Linux che supporta pure le estensioni per link
simbolici e socket definite da BSD, l'elenco completo di tutte le macro
-definite in GNU/Linux è riportato in \ntab:
+definite in GNU/Linux è riportato in \ntab.
\begin{table}[htb]
\centering
\footnotesize
anche ad un file che non esiste; ad esempio possiamo creare un file temporaneo
nella nostra directory con un link del tipo:
\begin{verbatim}
-$ln -s /tmp/tmp_file temporaneo
+$ ln -s /tmp/tmp_file temporaneo
\end{verbatim}%$
ma anche se \file{/tmp/tmp\_file} non esiste. Aprendo in scrittura
\file{temporaneo} questo verrà scritto; ma se cercassimo di accederlo in sola
parlavamo in \secref{sec:file_vfs}) in una opportuna struttura
\texttt{struct dirent}.
+(NdA Il resto va scritto!!! É noioso e lo farò più avanti).
+
+
\subsection{La directory di lavoro}
\label{sec:file_work_dir}
fatta per compatibilità all'indietro con BSD, che non consente di specificare
la dimensione del buffer; esso deve essere allocato in precedenza ed avere una
dimensione superiore a \texttt{PATH\_MAX} (di solito 256 bytes, vedi
-\secref{sec:xxx_limits}; il problema è che in Linux non esiste una dimensione
+\secref{sec:xxx_limits}); il problema è che in Linux non esiste una dimensione
superiore per un pathname, per cui non è detto che il buffer sia sufficiente a
contenere il nome del file, e questa è la ragione principale per cui questa
funzione è deprecata.
projects / gapil.git / blobdiff