+La funzione che permette la lettura ed l'impostazione dei parametri del
+sistema è \funcd{sysctl}; è una funzione derivata da BSD4.4, ma
+l'implementazione è specifica di Linux; il suo prototipo è:
+\begin{functions}
+\headdecl{unistd.h}
+\funcdecl{int sysctl(int *name, int nlen, void *oldval, size\_t *oldlenp, void
+ *newval, size\_t newlen)}
+
+Legge o scrive uno dei parametri di sistema.
+
+\bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di
+ errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EPERM}] non si ha il permesso di accedere ad uno dei
+ componenti nel cammino specificato per il parametro, o di accedere al
+ parametro nella modalità scelta.
+ \item[\errcode{ENOTDIR}] non esiste un parametro corrispondente al nome
+ \param{name}.
+% \item[\errcode{EFAULT}] si è specificato \param{oldlenp} zero quando
+% \param{oldval} è non nullo.
+ \item[\errcode{EINVAL}] o si è specificato un valore non valido per il
+ parametro che si vuole impostare o lo spazio provvisto per il ritorno di un
+ valore non è delle giuste dimensioni.
+ \item[\errcode{ENOMEM}] talvolta viene usato più correttamente questo errore
+ quando non si è specificato sufficiente spazio per ricevere il valore di un
+ parametro.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}.
+}
+\end{functions}
+
+I parametri a cui la funzione permettere di accedere sono organizzati in
+maniera gerarchica all'interno di un albero;\footnote{si tenga presente che
+ includendo solo \headfile{unistd.h}, saranno definiti solo i parametri
+ generici; dato che ce ne sono molti specifici dell'implementazione, nel caso
+ di Linux occorrerà includere anche i file \file{linux/unistd.h} e
+ \file{linux/sysctl.h}.} per accedere ad uno di essi occorre specificare un
+cammino attraverso i vari nodi dell'albero, in maniera analoga a come avviene
+per la risoluzione di un \textit{pathname} (da cui l'uso alternativo del
+filesystem \file{/proc}, che vedremo dopo).
+
+Ciascun nodo dell'albero è identificato da un valore intero, ed il cammino che
+arriva ad identificare un parametro specifico è passato alla funzione
+attraverso l'array \param{name}, di lunghezza \param{nlen}, che contiene la
+sequenza dei vari nodi da attraversare. Ogni parametro ha un valore in un
+formato specifico che può essere un intero, una stringa o anche una struttura
+complessa, per questo motivo i valori vengono passati come puntatori
+\ctyp{void}.
+
+L'indirizzo a cui il valore corrente del parametro deve essere letto è
+specificato da \param{oldvalue}, e lo spazio ivi disponibile è specificato da
+\param{oldlenp} (passato come puntatore per avere indietro la dimensione
+effettiva di quanto letto); il valore che si vuole impostare nel sistema è
+passato in \param{newval} e la sua dimensione in \param{newlen}.
+
+Si può effettuare anche una lettura e scrittura simultanea, nel qual caso il
+valore letto restituito dalla funzione è quello precedente alla scrittura.
+
+I parametri accessibili attraverso questa funzione sono moltissimi, e possono
+essere trovati in \headfile{sysctl.h}, essi inoltre dipendono anche dallo
+stato corrente del kernel (ad esempio dai moduli che sono stati caricati nel
+sistema) e in genere i loro nomi possono variare da una versione di kernel
+all'altra; per questo è sempre il caso di evitare l'uso di \func{sysctl}
+quando esistono modalità alternative per ottenere le stesse informazioni.
+Alcuni esempi di parametri ottenibili sono:
+\begin{itemize}
+\item il nome di dominio
+\item i parametri del meccanismo di \textit{paging}.
+\item il filesystem montato come radice
+\item la data di compilazione del kernel
+\item i parametri dello stack TCP
+\item il numero massimo di file aperti
+\end{itemize}
+
+Come accennato in Linux si ha una modalità alternativa per accedere alle
+stesse informazioni di \func{sysctl} attraverso l'uso del 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 alcune delle strutture interne del kernel stesso.
+
+In particolare l'albero dei valori di \func{sysctl} viene presentato in forma
+di file nella directory \file{/proc/sys}, cosicché è possibile accedervi
+specificando un \textit{pathname} e leggendo e scrivendo sul file
+corrispondente al parametro scelto. Il kernel si occupa di generare al volo
+il contenuto ed i nomi dei file corrispondenti, e questo ha il grande
+vantaggio di rendere accessibili i vari parametri a qualunque comando di shell
+e di permettere la navigazione dell'albero dei valori.
+
+Alcune delle corrispondenze dei file presenti in \file{/proc/sys} con i valori
+di \func{sysctl} sono riportate nei commenti del codice che può essere trovato
+in \file{linux/sysctl.h},\footnote{indicando un file di definizioni si fa
+ riferimento alla directory standard dei file di include, che in ogni
+ distribuzione che si rispetti è \file{/usr/include}.} la informazione
+disponibile in \file{/proc/sys} è riportata inoltre nella documentazione
+inclusa nei sorgenti del kernel, nella directory \file{Documentation/sysctl}.
+
+Ma oltre alle informazioni ottenibili da \func{sysctl} dentro \file{proc} sono
+disponibili moltissime altre informazioni, fra cui ad esempio anche quelle
+fornite da \func{uname} (vedi sez.~\ref{sec:sys_uname}) che sono mantenute nei
+file \sysctlrelfile{kernel}{ostype}, \sysctlrelfile{kernel}{hostname},
+\sysctlrelfile{kernel}{osrelease}, \sysctlrelfile{kernel}{version} e
+\sysctlrelfile{kernel}{domainname} di \file{/proc/sys/kernel/}.
+
+
+
+% TODO documentare keyctl ????
+% (fare sezione dedicata ????)
+%\subsection{La gestione delle chiavi crittografiche}
+%\label{sec:keyctl_management}
+
+%
+% \subsection{La gestione dello spegnimento e del riavvio}
+%\label{sec:sys_reboot}
+% TODO trattare reboot, kexec_load, ...
+
+
+\subsection{La gestione delle informazioni su utenti e gruppi}
+\label{sec:sys_user_group}
+
+Tradizionalmente le informazioni utilizzate nella gestione di utenti e gruppi
+(password, corrispondenze fra nomi simbolici e user-id, 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
+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
+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.
+
+In questo paragrafo ci limiteremo comunque a trattare le funzioni classiche
+per la lettura delle informazioni relative a utenti e gruppi tralasciando
+completamente quelle relative all'autenticazione.
+% Per questo non tratteremo
+% affatto l'interfaccia di PAM, ma approfondiremo invece il sistema del
+% \textit{Name Service Switch}, un meccanismo messo a disposizione dalle
+% \acr{glibc} per modularizzare l'accesso a tutti i servizi in cui sia
+% necessario trovare una corrispondenza fra un nome ed un numero (od altra
+% informazione) ad esso associato, come appunto, quella fra uno username ed un
+% \ids{UID} o fra un \ids{GID} ed il nome del gruppo corrispondente.
+Le prime funzioni che vedremo sono quelle previste dallo standard POSIX.1;
+queste sono del tutto generiche e si appoggiano direttamente al \textit{Name
+ Service Switch}, per cui sono in grado di ricevere informazioni qualunque
+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}
+
+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.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/passwd.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{passwd} contenente le informazioni relative ad
+ un utente del sistema.}
+ \label{fig:sys_passwd_struct}
+\end{figure}
+
+La struttura usata da entrambe le funzioni è allocata staticamente, per questo
+motivo viene sovrascritta ad ogni nuova invocazione, lo stesso dicasi per la
+memoria dove sono scritte le stringhe a cui i puntatori in essa contenuti
+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,
+ char *buffer, size\_t buflen, struct passwd **result)}
+
+ \funcdecl{struct passwd *getpwnam\_r(const char *name, struct passwd
+ *password, char *buffer, size\_t buflen, struct passwd **result)}
+
+ 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}
+
+In questo caso l'uso è molto più complesso, in quanto bisogna prima allocare
+la memoria necessaria a contenere le informazioni. In particolare i valori
+della struttura \struct{passwd} saranno restituiti all'indirizzo
+\param{password} mentre la memoria allocata all'indirizzo \param{buffer}, per
+un massimo di \param{buflen} byte, sarà utilizzata per contenere le stringhe
+puntate dai campi di \param{password}. Infine all'indirizzo puntato da
+\param{result} viene restituito il puntatore ai dati ottenuti, cioè
+\param{buffer} nel caso l'utente esista, o \val{NULL} altrimenti. Qualora i
+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}).
+
+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}
+
+ \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)}
+
+ 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
+in questo caso le informazioni vengono restituite in una struttura di tipo
+\struct{group}, la cui definizione è riportata in
+fig.~\ref{fig:sys_group_struct}.
+
+\begin{figure}[!htb]
+ \footnotesize
+ \centering
+ \begin{minipage}[c]{\textwidth}
+ \includestruct{listati/group.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{group} contenente le informazioni relative ad
+ un gruppo del sistema.}
+ \label{fig:sys_group_struct}
+\end{figure}
+
+Le funzioni viste finora sono in grado di leggere le informazioni sia
+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}.