From 4e566a40155b75d19f8cf3f3207e4a3df272245d Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Sun, 18 Mar 2012 15:26:39 +0000 Subject: [PATCH] maeriale su reboot, revisionata la parte utenti e gruppi e utmp. --- system.tex | 651 +++++++++++++++++++++++++++++++++-------------------- 1 file changed, 405 insertions(+), 246 deletions(-) diff --git a/system.tex b/system.tex index b8b745b..c5bcd09 100644 --- a/system.tex +++ b/system.tex @@ -541,22 +541,32 @@ di questi parametri sono: \item il numero massimo di file aperti \end{itemize*} + + +\index{file!filesystem~\texttt {/proc}!definizione|(} + Dato che fin dall'inizio i parametri erano organizzati in una struttura albero, è parso naturale rimappare questa organizzazione utilizzando il -filesystem \file{/proc}. Questo è un filesystem virtuale, generato -direttamente dal kernel, che non fa riferimento a nessun dispositivo fisico, -ma presenta in forma di file i dati di alcune delle strutture interne del -kernel stesso. Il suo utilizzo principale, come denuncia il nome stesso, è -quello di fornire una interfaccia per ricavare i dati dei processi (venne -introdotto a questo scopo su BSD), ma nel corso del tempo il suo uso è stato -ampliato. - -In particolare l'albero dei valori di \func{sysctl} viene presentato in forma -di una gerarchia di file e directory a partire dalla directory -\file{/proc/sys}, cosicché è possibile accedere al valore di un parametro del -kernel tramite il \textit{pathname} ad un file sotto \file{/proc/sys} -semplicemente leggendone il contenuto, così come si può modificare un -parametro scrivendo sul file ad esso corrispondente. +filesystem \file{/proc}. Questo è un filesystem completamente virtuale, il cui +contenuto è generato direttamente dal kernel, che non fa riferimento a nessun +dispositivo fisico, ma presenta in forma di file e directory i dati di alcune +delle strutture interne del kernel stesso. Il suo utilizzo principale, come +denuncia il nome stesso, è quello di fornire una interfaccia per ottenere i +dati relativi ai processi (venne introdotto a questo scopo su BSD), ma nel +corso del tempo il suo uso è stato ampliato. + +All'interno di questo filesystem sono pertanto presenti una serie di file che +riflettono il contenuto dei parametri del kernel (molti dei quali accessibili +in sola lettura) e in altrettante directory, nominate secondo il relativo +\ids{PID}, vengono mantenute le informazioni relative a ciascun processo +attivo nel sistema. + +In particolare l'albero dei valori dei parametri di sistema impostabili con +\func{sysctl} viene presentato in forma di una gerarchia di file e directory a +partire dalla directory \file{/proc/sys}, cosicché è possibile accedere al +valore di un parametro del kernel tramite il \textit{pathname} ad un file +sotto \file{/proc/sys} semplicemente leggendone il contenuto, così come si può +modificare un parametro scrivendo sul file ad esso corrispondente. Il kernel si occupa di generare al volo il contenuto ed i nomi dei file corrispondenti ai vari parametri che sono presenti, e questo ha il grande @@ -565,13 +575,14 @@ di permettere la navigazione dell'albero in modo da riconoscere quali parametri sono presenti senza dover cercare un valore all'interno di una pagina di manuale. -Inizialmente l'uso del filesystem \file{/proc} serviva soltanto a replicare, -con altrettante corrispondenze ai file presenti in \file{/proc/sys}, i valori -dei parametri usati da \func{sysctl}, ma vista la assoluta naturalità -dell'interfaccia, e la sua maggiore efficienza, nelle versioni più recenti del -kernel questa è diventata la modalità canonica per modificare i parametri del -kernel, evitando di dover ricorrere all'uso di una \textit{system call} -specifica che prima o poi verrà eliminata. +Inizialmente l'uso del filesystem \file{/proc} serviva soltanto a replicare +l'accesso, con altrettante corrispondenze ai file presenti in +\file{/proc/sys}, ai parametri impostabili tradizionalmente con \func{sysctl}, +ma vista la assoluta naturalità dell'interfaccia, e la sua maggiore +efficienza, nelle versioni più recenti del kernel questa è diventata la +modalità canonica per modificare i parametri del kernel, evitando di dover +ricorrere all'uso di una \textit{system call} specifica che pur essendo ancora +presente, prima o poi verrà eliminata. Nonostante la semplificazione nella gestione ottenuta con l'uso di \file{/proc/sys} resta il problema generale di conoscere il significato di @@ -581,12 +592,12 @@ buona parte di quelli può importanti sono descritti dalla documentazione inclusa nei sorgenti del kernel, nella directory \file{Documentation/sysctl}. Ma oltre alle informazioni che sostituiscono quelle ottenibili dalla ormai -deprecata \func{sysctl} dentro \file{proc} sono disponibili moltissime altre -informazioni, fra cui ad esempio anche quelle fornite dalla funzione -\funcd{uname},\footnote{con Linux ci sono in realtà 3 \textit{system call} - diverse per le dimensioni delle stringe restituite, le prime due usano - rispettivamente delle lunghezze di 9 e 65 byte, la terza usa anch'essa 65 - byte, ma restituisce anche l'ultimo campo, \var{domainname}, con una +deprecata \func{sysctl} dentro \file{/proc} sono disponibili moltissime altre +informazioni, fra cui ad esempio anche quelle fornite dalla funzione di +sistema \funcd{uname},\footnote{con Linux ci sono in realtà 3 \textit{system + call} diverse per le dimensioni delle stringhe restituite, le prime due + usano rispettivamente delle lunghezze di 9 e 65 byte, la terza usa anch'essa + 65 byte, ma restituisce anche l'ultimo campo, \var{domainname}, con una lunghezza di 257 byte, la \acr{glibc} provvede a mascherare questi dettagli usando la versione più recente disponibile.} il cui prototipo è: @@ -622,8 +633,9 @@ due costanti per queste dimensioni, \const{\_UTSNAME\_LENGTH} per i campi standard e \const{\_UTSNAME\_DOMAIN\_LENGTH} per quello relativo al nome di dominio, altri sistemi usano nomi diversi come \const{SYS\_NMLN} o \const{\_SYS\_NMLN} o \const{UTSLEN} che possono avere valori diversi. Dato -che il buffer deve essere preallocata l'unico modo per farlo in maniera sicura -è allora usare come dimensione il valore ottenuto con \code{sizeof(utsname)}. +che il buffer per \struct{utsname} deve essere preallocato l'unico modo per +farlo in maniera sicura è allora usare come dimensione il valore ottenuto con +\code{sizeof(utsname)}. Le informazioni vengono restituite in ciascuno dei singoli campi di \struct{utsname} in forma di stringhe terminate dal carattere NUL. In @@ -634,10 +646,9 @@ particolare dette informazioni sono: \item il nome della release del kernel; \item il nome della versione del kernel; \item il tipo di hardware della macchina; -\item il nome del domino (il \textit{doaminname}). +\item il nome del domino (il \textit{domainname}); \end{itemize*} - -Ma l'ultima di queste informazioni è stata aggiunta di recente e non è +ma l'ultima di queste informazioni è stata aggiunta di recente e non è prevista dallo standard POSIX, per questo essa è accessibile, come mostrato in fig.~\ref{fig:sys_utsname}, solo se si è definita la macro \macro{\_GNU\_SOURCE}. @@ -647,10 +658,10 @@ Come accennato queste stesse informazioni, anche se a differenza di direttamente tramite il filesystem \file{/proc}, esse infatti sono mantenute rispettivamente nei file \sysctlrelfile{kernel}{ostype}, \sysctlrelfile{kernel}{hostname}, \sysctlrelfile{kernel}{osrelease}, -\sysctlrelfile{kernel}{version} e \sysctlrelfile{kernel}{domainname} di -\file{/proc/sys/kernel/}. - +\sysctlrelfile{kernel}{version} e \sysctlrelfile{kernel}{domainname} che si +trovano sotto la directory \file{/proc/sys/kernel/}. +\index{file!filesystem~\texttt {/proc}!definizione|)} @@ -658,10 +669,10 @@ rispettivamente nei file \sysctlrelfile{kernel}{ostype}, \label{sec:sys_management} In questa sezione prenderemo in esame le interfacce di programmazione messe a -disposizione per affrontare una serie di tematiche di gestione generale del -sistema come quelle relative alla gestione di utenti e gruppi, delle -informazioni relative ai collegamenti al sistema, dello spegnimento e del -riavvio di una macchina. +disposizione per affrontare una serie di tematiche attinenti la gestione +generale del sistema come quelle relative alla gestione di utenti e gruppi, al +trattamento delle informazioni relative ai collegamenti al sistema, alle +modalità per effettuare lo spegnimento o il riavvio di una macchina. \subsection{La gestione delle informazioni su utenti e gruppi} @@ -670,40 +681,44 @@ riavvio di una macchina. Tradizionalmente le informazioni utilizzate nella gestione di utenti e gruppi (password, corrispondenze fra nomi simbolici e \ids{UID} numerici, home directory, ecc.) venivano registrate all'interno dei due file di testo -\conffile{/etc/passwd} ed \conffile{/etc/group},\footnote{in realtà oltre a - questi nelle distribuzioni più recenti è stato introdotto il sistema delle - \textit{shadow password} che prevede anche i due file \conffile{/etc/shadow} - e \conffile{/etc/gshadow}, in cui sono state spostate le informazioni di - autenticazione (ed inserite alcune estensioni) per toglierle dagli altri - file che devono poter essere letti per poter effettuare l'associazione fra - username e \ids{UID}.} il cui formato è descritto dalle relative pagine del -manuale\footnote{nella quinta sezione, quella dei file di configurazione, - occorre cioè usare \cmd{man 5 passwd} dato che altrimenti si avrebbe la - pagina di manuale del comando \cmd{passwd}.} e tutte le funzioni che -richiedevano l'accesso a queste informazione andavano a leggere direttamente -il contenuto di questi file. - -Col tempo però questa impostazione ha incominciato a mostrare dei limiti: da +\conffile{/etc/passwd} ed \conffile{/etc/group}, il cui formato è descritto +dalle relative pagine del manuale\footnote{nella quinta sezione, quella dei + file di configurazione (esistono comandi corrispondenti), una trattazione + sistemistica dell'intero argomento coperto in questa sezione si consulti + sez.~4.3 di \cite{AGL}.} e tutte le funzioni che richiedevano l'accesso a +queste informazione andavano a leggere direttamente il contenuto di questi +file. + +In realtà oltre a questi due file da molto tempo gran parte dei sistemi +unix-like usano il cosiddetto sistema delle \textit{shadow password} che +prevede anche i due file \conffile{/etc/shadow} e \conffile{/etc/gshadow}, in +cui sono state spostate le informazioni di autenticazione (ed inserite alcune +estensioni di gestione avanzata) per toglierle dagli altri file che devono +poter essere letti da qualunque processo per poter effettuare l'associazione +fra username e \ids{UID}. + +Col tempo però questa impostazione ha incominciato a mostrare dei limiti. Da una parte il meccanismo classico di autenticazione è stato ampliato, ed oggi la maggior parte delle distribuzioni di GNU/Linux usa la libreria PAM (sigla che sta per \textit{Pluggable Authentication Method}) che fornisce una -interfaccia comune per i processi di autenticazione,\footnote{il - \textit{Pluggable Authentication Method} è un sistema modulare, in cui è - possibile utilizzare anche più meccanismi insieme, diventa così possibile - avere vari sistemi di riconoscimento (biometria, chiavi hardware, ecc.), - diversi formati per le password e diversi supporti per le informazioni, il - tutto in maniera trasparente per le applicazioni purché per ciascun - meccanismo si disponga della opportuna libreria che implementa l'interfaccia - di PAM.} svincolando completamente le singole applicazione dai dettagli del -come questa viene eseguita e di dove vengono mantenuti i dati relativi; -dall'altra con il diffondersi delle reti la necessità di centralizzare le -informazioni degli utenti e dei gruppi per insiemi di macchine, in modo da -mantenere coerenti i dati, ha portato anche alla necessità di poter recuperare -e memorizzare dette informazioni su supporti diversi, introducendo il sistema -del \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch} che +interfaccia comune per i processi di autenticazione, svincolando completamente +le singole applicazioni dai dettagli del come questa viene eseguita e di dove +vengono mantenuti i dati relativi. Si tratta di un sistema modulare, in cui è +possibile utilizzare anche più meccanismi insieme, diventa così possibile +avere vari sistemi di riconoscimento (biometria, chiavi hardware, ecc.), +diversi formati per le password e diversi supporti per le informazioni. Il +tutto avviene in maniera trasparente per le applicazioni purché per ciascun +meccanismo si disponga della opportuna libreria che implementa l'interfaccia +di PAM. + +Dall'altra parte, il diffondersi delle reti e la necessità di centralizzare le +informazioni degli utenti e dei gruppi per insiemi di macchine e servizi +all'interno di una stessa organizzazione, in modo da mantenere coerenti i +dati, ha portato anche alla necessità di poter recuperare e memorizzare dette +informazioni su supporti diversi dai file citati, introducendo il sistema del +\itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch} che tratteremo brevemente più avanti (in sez.~\ref{sec:sock_resolver}) dato che la -maggior parte delle sua applicazioni sono relative alla risoluzioni di nomi di -rete. +sua applicazione è cruciale nella procedura di risoluzione di nomi di rete. In questo paragrafo ci limiteremo comunque a trattare le funzioni classiche per la lettura delle informazioni relative a utenti e gruppi tralasciando @@ -721,37 +736,39 @@ queste sono del tutto generiche e si appoggiano direttamente al \textit{Name sia il supporto su cui esse vengono mantenute. Per leggere le informazioni relative ad un utente si possono usare due funzioni, \funcd{getpwuid} e \funcd{getpwnam}, i cui prototipi sono: -\begin{functions} - \headdecl{pwd.h} - \headdecl{sys/types.h} - \funcdecl{struct passwd *getpwuid(uid\_t uid)} - - \funcdecl{struct passwd *getpwnam(const char *name)} - Restituiscono le informazioni relative all'utente specificato. - - \bodydesc{Le funzioni ritornano il puntatore alla struttura contenente le - informazioni in caso di successo e \val{NULL} nel caso non sia stato - trovato nessun utente corrispondente a quanto specificato.} -\end{functions} +\begin{funcproto}{ +\fhead{pwd.h} +\fhead{sys/types.h} +\fdecl{struct passwd *getpwuid(uid\_t uid)} +\fdecl{struct passwd *getpwnam(const char *name)} +\fdesc{Restituiscono le informazioni relative all'utente specificato.} +} + +{Le funzioni ritornano il puntatore alla struttura contenente le informazioni + in caso di successo e \val{NULL} nel caso non sia stato trovato nessun + utente corrispondente a quanto specificato, nel qual caso \var{errno} + assumerà il valore riportato dalle funzioni sottostanti.} +\end{funcproto} Le due funzioni forniscono le informazioni memorizzate nel registro degli -utenti (che nelle versioni più recenti possono essere ottenute attraverso PAM) -relative all'utente specificato attraverso il suo \ids{UID} o il nome di -login. Entrambe le funzioni restituiscono un puntatore ad una struttura di -tipo \struct{passwd} la cui definizione (anch'essa eseguita in -\headfile{pwd.h}) è riportata in fig.~\ref{fig:sys_passwd_struct}, dove è pure -brevemente illustrato il significato dei vari campi. +utenti (che nelle versioni più recenti per la parte di credenziali di +autenticazione vengono ottenute attraverso PAM) relative all'utente +specificato attraverso il suo \ids{UID} o il nome di login. Entrambe le +funzioni restituiscono un puntatore ad una struttura di tipo \struct{passwd} +la cui definizione (anch'essa eseguita in \headfile{pwd.h}) è riportata in +fig.~\ref{fig:sys_passwd_struct}, dove è pure brevemente illustrato il +significato dei vari campi. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{\textwidth} + \begin{minipage}[c]{0.8\textwidth} \includestruct{listati/passwd.h} \end{minipage} \normalsize - \caption{La struttura \structd{passwd} contenente le informazioni relative ad - un utente del sistema.} + \caption{La struttura \structd{passwd} contenente le informazioni relative + ad un utente del sistema.} \label{fig:sys_passwd_struct} \end{figure} @@ -762,22 +779,20 @@ fanno riferimento. Ovviamente questo implica che dette funzioni non possono essere \index{funzioni!rientranti} rientranti; per questo motivo ne esistono anche due versioni alternative (denotate dalla solita estensione \code{\_r}), i cui prototipi sono: -\begin{functions} - \headdecl{pwd.h} - - \headdecl{sys/types.h} - - \funcdecl{struct passwd *getpwuid\_r(uid\_t uid, struct passwd *password, + +\begin{funcproto}{ +\fhead{pwd.h} +\fhead{sys/types.h} +\fdecl{struct passwd *getpwuid\_r(uid\_t uid, struct passwd *password, char *buffer, size\_t buflen, struct passwd **result)} - - \funcdecl{struct passwd *getpwnam\_r(const char *name, struct passwd +\fdecl{struct passwd *getpwnam\_r(const char *name, struct passwd *password, char *buffer, size\_t buflen, struct passwd **result)} +\fdesc{Restituiscono le informazioni relative all'utente specificato.} +} - Restituiscono le informazioni relative all'utente specificato. - - \bodydesc{Le funzioni ritornano 0 in caso di successo e un codice d'errore - altrimenti, nel qual caso \var{errno} sarà impostata opportunamente.} -\end{functions} +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà il valore riportato dalle funzioni sottostanti.} +\end{funcproto} In questo caso l'uso è molto più complesso, in quanto bisogna prima allocare la memoria necessaria a contenere le informazioni. In particolare i valori @@ -791,29 +806,52 @@ dati non possano essere contenuti nei byte specificati da \param{buflen}, la funzione fallirà restituendo \errcode{ERANGE} (e \param{result} sarà comunque impostato a \val{NULL}). +Sia queste versioni rientranti che precedenti gli errori eventualmente +riportati in \var{errno} in caso di fallimento dipendono dalla sottostanti +funzioni di sistema usate per ricavare le informazioni (si veda quanto +illustrato in sez.~\ref{sec:sys_errno}) per cui se lo si vuole utilizzare è +opportuno inizializzarlo a zero prima di invocare le funzioni per essere +sicuri di non avere un residuo di errore da una chiamata precedente. Il non +aver trovato l'utente richiesto infatti può essere dovuto a diversi motivi (a +partire dal fatto che non esista) per cui si possono ottenere i valori di +errore più vari a seconda dei casi. + Del tutto analoghe alle precedenti sono le funzioni \funcd{getgrnam} e -\funcd{getgrgid} (e le relative analoghe \index{funzioni!rientranti} -rientranti con la stessa estensione \code{\_r}) che permettono di leggere le -informazioni relative ai gruppi, i loro prototipi sono: -\begin{functions} - \headdecl{grp.h} - \headdecl{sys/types.h} +\funcd{getgrgid} che permettono di leggere le informazioni relative ai gruppi, +i loro prototipi sono: - \funcdecl{struct group *getgrgid(gid\_t gid)} - - \funcdecl{struct group *getgrnam(const char *name)} - - \funcdecl{struct group *getpwuid\_r(gid\_t gid, struct group *password, - char *buffer, size\_t buflen, struct group **result)} - - \funcdecl{struct group *getpwnam\_r(const char *name, struct group - *password, char *buffer, size\_t buflen, struct group **result)} +\begin{funcproto}{ +\fhead{grp.h} +\fhead{sys/types.h} +\fdecl{struct group *getgrgid(gid\_t gid)} +\fdecl{struct group *getgrnam(const char *name)} +\fdesc{Restituiscono le informazioni relative al gruppo specificato.} +} + +{Le funzioni ritornano il puntatore alla struttura contenente le informazioni + in caso di successo e \val{NULL} nel caso non sia stato trovato nessun + utente corrispondente a quanto specificato, nel qual caso \var{errno} + assumerà il valore riportato dalle funzioni sottostanti.} +\end{funcproto} + +Come per le precedenti per gli utenti esistono anche le analoghe versioni +\index{funzioni!rientranti} rientranti che di nuovo utilizzano la stessa +estensione \code{\_r}; i loro prototipi sono: + +\begin{funcproto}{ +\fhead{grp.h} +\fhead{sys/types.h} +\fdecl{int getgrgid\_r(gid\_t gid, struct group *grp, char *buf, + size\_t buflen, struct group **result)} +\fdecl{int getgrnam\_r(const char *name, struct group *grp, char *buf, + size\_t buflen, struct group **result)} +\fdesc{Restituiscono le informazioni relative al gruppo specificato.} +} + +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà il valore riportato dalle funzioni sottostanti.} +\end{funcproto} - Restituiscono le informazioni relative al gruppo specificato. - - \bodydesc{Le funzioni ritornano 0 in caso di successo e un codice d'errore - altrimenti, nel qual caso \var{errno} sarà impostata opportunamente.} -\end{functions} Il comportamento di tutte queste funzioni è assolutamente identico alle precedenti che leggono le informazioni sugli utenti, l'unica differenza è che @@ -824,7 +862,7 @@ fig.~\ref{fig:sys_group_struct}. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{\textwidth} + \begin{minipage}[c]{0.8\textwidth} \includestruct{listati/group.h} \end{minipage} \normalsize @@ -838,13 +876,13 @@ direttamente dal file delle password in \conffile{/etc/passwd} che tramite il sistema del \itindex{Name~Service~Switch~(NSS)} \textit{Name Service Switch} e sono completamente generiche. Si noti però che non c'è una funzione che permetta di impostare direttamente una password.\footnote{in realtà questo può - essere fatto ricorrendo a PAM, ma questo è un altro discorso.} Dato che -POSIX non prevede questa possibilità esiste un'altra interfaccia che lo fa, -derivata da SVID le cui funzioni sono riportate in -tab.~\ref{tab:sys_passwd_func}. Questa però funziona soltanto quando le -informazioni sono mantenute su un apposito file di \textsl{registro} di utenti -e gruppi, con il formato classico di \conffile{/etc/passwd} e -\conffile{/etc/group}. + essere fatto ricorrendo alle funzioni della libreria PAM, ma questo non è un + argomento che trattremo qui.} Dato che POSIX non prevede questa possibilità +esiste un'altra interfaccia che lo fa, derivata da SVID le cui funzioni sono +riportate in tab.~\ref{tab:sys_passwd_func}. Questa interfaccia però funziona +soltanto quando le informazioni sono mantenute su un apposito file di +\textsl{registro} di utenti e gruppi, con il formato classico di +\conffile{/etc/passwd} e \conffile{/etc/group}. \begin{table}[htb] \footnotesize @@ -885,15 +923,17 @@ e gruppi, con il formato classico di \conffile{/etc/passwd} e % TODO mancano i prototipi di alcune delle funzioni -Dato che oramai la gran parte delle distribuzioni di GNU/Linux utilizzano -almeno le \textit{shadow password} (quindi con delle modifiche rispetto al -formato classico del file \conffile{/etc/passwd}), si tenga presente che le -funzioni di questa interfaccia che permettono di scrivere delle voci in un +Dato che oramai tutte le distribuzioni di GNU/Linux utilizzano le +\textit{shadow password} (quindi con delle modifiche rispetto al formato +classico del file \conffile{/etc/passwd}), si tenga presente che le funzioni +di questa interfaccia che permettono di scrivere delle voci in un \textsl{registro} degli utenti (cioè \func{putpwent} e \func{putgrent}) non hanno la capacità di farlo specificando tutti i contenuti necessari rispetto a -questa estensione. Per questo motivo l'uso di queste funzioni è deprecato, in -quanto comunque non funzionale, pertanto ci limiteremo a fornire soltanto -l'elenco di tab.~\ref{tab:sys_passwd_func}, senza nessuna spiegazione +questa estensione. + +Per questo motivo l'uso di queste funzioni è deprecato, in quanto comunque non +funzionale rispetto ad un sistema attuale, pertanto ci limiteremo a fornire +soltanto l'elenco di tab.~\ref{tab:sys_passwd_func}, senza nessuna spiegazione ulteriore. Chi volesse insistere ad usare questa interfaccia può fare riferimento alle pagine di manuale delle rispettive funzioni ed al manuale delle \acr{glibc} per i dettagli del funzionamento. @@ -903,26 +943,24 @@ delle \acr{glibc} per i dettagli del funzionamento. \subsection{Il registro della \textsl{contabilità} degli utenti} \label{sec:sys_accounting} -L'ultimo insieme di funzioni relative alla gestione del sistema che +Un altro insieme di funzioni relative alla gestione del sistema che esamineremo è quello che permette di accedere ai dati del registro della cosiddetta \textsl{contabilità} (o \textit{accounting}) degli utenti. In esso vengono mantenute una serie di informazioni storiche relative sia agli utenti -che si sono collegati al sistema, (tanto per quelli correntemente collegati, -che per la registrazione degli accessi precedenti), sia relative all'intero +che si sono collegati al sistema, tanto per quelli correntemente collegati, +che per la registrazione degli accessi precedenti, sia relative all'intero sistema, come il momento di lancio di processi da parte di \cmd{init}, il cambiamento dell'orologio di sistema, il cambiamento di runlevel o il riavvio della macchina. -I dati vengono usualmente\footnote{questa è la locazione specificata dal - \textit{Linux Filesystem Hierarchy Standard}, adottato dalla gran parte - delle distribuzioni.} memorizzati nei due file \file{/var/run/utmp} e -\file{/var/log/wtmp}.\footnote{non si confonda quest'ultimo con il simile - \file{/var/log/btmp} dove invece vengono memorizzati dal programma di login - tutti tentativi di accesso fallito.} Quando un utente si collega viene -aggiunta una voce a \file{/var/run/utmp} in cui viene memorizzato il nome di -login, il terminale da cui ci si collega, l'\ids{UID} della shell di login, -l'orario della connessione ed altre informazioni. La voce resta nel file fino -al logout, quando viene cancellata e spostata in \file{/var/log/wtmp}. +I dati vengono usualmente memorizzati nei due file \file{/var/run/utmp} e +\file{/var/log/wtmp}. che sono quelli previsti dal \textit{Linux Filesystem + Hierarchy Standard}, adottato dalla gran parte delle distribuzioni. Quando +un utente si collega viene aggiunta una voce a \file{/var/run/utmp} in cui +viene memorizzato il nome di login, il terminale da cui ci si collega, +l'\ids{UID} della shell di login, l'orario della connessione ed altre +informazioni. La voce resta nel file fino al logout, quando viene cancellata +e spostata in \file{/var/log/wtmp}. In questo modo il primo file viene utilizzato per registrare chi sta utilizzando il sistema al momento corrente, mentre il secondo mantiene la @@ -939,38 +977,39 @@ solo che in questo caso la struttura del registro della \textsl{contabilità} è molto più complessa, dato che contiene diversi tipi di informazione. Le prime tre funzioni, \funcd{setutent}, \funcd{endutent} e \funcd{utmpname} -servono rispettivamente a aprire e a chiudere il file che contiene il -registro, e a specificare su quale file esso viene mantenuto. I loro prototipi -sono: -\begin{functions} - \headdecl{utmp.h} - - \funcdecl{void utmpname(const char *file)} Specifica il file da usare come - registro. - - \funcdecl{void setutent(void)} Apre il file del registro, posizionandosi al - suo inizio. - - \funcdecl{void endutent(void)} Chiude il file del registro. - - \bodydesc{Le funzioni non ritornano codici di errore.} -\end{functions} -e si tenga presente che le funzioni non restituiscono nessun valore, pertanto -non è possibile accorgersi di eventuali errori (ad esempio se si è impostato -un nome di file sbagliato con \func{utmpname}). +servono rispettivamente a aprire e a chiudere il file che contiene il registro +della \textsl{contabilità} degli, e a specificare su quale file esso viene +mantenuto. I loro prototipi sono: + +\begin{funcproto}{ +\fhead{utmp.h} +\fdecl{void utmpname(const char *file)} +\fdesc{Specifica il file da usare come registro.} +\fdecl{void setutent(void)} +\fdesc{Apre il file del registro.} +\fdecl{void endutent(void)} +\fdesc{Chiude il file del registro.} +} + +{Le funzioni non ritornano nulla.} +\end{funcproto} + +Si tenga presente che le funzioni non restituiscono nessun valore, pertanto +non è possibile accorgersi di eventuali errori, ad esempio se si è impostato +un nome di file sbagliato con \func{utmpname}. Nel caso non si sia utilizzata \func{utmpname} per specificare un file di registro alternativo, sia \func{setutent} che \func{endutent} operano usando -il default che è \sysfile{/var/run/utmp}. Il nome di questo file, così come -una serie di altri valori di default per i \textit{pathname} di uso più -comune, viene mantenuto nei valori di una serie di costanti definite -includendo \headfile{paths.h}, in particolare quelle che ci interessano sono: +il default che è \sysfile{/var/run/utmp} il cui nome, così come una serie di +altri valori di default per i \textit{pathname} di uso più comune, viene +mantenuto nei valori di una serie di costanti definite includendo +\headfile{paths.h}, in particolare quelle che ci interessano sono: \begin{basedescript}{\desclabelwidth{2.0cm}} \item[\const{\_PATH\_UTMP}] specifica il file che contiene il registro per gli - utenti correntemente collegati; questo è il valore che viene usato se non si - è utilizzato \func{utmpname} per modificarlo. + utenti correntemente collegati, questo è il valore che viene usato se non si + è utilizzato \func{utmpname} per modificarlo; \item[\const{\_PATH\_WTMP}] specifica il file che contiene il registro per - l'archivio storico degli utenti collegati. + l'archivio storico degli utenti collegati; \end{basedescript} che nel caso di Linux hanno un valore corrispondente ai file \sysfile{/var/run/utmp} e \sysfile{/var/log/wtmp} citati in precedenza. @@ -978,37 +1017,40 @@ che nel caso di Linux hanno un valore corrispondente ai file Una volta aperto il file del registro degli utenti si può eseguire una scansione leggendo o scrivendo una voce con le funzioni \funcd{getutent}, \funcd{getutid}, \funcd{getutline} e \funcd{pututline}, i cui prototipi sono: -\begin{functions} - \headdecl{utmp.h} - \funcdecl{struct utmp *getutent(void)} - Legge una voce dalla posizione corrente nel registro. - - \funcdecl{struct utmp *getutid(struct utmp *ut)} Ricerca una voce sul - registro in base al contenuto di \param{ut}. - \funcdecl{struct utmp *getutline(struct utmp *ut)} - Ricerca nel registro la prima voce corrispondente ad un processo sulla linea - di terminale specificata tramite \param{ut}. +\begin{funcproto}{ +\fhead{utmp.h} +\fdecl{struct utmp *getutent(void)} +\fdesc{Legge una voce dalla posizione corrente nel registro.} +\fdecl{struct utmp *getutid(struct utmp *ut)} +\fdesc{Ricerca una voce sul registro.} +\fdecl{struct utmp *getutline(struct utmp *ut)} +\fdesc{Ricerca una voce sul registro attinente a un terminale.} +\fdecl{struct utmp *pututline(struct utmp *ut)} +\fdesc{Scrive una voce nel registro.} +} - \funcdecl{struct utmp *pututline(struct utmp *ut)} - Scrive una voce nel registro. - - \bodydesc{Le funzioni ritornano il puntatore ad una struttura \struct{utmp} - in caso di successo e \val{NULL} in caso di errore.} -\end{functions} +{Le funzioni ritornano il puntatore ad una struttura \struct{utmp} in caso di + successo e \val{NULL} in caso di errore, nel qual caso \var{errno} assumerà + il valore riportato dalle funzioni sottostanti.} +\end{funcproto} Tutte queste funzioni fanno riferimento ad una struttura di tipo \struct{utmp}, la cui definizione in Linux è riportata in fig.~\ref{fig:sys_utmp_struct}. Le prime tre funzioni servono per leggere una -voce dal registro; \func{getutent} legge semplicemente la prima voce -disponibile; le altre due permettono di eseguire una ricerca. - +voce dal registro: \func{getutent} legge semplicemente la prima voce +disponibile, le altre due permettono di eseguire una ricerca. Aprendo il +registro con \func{setutent} ci si posiziona al suo inizio, ogni chiamata di +queste funzioni eseguirà la lettura sulle voci seguenti, portanto la posizione +sulla voce appena letta, in modo da consentire una scansione del file. Questo +vale anche per \func{getutid} e \func{getutline}, il che comporta che queste +funzioni effettuano comunque una ricerca ``\textsl{in avanti}''. \begin{figure}[!htb] \footnotesize \centering - \begin{minipage}[c]{\textwidth} + \begin{minipage}[c]{0.9\textwidth} \includestruct{listati/utmp.h} \end{minipage} \normalsize @@ -1056,74 +1098,191 @@ corrispondente al valore del campo \var{ut\_id} specificato in \param{ut}. La funzione \func{getutline} esegue la ricerca sulle voci che hanno \var{ut\_type} uguale a \const{LOGIN\_PROCESS} o \const{USER\_PROCESS}, restituendo la prima che corrisponde al valore di \var{ut\_line}, che -specifica il device\footnote{espresso senza il \file{/dev/} iniziale.} di -terminale che interessa. Lo stesso criterio di ricerca è usato da -\func{pututline} per trovare uno spazio dove inserire la voce specificata, -qualora non sia trovata la voce viene aggiunta in coda al registro. +specifica il dispositivo di terminale che interessa, da indicare senza il +\file{/dev/} iniziale. Lo stesso criterio di ricerca è usato da +\func{pututline} per trovare uno spazio dove inserire la voce specificata; +qualora questo spazio non venga trovato la voce viene aggiunta in coda al +registro. In generale occorre però tenere conto che queste funzioni non sono completamente standardizzate, e che in sistemi diversi possono esserci differenze; ad esempio \func{pututline} restituisce \code{void} in vari sistemi (compreso Linux, fino alle \acr{libc5}). Qui seguiremo la sintassi fornita dalle \acr{glibc}, ma gli standard POSIX 1003.1-2001 e XPG4.2 hanno -introdotto delle nuove strutture (e relativi file) di tipo \code{utmpx}, che -sono un sovrainsieme di \code{utmp}. - -Le \acr{glibc} utilizzano già una versione estesa di \code{utmp}, che rende -inutili queste nuove strutture; pertanto esse e le relative funzioni di -gestione (\funcm{getutxent}, \funcm{getutxid}, \funcm{getutxline}, -\funcm{pututxline}, \funcm{setutxent} e \funcm{endutxent}) sono ridefinite come -sinonimi delle funzioni appena viste. - -% TODO (verificare le funzioni di cui sopra ) - -Come visto in sez.~\ref{sec:sys_user_group}, l'uso di strutture allocate -staticamente rende le funzioni di lettura non \index{funzioni!rientranti} -rientranti; per questo motivo le \acr{glibc} forniscono anche delle versioni -\index{funzioni!rientranti} rientranti: \funcm{getutent\_r}, \funcm{getutid\_r}, -\funcm{getutline\_r}, che invece di restituire un puntatore restituiscono un -intero e prendono due argomenti aggiuntivi. Le funzioni si comportano -esattamente come le analoghe non \index{funzioni!rientranti} rientranti, solo -che restituiscono il risultato all'indirizzo specificato dal primo argomento -aggiuntivo (di tipo \code{struct utmp *buffer}) mentre il secondo (di tipo -\code{struct utmp **result)} viene usato per restituire il puntatore allo -stesso buffer. - -Infine le \acr{glibc} forniscono come estensione per la scrittura delle voci -in \file{wmtp} altre due funzioni, \funcd{updwtmp} e \funcd{logwtmp}, i cui -prototipi sono: -\begin{functions} - \headdecl{utmp.h} - - \funcdecl{void updwtmp(const char *wtmp\_file, const struct utmp *ut)} - Aggiunge la voce \param{ut} nel registro \file{wmtp}. - - \funcdecl{void logwtmp(const char *line, const char *name, const char - *host)} Aggiunge nel registro una voce con i valori specificati. -\end{functions} +introdotto delle nuove strutture (e relativi file) di tipo \struct{utmpx}, che +sono un sovrainsieme della \struct{utmp} usata tradizionalmente ed altrettante +funzioni che le usano al posto di quelle citate. + +Le \acr{glibc} utilizzavano già una versione estesa di \struct{utmp}, che +rende inutili queste nuove strutture, per questo su Linux \struct{utmpx} viene +definita esattamente come \struct{utmp}, con gli stessi campi di +fig.~\ref{fig:sys_utmp_struct}. Altrettanto dicasi per le nuove funzioni di +gestione previste dallo standard: \funcm{getutxent}, \funcm{getutxid}, +\funcm{getutxline}, \funcm{pututxline}, \funcm{setutxent} e \funcm{endutxent}. + +Tutte queste funzioni, definite con \struct{utmpx} dal file di dichiarazione +\headfile{utmpx.h}, su Linux sono ridefinite come sinonimi delle funzioni +appena viste, con argomento di tipo \struct{utmpx} anziché \struct{utmp} ed +hanno lo stesso identico comportamento. Per completezza viene definita anche +\funcm{utmpxname} che non è prevista da POSIX.1-2001. + +Come già visto in sez.~\ref{sec:sys_user_group}, l'uso di strutture allocate +staticamente rende le funzioni di lettura dei dati appena illustrate non +\index{funzioni!rientranti} rientranti. Per questo motivo le \acr{glibc} +forniscono anche delle versioni \index{funzioni!rientranti} rientranti: +\func{getutent\_r}, \func{getutid\_r}, \func{getutline\_r}, che invece di +restituire un puntatore restituiscono un intero e prendono due argomenti +aggiuntivi, i rispettivi prototipi sono: -La prima funzione permette l'aggiunta di una voce a \file{wmtp} specificando -direttamente una struttura \struct{utmp}, mentre la seconda utilizza gli -argomenti \param{line}, \param{name} e \param{host} per costruire la voce che -poi aggiunge chiamando \func{updwtmp}. +\begin{funcproto}{ +\fhead{utmp.h} +\fdecl{int *getutent\_r(struct utmp *buffer, struct utmp **result)} +\fdesc{Legge una voce dalla posizione corrente nel registro.} +\fdecl{int *getutid\_r(struct utmp *buffer, struct utmp **result, struct utmp + *ut)} +\fdesc{Ricerca una voce sul registro.} +\fdecl{int *getutline\_r(struct utmp *buffer, struct utmp **result, struct utmp + *ut)} +\fdesc{Ricerca una voce sul registro attinente a un terminale.} +} +{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual + caso \var{errno} assumerà il valore riportato dalle funzioni sottostanti.} +\end{funcproto} +Le funzioni si comportano esattamente come le precedenti analoghe non +\index{funzioni!rientranti} rientranti, solo che restituiscono il risultato +all'indirizzo specificato dal primo argomento aggiuntivo \param{buffer} mentre +il secondo, \param{result)} viene usato per restituire il puntatore al buffer +stesso. -% TODO documentare keyctl ???? -% (fare sezione dedicata ????) -%\subsection{La gestione delle chiavi crittografiche} -%\label{sec:keyctl_management} +Infine le \acr{glibc} forniscono altre due funzioni, \funcd{updwtmp} e +\funcd{logwtmp}, come estensione per scrivere direttamente delle voci nel file +sul registro storico \sysfile{/var/log/wtmp}; i rispettivi prototipi sono: + +\begin{funcproto}{ +\fhead{utmp.h} +\fdecl{void updwtmp(const char *wtmp\_file, const struct utmp *ut)} +\fdesc{Aggiunge una voce in coda al registro.} +\fdecl{void logwtmp(const char *line, const char *name, const char *host)} +\fdesc{Aggiunge nel registro una voce con i valori specificati.} +} + +{Le funzioni non restituiscono nulla.} +\end{funcproto} + +La prima funzione permette l'aggiunta di una voce in coda al file del registro +storico, indicato dal primo argomento, specificando direttamente una struttura +\struct{utmp}. La seconda invece utilizza gli argomenti \param{line}, +\param{name} e \param{host} per costruire la voce che poi aggiunge chiamando +\func{updwtmp}. + +Queste funzioni non sono previste da POSIX.1-2001, anche se sono presenti in +altri sistemi (ad esempio Solaris e NetBSD), per mantenere una coerenza con le +altre funzioni definite nello standard che usano la struttura \struct{utmpx} +la \acr{glibc} definisce anche una funzione \funcm{updwtmpx}, che come in +precedenza è identica a \func{updwtmp} con la sola differenza di richiedere +l'uso di \headfile{utmpx.h} e di una struttura \struct{utmpx} come secondo +argomento. \subsection{La gestione dello spegnimento e del riavvio} \label{sec:sys_reboot} -(da fare) +Una delle operazioni di gestione generale del sistema è quella che attiene +alle modalità con cui se ne può gestire lo spegnimento ed il riavvio. Perché +questo avvenga in maniera corretta, in particolare per le parti che comportano +lo spegnimento effettivo della macchina, occorre che il kernel effettui le +opportune operazioni interagendo con il BIOS ed i dispositivi che controllano +l'erogazione della potenza. + +La funzione di sistema che controlla lo spegnimento ed il riavvio (ed altri +aspetti della relativa procedura) è \funcd{reboot},\footnote{la funzione + illustrata è quella fornita dalla \acr{glibc} che maschera i dettagli di + basso livello della \textit{system call} la quale richiede quattro + argomenti, di cui due \textit{magic number} interi che possono assumere solo + alcuni valori predefiniti, un comando, corrispondente all'unico argomento + della funzione della \acr{glibc} e un puntatore generico ad ulteriori dati.} +il cui prototipo è: + +\begin{funcproto}{ +\fhead{unistd.h} +\fhead{sys/reboot.h} +\fdecl{int reboot(int cmd)} +\fdesc{Controlla il riavvio o l'arresto della macchina.} +} + +{La funzione non ritorna o ritorna $0$ in caso di successo e $-1$ per un + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\errcode{EFAULT}] c'è un indirizzo non valido nel passaggio degli + argomenti con il comando \const{LINUX\_REBOOT\_CMD\_RESTART2}. + \item[\errcode{EINVAL}] si sono specificati valori non validi per gli + argomenti. + \item[\errcode{EPERM}] il chiamante non ha i privilegi di amministratore (la + \textit{capability} \const{CAP\_SYS\_BOOT}). + \end{errlist} +} +\end{funcproto} + +La funzione, oltre al riavvio ed allo spegnimento, consente anche di +controllare l'uso della combinazione di tasti tradizionalmente usata come +scorciatoia da tastiera per richiedere il riavvio (\texttt{Ctrl-Alt-Del}, +denominata in breve nella documentazione CAD) ed i suoi effetti specifici +dipendono dalla architettura hardware. + + + + +Il comportamento della funzione viene controllato dall'argomento \param{cmd} +che deve assumere indicato con una delle costanti seguente elenco, che +illustra i comandi attualmente disponibili: + +\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}} +\item[\const{LINUX\_REBOOT\_CMD\_CAD\_OFF}] Disabilita l'uso diretto della + combinazione \texttt{Ctrl-Alt-Del}, la cui pressione si traduce nell'invio + del segnale \const{SIGINT} a \texttt{init} (o più in generale al processo + con \ids{PID} 1) il cui effetto dipende dalla configurazione di + quest'ultimo. +\item[\const{LINUX\_REBOOT\_CMD\_CAD\_ON}] Attiva l'uso diretto della + combinazione \texttt{Ctrl-Alt-Del}, la cui pressione si traduce + nell'esecuzione dell'azione che si avrebbe avuto chiamando \func{reboot} con + il comando \const{LINUX\_REBOOT\_CMD\_RESTART}. +\item[\const{LINUX\_REBOOT\_CMD\_HALT}] Viene inviato sulla console il + messaggio ``\textit{System halted.}'' l'esecuzione viene bloccata + immediatamente ed il controllo passato al monitor nella ROM (se esiste e + l'architettura lo consente). Se non si è eseguita una sincronizzazione dei + dati su disco con \func{sync} questo saranno perduti. +\item[\const{LINUX\_REBOOT\_CMD\_KEXEC}] +\item[\const{LINUX\_REBOOT\_CMD\_POWER\_OFF}] Viene inviato sulla console il + messaggio ``\textit{Power down.}'' l'esecuzione viene bloccata + immediatamente e la macchina, se possibile, viene spenta. Se non si è + eseguita una sincronizzazione dei dati su disco con \func{sync} questi + saranno perduti. +\item[\const{LINUX\_REBOOT\_CMD\_RESTART}] Viene inviato sulla console il + messaggio ``\textit{Restarting system.}'' ed avviata immediatamente la + procedura di riavvio ordinaria. Se non si è eseguita una sincronizzazione + dei dati su disco con \func{sync} questi saranno perduti. +\item[\const{LINUX\_REBOOT\_CMD\_RESTART2}] Viene inviato sulla console il + messaggio ``\textit{Restarting system with command '\%s'.}'' ed avviata + immediatamente la procedura di riavvio usando il comando fornito + nell'argomento \param{arg} che viene stampato al posto di \textit{'\%s'}. Se + non si è eseguita una sincronizzazione dei dati su disco con \func{sync} + questi saranno perduti. +\end{basedescript} + % TODO trattare reboot, kexec_load, ... + +% TODO documentare keyctl ???? +% (fare sezione dedicata ????) +%\subsection{La gestione delle chiavi crittografiche} +%\label{sec:keyctl_management} + + \section{Il controllo dell'uso delle risorse} \label{sec:sys_res_limits} @@ -2493,6 +2652,7 @@ linea non vengano ripetuti. % LocalWords: perror string errnum MESSAGES error message ErrCode strtol log % LocalWords: program invocation argv printf print progname exit count fname % LocalWords: lineno one standardese Di page Wed Wednesday Apr April PM AM +% LocalWords: CEST @@ -2500,4 +2660,3 @@ linea non vengano ripetuti. %%% mode: latex %%% TeX-master: "gapil" %%% End: -% LocalWords: CEST -- 2.30.2