From: Simone Piccardi Date: Sun, 19 Mar 2006 23:29:58 +0000 (+0000) Subject: Finita la parte sulle capabilities. X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=bf41def586b4bf552660e34913f3c39b7d26b7bc;p=gapil.git Finita la parte sulle capabilities. --- diff --git a/listati/getcap.c b/listati/getcap.c new file mode 100644 index 0000000..fc2fd3c --- /dev/null +++ b/listati/getcap.c @@ -0,0 +1,21 @@ + if (!pid) { + capab = cap_get_proc(); + if (capab == NULL) { + perror("cannot get current process capabilities"); + return 1; + } + } else { + capab = cap_init(); + res = capgetp(pid, capab); + if (res) { + perror("cannot get process capabilities"); + return 1; + } + } + + string = cap_to_text(capab, NULL); + printf("Capability: %s\n", string); + + cap_free(capab); + cap_free(string); + return 0; diff --git a/prochand.tex b/prochand.tex index cb43183..099b1ff 100644 --- a/prochand.tex +++ b/prochand.tex @@ -152,7 +152,7 @@ interrupt,\footnote{pi comunque a che esso sia invocato periodicamente, generando un interrupt periodico secondo la frequenza specificata dalla costante \const{HZ}, definita in \file{asm/param.h}, ed il cui valore è espresso in Hertz.\footnote{Fino al - kernel 2.4 l valore usuale di questa costante era 100, per tutte le + kernel 2.4 il valore usuale di questa costante era 100, per tutte le architetture eccetto l'alpha, per la quale era 1000. Occorre fare attenzione a non confondere questo valore con quello dei clock tick (vedi sez.~\ref{sec:sys_unix_time}).} @@ -327,14 +327,14 @@ condivisa, pertanto padre e figlio vedono variabili diverse. Per quanto riguarda la gestione della memoria, in generale il\index{segmento!testo} segmento di testo, che è identico per i due processi, è condiviso e tenuto in read-only per il padre e per i figli. Per gli altri -segmenti Linux utilizza la tecnica del \textit{copy on - write}\itindex{copy~on~write}; questa tecnica comporta che una pagina di -memoria viene effettivamente copiata per il nuovo processo solo quando ci -viene effettuata sopra una scrittura (e si ha quindi una reale differenza fra -padre e figlio). In questo modo si rende molto più efficiente il meccanismo -della creazione di un nuovo processo, non essendo più necessaria la copia di -tutto lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di -memoria che sono state modificate, e solo al momento della modifica stessa. +segmenti Linux utilizza la tecnica del \textit{copy on write} +\itindex{copy~on~write}; questa tecnica comporta che una pagina di memoria +viene effettivamente copiata per il nuovo processo solo quando ci viene +effettuata sopra una scrittura (e si ha quindi una reale differenza fra padre +e figlio). In questo modo si rende molto più efficiente il meccanismo della +creazione di un nuovo processo, non essendo più necessaria la copia di tutto +lo spazio degli indirizzi virtuali del padre, ma solo delle pagine di memoria +che sono state modificate, e solo al momento della modifica stessa. La differenza che si ha nei due processi è che nel processo padre il valore di ritorno della funzione \func{fork} è il \acr{pid} del processo figlio, mentre @@ -454,19 +454,19 @@ ciclo successivo), mentre la terza volta (fino alla conclusione) e poi il padre. In generale l'ordine di esecuzione dipenderà, oltre che dall'algoritmo di -scheduling usato dal kernel, dalla particolare situazione in cui si trova la -macchina al momento della chiamata, risultando del tutto impredicibile. -Eseguendo più volte il programma di prova e producendo un numero diverso di -figli, si sono ottenute situazioni completamente diverse, compreso il caso in -cui il processo padre ha eseguito più di una \func{fork} prima che uno dei -figli venisse messo in esecuzione. +\itindex{scheduler} scheduling usato dal kernel, dalla particolare situazione +in cui si trova la macchina al momento della chiamata, risultando del tutto +impredicibile. Eseguendo più volte il programma di prova e producendo un +numero diverso di figli, si sono ottenute situazioni completamente diverse, +compreso il caso in cui il processo padre ha eseguito più di una \func{fork} +prima che uno dei figli venisse messo in esecuzione. Pertanto non si può fare nessuna assunzione sulla sequenza di esecuzione delle istruzioni del codice fra padre e figli, né sull'ordine in cui questi potranno essere messi in esecuzione. Se è necessaria una qualche forma di precedenza occorrerà provvedere ad espliciti meccanismi di sincronizzazione, pena il -rischio di incorrere nelle cosiddette \textit{race - condition}\itindex{race~condition} (vedi sez.~\ref{sec:proc_race_cond}). +rischio di incorrere nelle cosiddette \textit{race condition} +\itindex{race~condition} (vedi sez.~\ref{sec:proc_race_cond}). Si noti inoltre che essendo i segmenti di memoria utilizzati dai singoli processi completamente separati, le modifiche delle variabili nei processi @@ -639,7 +639,7 @@ padre, che costituiva un inutile appesantimento in tutti quei casi in cui la \func{fork} veniva fatta solo per poi eseguire una \func{exec}. La funzione venne introdotta in BSD per migliorare le prestazioni. -Dato che Linux supporta il \textit{copy on write}\itindex{copy~on~write} la +Dato che Linux supporta il \textit{copy on write} \itindex{copy~on~write} la perdita di prestazioni è assolutamente trascurabile, e l'uso di questa funzione (che resta un caso speciale della system call \func{\_\_clone}) è deprecato; per questo eviteremo di trattarla ulteriormente. @@ -788,19 +788,19 @@ terminale (prima dello scadere dei 10 secondi) otterremo: \end{verbatim} %$ \normalsize e come si vede, dato che non si è fatto nulla per riceverne lo stato di terminazione, i tre processi figli sono ancora presenti pur essendosi -conclusi, con lo stato di zombie\index{zombie} e l'indicazione che sono stati +conclusi, con lo stato di zombie \index{zombie} e l'indicazione che sono stati terminati. -La possibilità di avere degli zombie\index{zombie} deve essere tenuta sempre +La possibilità di avere degli zombie \index{zombie} deve essere tenuta sempre presente quando si scrive un programma che deve essere mantenuto in esecuzione a lungo e creare molti figli. In questo caso si deve sempre avere cura di far leggere l'eventuale stato di uscita di tutti i figli (in genere questo si fa attraverso un apposito \textit{signal handler}, che chiama la funzione \func{wait}, vedi sez.~\ref{sec:sig_sigchld} e sez.~\ref{sec:proc_wait}). -Questa operazione è necessaria perché anche se gli -\textit{zombie}\index{zombie} non consumano risorse di memoria o processore, -occupano comunque una voce nella tabella dei processi, che a lungo andare -potrebbe esaurirsi. +Questa operazione è necessaria perché anche se gli \textit{zombie} +\index{zombie} non consumano risorse di memoria o processore, occupano +comunque una voce nella tabella dei processi, che a lungo andare potrebbe +esaurirsi. Si noti che quando un processo adottato da \cmd{init} termina, esso non diviene uno \textit{zombie}\index{zombie}; questo perché una delle funzioni di @@ -818,7 +818,7 @@ processo che li ha generati, in modo che \cmd{init} possa adottarli e provvedere a concluderne la terminazione. -\subsection{Le funzioni \func{wait} e \func{waitpid}} +\subsection{Le funzioni \func{wait} e \func{waitpid}} \label{sec:proc_wait} Uno degli usi più comuni delle capacità multitasking di un sistema unix-like @@ -1278,12 +1278,12 @@ forma \cmd{\#!/path/to/interpreter [argomenti]} dove l'interprete indicato deve essere un programma valido (binario, non un altro script) che verrà chiamato come se si fosse eseguito il comando \cmd{interpreter [argomenti] filename}.\footnote{si tenga presente che con Linux quanto viene scritto - come \texttt{argomenti} viene passato all'inteprete come un unico argomento + come \texttt{argomenti} viene passato all'interprete come un unico argomento con una unica stringa di lunghezza massima di 127 caratteri e se questa dimensione viene ecceduta la stringa viene troncata; altri Unix hanno dimensioni massime diverse, e diversi comportamenti, ad esempio FreeBSD esegue la scansione della riga e la divide nei vari argomenti e se è troppo - lunga restitituisce un errore di \const{ENAMETOOLONG}, una comparazione dei + lunga restituisce un errore di \const{ENAMETOOLONG}, una comparazione dei vari comportamenti si trova su \href{http://www.in-ulm.de/~mascheck/various/shebang/} {\texttt{http://www.in-ulm.de/\tild mascheck/various/shebang/}}.} @@ -1575,10 +1575,9 @@ l'\textsl{user-ID effettivo} del processo per cedere i privilegi occorre ricorrere ad altre funzioni. Le due funzioni \funcd{setreuid} e \funcd{setregid} derivano da BSD che, non -supportando\footnote{almeno fino alla versione 4.3+BSD TODO, FIXME verificare - e aggiornare la nota.} gli identificatori del gruppo \textit{saved}, le usa -per poter scambiare fra di loro \textit{effective} e \textit{real}. I -rispettivi prototipi sono: +supportando\footnote{almeno fino alla versione 4.3+BSD.} gli identificatori +del gruppo \textit{saved}, le usa per poter scambiare fra di loro +\textit{effective} e \textit{real}. I rispettivi prototipi sono: \begin{functions} \headdecl{unistd.h} \headdecl{sys/types.h} @@ -1924,6 +1923,9 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.13, e \textbf{Capacità}&\textbf{Descrizione}\\ \hline \hline +% +% POSIX-draft defined capabilities. +% \const{CAP\_CHOWN} & la capacità di cambiare proprietario e gruppo proprietario di un file (vedi sez.~\ref{sec:file_chown}).\\ @@ -1967,53 +1969,14 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.13, e di impostare il bit \acr{sgid} su un file anche quando questo è relativo ad un gruppo cui non si appartiene (vedi sez.~\ref{sec:file_chmod}).\\ - \const{CAP\_IPC\_LOCK} & la capacità di effettuare il \textit{memory - locking} \itindex{memory~locking} con le - funzioni \func{mlock}, \func{mlockall}, - \func{shmctl}, \func{mmap} (vedi - sez.~\ref{sec:proc_mem_lock} e - sez.~\ref{sec:file_memory_map}). \\ - \const{CAP\_IPC\_OWNER} & la capacità di evitare il controllo dei permessi - per le operazioni sugli oggetti di - intercomunicazione fra processi (vedi - sez.~\ref{sec:ipc_sysv}).\\ \const{CAP\_KILL} & la capacità di mandare segnali a qualunque processo (vedi sez.~\ref{sec:sig_kill_raise}).\\ - \const{CAP\_LEASE} & la capacità di creare dei \textit{file lease} - \index{file!lease} su di un file (vedi - sez.~\ref{sec:file_asyncronous_lease}) - indipendentemente dalla proprietà dello - stesso.\footnotemark\\ - \const{CAP\_LINUX\_IMMUTABLE}& la capacità di impostare gli attributi - \textit{immutable} e \textit{append only} per i - file su un filesystem che supporta questi - attributi estesi.\\ - \const{CAP\_MKNOD} & la capacità di creare file di dispositivo con la - funzione \func{mknod} (vedi - sez.~\ref{sec:file_mknod}).\footnotemark\\ - \const{CAP\_NET\_ADMIN} & la capacità di eseguire alcune operazioni - privilegiate sulla rete (impostare le opzioni - privilegiate dei socket, abilitare il - multicasting, impostare interfacce di rete e - tabella di instradamento).\\ - \const{CAP\_NET\_BIND\_SERVICE}& la capacità di porre in ascolto server - su porte riservate (vedi - sez.~\ref{sec:TCP_func_bind}).\\ - \const{CAP\_NET\_BROADCAST}& la capacità di consentire l'uso di socket in - broadcast e multicast.\\ - \const{CAP\_NET\_RAW} & la capacità di usare socket \texttt{RAW} e - \texttt{PACKET} (quelli che permettono di creare - pacchetti nei protocolli di basso livello).\\ \const{CAP\_SETGID} & la capacità di manipolare i group ID dei processi, sia il principale che i supplementari, (vedi sez.~\ref{sec:proc_setgroups} che quelli trasmessi tramite i \index{socket} socket \textit{unix domain} (vedi sez.~\ref{sec:unix_socket}).\\ - \const{CAP\_SETPCAP} & la capacità di impostare o rimuovere una capacità - (limitatamente a quelle che il processo - chiamante ha nel suo insieme di capacità - permesse) da qualunque processo.\\ \const{CAP\_SETUID} & la capacità di manipolare gli user ID del processo (con \func{setuid}, \func{setreuid}, \func{setresuid}, \func{setfsuid}) e di @@ -2021,25 +1984,64 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.13, e dell'\textsl{uid} nel passaggio delle credenziali coi socket unix domain (vedi sez.~\ref{sec:unix_socket_xxx}).\\ +% +% Linux specific capabilities +% +\hline + \const{CAP\_SETPCAP} & la capacità di impostare o rimuovere una capacità + (limitatamente a quelle che il processo + chiamante ha nel suo insieme di capacità + permesse) da qualunque processo.\\ + \const{CAP\_LINUX\_IMMUTABLE}& la capacità di impostare gli attributi + \textit{immutable} e \textit{append only} per i + file su un filesystem che supporta questi + attributi estesi.\\ + \const{CAP\_NET\_BIND\_SERVICE}& la capacità di porre in ascolto server + su porte riservate (vedi + sez.~\ref{sec:TCP_func_bind}).\\ + \const{CAP\_NET\_BROADCAST}& la capacità di consentire l'uso di socket in + broadcast e multicast.\\ + \const{CAP\_NET\_ADMIN} & la capacità di eseguire alcune operazioni + privilegiate sulla rete (impostare le opzioni + privilegiate dei socket, abilitare il + multicasting, impostare interfacce di rete e + tabella di instradamento).\\ + \const{CAP\_NET\_RAW} & la capacità di usare socket \texttt{RAW} e + \texttt{PACKET} (quelli che permettono di creare + pacchetti nei protocolli di basso livello).\\ + \const{CAP\_IPC\_LOCK} & la capacità di effettuare il \textit{memory + locking} \itindex{memory~locking} con le + funzioni \func{mlock}, \func{mlockall}, + \func{shmctl}, \func{mmap} (vedi + sez.~\ref{sec:proc_mem_lock} e + sez.~\ref{sec:file_memory_map}). \\ + \const{CAP\_IPC\_OWNER} & la capacità di evitare il controllo dei permessi + per le operazioni sugli oggetti di + intercomunicazione fra processi (vedi + sez.~\ref{sec:ipc_sysv}).\\ + \const{CAP\_SYS\_MODULE}& la capacità di caricare e rimuovere moduli del + kernel. \\ + \const{CAP\_SYS\_RAWIO} & la capacità di eseguire operazioni sulle porte + di I/O con \func{ioperm} e \func{iopl} (vedi + sez.~\ref{sec:file_io_port}).\\ + \const{CAP\_SYS\_CHROOT}& la capacità di eseguire la funzione + \func{chroot} (vedi + sez.~\ref{sec:file_chroot}).\\ + \const{CAP\_SYS\_PTRACE}& consente di tracciare qualunque processo con + \func{ptrace} (vedi + sez.~\ref{sec:xxx_ptrace}).\\ +% TODO documentatare ptrace + \const{CAP\_SYS\_PACCT} & la capacità di usare le funzioni di + \textit{accounting} dei processi (vedi + sez.~\ref{sec:sys_bsd_accounting}).\\ \const{CAP\_SYS\_ADMIN} & la capacità di eseguire una serie di compiti amministrativi (come impostare le quote, attivare e disattivare la swap, montare, rimontare e smontare filesystem, ecc.). \\ - \const{CAP\_SYS\_BOOT} & la capacità di fare eseguire un reboot del + \const{CAP\_SYS\_BOOT} & la capacità di fare eseguire un riavvio del sistema.\\ - \const{CAP\_SYS\_CHROOT}& la capacità di eseguire la funzione - \func{chroot} (vedi - sez.~\ref{sec:file_chroot}).\\ - \const{CAP\_SYS\_MODULE}& la capacità di caricare e rimuovere moduli del - kernel. \\ \const{CAP\_SYS\_NICE} & la capacità di modificare le priorità dei processi (vedi sez.~\ref{sec:proc_priority}). \\ - \const{CAP\_SYS\_PACCT} & la capacità di usare le funzioni di - \textit{accounting} dei processi (vedi - sez.~\ref{sec:sys_bsd_accounting}).\\ - \const{CAP\_SYS\_RAWIO} & la capacità di eseguire operazioni sulle porte - di I/O con \func{ioperm} e \func{iopl} (vedi - sez.~\ref{sec:file_io_port}).\\ \const{CAP\_SYS\_RESOURCE}& la capacità di superare le limitazioni sulle risorse, aumentare le quote disco, usare lo spazio disco riservato all'amministratore.\\ @@ -2048,10 +2050,17 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.13, e \const{CAP\_SYS\_TTY\_CONFIG}& la capacità di simulare un \textit{hangup} della console, con la funzione \func{vhangup}.\\ - \const{CAP\_SYS\_PTRACE}& consente di tracciare qualunque processo con - \func{ptrace} (vedi - sez.~\ref{sec:xxx_ptrace}).\\ -% TODO documentatare ptrace + \const{CAP\_MKNOD} & la capacità di creare file di dispositivo con la + funzione \func{mknod} (vedi + sez.~\ref{sec:file_mknod}).\footnotemark\\ + \const{CAP\_LEASE} & la capacità di creare dei \textit{file lease} + \index{file!lease} su di un file (vedi + sez.~\ref{sec:file_asyncronous_lease}) + indipendentemente dalla proprietà dello + stesso.\footnotemark\\ + \const{CAP\_SETFCAP} & la capacità di impostare le + \textit{capabilities} di un file (non + supportata).\\ \hline \end{tabular} \caption{Le costanti che identificano le \textit{capabilities} presenti nel @@ -2059,10 +2068,10 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.13, e \label{tab:proc_capabilities} \end{table} -\footnotetext[21]{questa capacità è presente soltato a partire dai kernel +\footnotetext[21]{questa capacità è presente soltanto a partire dai kernel della serie 2.4.x.} -\footnotetext{questa capacità è presente soltato a partire dai kernel della +\footnotetext{questa capacità è presente soltanto a partire dai kernel della serie 2.4.x.} Per gestire questo nuovo meccanismo ciascun processo porta con sé tre distinti @@ -2078,9 +2087,12 @@ vengono mantenuti in forma di tre diverse maschere binarie,\footnote{il kernel ciascun bit corrisponde ad una capacità diversa; se ne è riportato l'elenco,\footnote{si tenga presente che l'elenco delle \textit{capabilities} presentato questa tabella, ripreso dalla relativa pagina di manuale - (accessibile con \texttt{man capabilities}), è quello aggiornato al kernel - 2.6.6.} con una breve descrizione, ed il nome delle costanti che -identificano i singoli bit, in tab.~\ref{tab:proc_capabilities}. + (accessibile con \texttt{man capabilities}) e dalle definizioni in + \texttt{sys/capabilities.h}, è quello aggiornato al kernel 2.6.6.} con una +breve descrizione, ed il nome delle costanti che identificano i singoli bit, +in tab.~\ref{tab:proc_capabilities}; la tabella è divisa in due parti, la +prima riporta le \textit{capabilities} previste nella bozza dello standard +POSIX1.e, la seconda quelle specifiche di Linux. L'utilizzo di tre distinti insiemi serve a fornire una interfaccia flessibile per l'uso delle \textit{capabilities}, con scopi analoghi a quelli per cui @@ -2181,7 +2193,7 @@ fig.~\ref{fig:cap_kernel_struct}, come i prototipi delle due funzioni \func{capget} e \func{capset}, sono soggette ad essere modificate con il cambiamento del kernel (in particolare i tipi di dati delle strutture) ed anche se finora l'interfaccia è risultata stabile, non c'è nessuna -assicurazione che questa venga mantenuta. Pertando se si vogliono scrivere +assicurazione che questa venga mantenuta. Pertanto se si vogliono scrivere programmi portabili che possano essere eseguiti su qualunque versione del kernel è opportuno utilizzare le interfacce di alto livello. @@ -2248,7 +2260,7 @@ relativi dati. La funzione La funzione restituisce il puntatore \type{cap\_t} ad uno stato inizializzato con tutte le \textit{capabilities} azzerate. In caso di errore (cioè quando -non c'è memoria suffuciente ad allocare i dati) viene restituito \macro{NULL} +non c'è memoria sufficiente ad allocare i dati) viene restituito \macro{NULL} ed \var{errno} viene impostata a \errval{ENOMEM}. La memoria necessaria a mantenere i dati viene automaticamente allocata da \func{cap\_init}, ma dovrà essere disallocata esplicitamente quando non più necessaria utilizzando la @@ -2426,7 +2438,8 @@ La funzione ritorna l'indirizzo di una stringa contente la descrizione testuale del contenuto del \textit{capabilities state} \param{caps} passato come argomento, e, qualora l'argomento \param{length\_p} sia diverso da \val{NULL}, restituisce nella variabile intera da questo puntata la lunghezza -della stringa. +della stringa. La stringa restituita viene allocata automaticamente dalla +funzione e deve essere liberata con \func{cap\_free}. Fin quei abbiamo trattato delle funzioni di manipolazione dei \textit{capabilities state}; quando si vuole eseguire la lettura delle @@ -2469,7 +2482,16 @@ prototipo\footnote{su alcune pagine di manuale la funzione La funzione legge il valore delle \textit{capabilities} del processo indicato con l'argomento \param{pid}, salvando il risultato nel \textit{capabilities state} all'indirizzo \param{cap\_d} che deve essere stato creato in -precedenza. Qualora il processo non esista si avrà un errore di \errval{ESRCH}. +precedenza. Qualora il processo non esista si avrà un errore di +\errval{ESRCH}. Gli stessi valori possono essere letti direttamente nel +filesystem \textit{proc}, nei file \texttt{/proc//status}; ad esempio per +\texttt{init} si otterrà qualcosa del tipo: +\begin{Verbatim} +... +CapInh: 0000000000000000 +CapPrm: 00000000fffffeff +CapEff: 00000000fffffeff +\end{Verbatim} Infine per impostare le \textit{capabilities} del processo corrente (non esiste una funzione che permetta di cambiare le \textit{capabilities} di un @@ -2487,7 +2509,51 @@ prototipo } \end{functions} +La funzione modifica le \textit{capabilities} del processo corrente secondo +quanto specificato con l'argomento \param{cap\_p}, posto che questo sia +possibile nei termini spiegati in precedenza (non sarà ad esempio possibile +impostare capacità non presenti nell'insieme di quelle permesse). In caso di +successo i nuovi valori saranno effettivi al ritorno della funzione, in caso +di fallimento invece lo stato delle capacità resterà invariato. Si tenga +presente che \textsl{tutte} le capacità specificate tramite \param{cap\_p} +devono essere permesse; se anche una sola non lo è la funzione fallirà, e per +quanto appena detto, lo stato delle \textit{capabilities} non verrà modificato +(neanche per le parti eventualmente permesse). + +Come esempio di utilizzo di queste funzioni nei sorgenti allegati alla guida +si è distribuito il programma \texttt{getcap.c}, che consente di leggere le +\textit{capabilities} del processo corrente\footnote{vale a dire di sé stesso, + quando lo si lancia, il che può sembrare inutile, ma serve a mostrarci quali + sono le \textit{capabilities} standard che ottiene un processo lanciato + dalla riga di comando.} o tramite l'opzione \texttt{-p}, quelle di un +processo qualunque il cui pid viene passato come parametro dell'opzione. + +\begin{figure}[htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \includecodesample{listati/getcap.c} + \end{minipage} + \normalsize + \caption{Corpo principale del programma \texttt{getcap.c}.} + \label{fig:proc_getcap} +\end{figure} +La sezione principale del programma è riportata in fig.~\ref{fig:proc_getcap}, +e si basa su una condizione sulla variabile \var{pid} che se si è usato +l'opzione \texttt{-p} è impostata (nella sezione di gestione delle opzioni, +che si è tralasciata) al valore del \textsl{pid} del processo di cui si vuole +leggere le \textit{capabilities} e nulla altrimenti. Nel primo caso +(\texttt{\small 1--6}) si utilizza direttamente (\texttt{\small 2}) +\func{cap\_get\_proc} per ottenere lo stato delle capacità del processo, nel +secondo (\texttt{\small 7--14}) prima si inizializza (\texttt{\small 8}) uno +stato vuoto e poi (\texttt{\small 9}) si legge il valore delle capacità del +processo indicato. + +Il passo successivo è utilizzare (\texttt{\small 16}) \func{cap\_to\_text} per +tradurre in una stringa lo stato, e poi (\texttt{\small 17}) stamparlo; infine +(\texttt{\small 19--20}) si libera la memoria allocata dalle precedenti +funzioni con \func{cap\_free} per poi ritornare dal ciclo principale della +funzione. \itindend{capabilities} @@ -3100,7 +3166,7 @@ su quali processori far eseguire un determinato processo attraverso una \texttt{len} è stato eliminato, successivamente si è introdotta la versione riportata con però un secondo argomento di tipo \texttt{size\_t cpusetsize} (anche questa citata nella pagina di manuale); la versione citata è quella - riportata nel manuale delle \textsl{glibc} e corripondente alla definizione + riportata nel manuale delle \textsl{glibc} e corrispondente alla definizione presente in \file{sched.h}.} è: \begin{prototype}{sched.h} {int sched\_setaffinity (pid\_t pid, const cpu\_set\_t *cpuset)} @@ -3152,7 +3218,7 @@ di processore. Per facilitare l'uso dell'argomento \param{cpuset} le \acr{glibc} hanno introdotto un apposito dato di tipo, \ctyp{cpu\_set\_t},\footnote{questa è una estensione specifica delle \acr{glibc}, da attivare definendo la macro - \macro{\_GNU\_SOURCE}, non esiste infatti una standardardizzazione per + \macro{\_GNU\_SOURCE}, non esiste infatti una standardizzazione per questo tipo di interfaccia e POSIX al momento non prevede nulla al riguardo.} che permette di identificare un insieme di processori. Il dato è una maschera binaria: in generale è un intero a 32 bit in cui ogni bit @@ -3207,7 +3273,7 @@ valore per un processo specifico usando la funzione La funzione restituirà all'indirizzo specificato da \param{cpuset} il valore della maschera di affinità del processo, così da poterla riutilizzare per una successiva reimpostazione. In questo caso non sono necessari privilegi -paricolari. +particolari. È chiaro che queste funzioni per la gestione dell'affinità hanno significato soltanto su un sistema multiprocessore, esse possono comunque essere @@ -3378,3 +3444,40 @@ varie funzioni di libreria, che sono identificate aggiungendo il suffisso %%% mode: latex %%% TeX-master: "gapil" %%% End: + +% LocalWords: multitasking like VMS child process identifier pid sez shell fig +% LocalWords: parent kernel init pstree keventd kswapd table struct linux call +% LocalWords: nell'header scheduler system interrupt timer HZ asm Hertz clock +% LocalWords: l'alpha tick fork wait waitpid exit exec image glibc int pgid ps +% LocalWords: sid threads thread Ingo Molnar ppid getpid getppid sys unistd +% LocalWords: void ForkTest tempnam pathname sibling cap errno EAGAIN ENOMEM +% LocalWords: stack read only copy write tab client spawn forktest sleep PATH +% LocalWords: source LIBRARY scheduling race condition printf descriptor dup +% LocalWords: close group session tms lock vfork execve BSD stream main abort +% LocalWords: SIGABRT SIGCHLD SIGHUP foreground SIGCONT termination signal ANY +% LocalWords: handler kill EINTR POSIX options WNOHANG ECHILD option WUNTRACED +% LocalWords: dump bits rusage getrusage heap const filename argv envp EACCES +% LocalWords: filesystem noexec EPERM suid sgid root nosuid ENOEXEC ENOENT ELF +% LocalWords: ETXTBSY EINVAL ELIBBAD BIG EFAULT EIO ENAMETOOLONG ELOOP ENOTDIR +% LocalWords: ENFILE EMFILE argc execl path execv execle execlp execvp vector +% LocalWords: list environ NULL umask pending utime cutime ustime fcntl linker +% LocalWords: opendir libc interpreter FreeBSD capabilities Mandatory Access +% LocalWords: Control MAC SELinux Security Modules LSM superuser uid gid saved +% LocalWords: effective euid egid dell' fsuid fsgid getuid geteuid getgid SVr +% LocalWords: getegid IDS NFS setuid setgid all' logout utmp screen xterm TODO +% LocalWords: setreuid setregid FIXME ruid rgid seteuid setegid setresuid size +% LocalWords: setresgid getresuid getresgid value result argument setfsuid DAC +% LocalWords: setfsgid NGROUPS sysconf getgroups getgrouplist groups ngroups +% LocalWords: setgroups initgroups patch LIDS CHOWN OVERRIDE Discrectionary +% LocalWords: SEARCH chattr sticky NOATIME socket domain immutable append mmap +% LocalWords: broadcast multicast multicasting memory locking mlock mlockall +% LocalWords: shmctl ioperm iopl chroot ptrace accounting swap reboot hangup +% LocalWords: vhangup mknod lease permitted inherited inheritable bounding AND +% LocalWords: capability capget capset header ESRCH undef version obj clear +% LocalWords: pag ssize length proc capgetp prehemptive cache runnable Stopped +% LocalWords: Uninterrutible SIGSTOP soft slice nice niceness counter which +% LocalWords: getpriority who setpriority RTLinux RTAI Adeos fault FIFO First +% LocalWords: yield Robin setscheduler policy param OTHER priority setparam +% LocalWords: min getparam getscheduler interval robin ENOSYS fifo ping long +% LocalWords: affinity setaffinity unsigned mask cpu NUMA CLR ISSET SETSIZE +% LocalWords: getaffinity assembler deadlock REENTRANT SAFE diff --git a/sources/getcap.c b/sources/getcap.c index 116f3cb..19974ee 100644 --- a/sources/getcap.c +++ b/sources/getcap.c @@ -110,6 +110,7 @@ int main(int argc, char *argv[]) printf("Capability: %s\n", string); cap_free(capab); + cap_free(string); return 0; } /*