X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=filedir.tex;h=1f0edcd66b40e82a0c62684b45025bd8aeb4170a;hp=cbd718bdc7582cb4c0d1f567a5405e8aba1ac1bc;hb=429f6e0da8fc282eb6611b6fe83fdf58ae8da611;hpb=43c4caa7e3d1c681d26f4381ec19f41325786ea1 diff --git a/filedir.tex b/filedir.tex index cbd718b..1f0edcd 100644 --- a/filedir.tex +++ b/filedir.tex @@ -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}.