X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=1f0edcd66b40e82a0c62684b45025bd8aeb4170a;hp=db127ae9f548fb956646cdd02899dab01b1dc085;hb=429f6e0da8fc282eb6611b6fe83fdf58ae8da611;hpb=ffde006b4b38517dd190c394b769c619d13174a5 diff --git a/filedir.tex b/filedir.tex index db127ae..1f0edcd 100644 --- a/filedir.tex +++ b/filedir.tex @@ -22,10 +22,10 @@ le funzioni usate per gestirne i vari aspetti. \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 @@ -34,7 +34,7 @@ controllo di accesso molto pi 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, @@ -47,7 +47,7 @@ sono espressi da un numero di 12 bit; di questi i nove meno significativi sono 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}). @@ -149,22 +149,9 @@ del processo. 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: @@ -184,15 +171,15 @@ 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 @@ -203,22 +190,22 @@ processo appartiene ad un gruppo appropriato, in questo caso i permessi per 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 @@ -258,8 +245,8 @@ con questi bit l'uso della semantica BSD nella creazione di nuovi file (si 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}). @@ -322,26 +309,28 @@ stesso problema di presenta per la creazione di nuove directory (procedimento 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}} @@ -489,7 +478,7 @@ particolare: \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 @@ -591,8 +580,8 @@ Un'altra estensione rispetto allo standard POSIX 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}. @@ -699,7 +688,7 @@ Dato che il valore numerico pu 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 @@ -1356,7 +1345,7 @@ Un secondo punto da tenere presente 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 @@ -1420,6 +1409,9 @@ la funzione \texttt{opendir} apre uno di questi stream e la funzione 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} @@ -1467,7 +1459,7 @@ Di questa funzione esiste una versione \texttt{char * getwd(char * buffer)} 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.