capacità \textsl{permesse} del processo.
\item[\textit{inheritable}] (chiamato originariamente \textit{allowed})
l'insieme delle capacità che con l'esecuzione del programma possono essere
- ereditate dal processo originario (che cioè vengono tolte
+ ereditate dal processo originario (che cioè non vengono tolte
dall'\textit{inheritable set} del processo originale all'esecuzione di
\func{exec}).
\item[\textit{effective}] in questo caso non si tratta di un insieme ma di un
unico valore logico; se attivo all'esecuzione del programma tutte le
capacità che risulterebbero \textsl{permesse} verranno pure attivate,
inserendole automaticamente nelle \textsl{effettive}, se disattivato nessuna
- capacità verrà attivata (cioè l'\textit{effective set} resta vuoto).
+ capacità verrà attivata (cioè l'\textit{effective set} resterà vuoto).
\end{basedescript}
\itindbeg{capabilities~bounding~set}
presenza di tutte le \textit{capabilities} eccetto \const{CAP\_SETPCAP}. In
questa situazione solo il primo processo eseguito nel sistema (quello con
\textsl{pid} 1, di norma \texttt{/sbin/init}) ha la possibilità di
-modificarlo, ogni processo eseguito successivamente, anche se eseguito con
-privilegi di amministratore,\footnote{per essere precisi occorreva la capacità
- \const{CAP\_SYS\_MODULE}.} è in grado soltanto di rimuovere una delle
-\textit{capabilities} già presenti dell'insieme.
-
-In questo caso l'effetto del \textit{capabilities bounding set} è che solo le
-capacità in esso presenti possono essere trasmesse ad un altro programma
-attraverso una \func{exec}. Questo in sostanza significa che se si elimina da
-esso una capacità, considerato che \texttt{init} (almeno nelle versioni
-ordinarie) non supporta la reimpostazione del \textit{bounding set}, questa
-non sarà più disponibile per nessun processo a meno di un riavvio, eliminando
-così in forma definitiva quella capacità per tutti, compreso
-l'amministratore.\footnote{la qual cosa, visto il default usato per il
- \textit{capabilities bounding set}, significa anche che \const{CAP\_SETPCAP}
- non è stata praticamente mai usata nella sua forma originale.}
+modificarlo; ogni processo eseguito successivamente, se dotato dei privilegi
+di amministratore, è in grado soltanto di rimuovere una delle
+\textit{capabilities} già presenti dell'insieme.\footnote{per essere precisi
+ occorreva la capacità \const{CAP\_SYS\_MODULE}.}
+
+In questo caso l'effetto complessivo del \textit{capabilities bounding set} è
+che solo le capacità in esso presenti possono essere trasmesse ad un altro
+programma attraverso una \func{exec}. Questo in sostanza significa che se un
+qualunque programma elimina da esso una capacità, considerato che
+\texttt{init} (almeno nelle versioni ordinarie) non supporta la reimpostazione
+del \textit{bounding set}, questa non sarà più disponibile per nessun processo
+a meno di un riavvio, eliminando così in forma definitiva quella capacità per
+tutti, compreso l'amministratore.\footnote{la qual cosa, visto il default
+ usato per il \textit{capabilities bounding set}, significa anche che
+ \const{CAP\_SETPCAP} non è stata praticamente mai usata nella sua forma
+ originale.}
Con il kernel 2.6.25 e le \textit{file capabilities} il \textit{bounding set}
è diventato una proprietà di ciascun processo, che viene propagata invariata
devono essere presenti nel \textit{bounding set} oltre che nel
\textit{permitted set} del processo. Questo limite vale anche per processi con
i privilegi di amministratore,\footnote{si tratta sempre di avere la
- \textit{capability} \const{CAP\_SETPCAP}.} per i quali non vale la
+ \textit{capability} \const{CAP\_SETPCAP}.} per i quali invece non vale la
condizione che le \textit{capabilities} da aggiungere nell'\textit{inheritable
set} debbano essere presenti nel proprio \textit{permitted set}.\footnote{lo
scopo anche in questo caso è ottenere una rimozione definitiva della
presenza di una radicale modifica del loro funzionamento con l'introduzione
delle \textit{file capabilities}. Considerato che il meccanismo originale era
incompleto e decisamente problematico nel caso di programmi che non ne
-sappessero tener conto,\footnote{si ebbe un grosso problema di sicurezza con
- \texttt{sendmail}: riuscendo a rimuovere \const{CAP\_SETGID}
+sapessero tener conto,\footnote{c'è stato un grosso problema di sicurezza con
+ \texttt{sendmail}, riuscendo a rimuovere \const{CAP\_SETGID}
dall'\textit{inheritable set} di un processo si ottenne di far fallire
\func{setuid} in maniera inaspettata per il programma (che aspettandosi
sempre il successo della funzione non ne controllava lo stato di uscita) con
\texttt{file\_*} quelli del file eseguito e con \texttt{bound\_set} il
\textit{capabilities bounding set}, dopo l'invocazione di \func{exec} il
processo otterrà dei nuovi insiemi di capacità \texttt{new\_*} secondo la
-formula (espressa in pseudocodice C) di fig.~\ref{fig:cap_across_exec}; si
+formula (espressa in pseudo-codice C) di fig.~\ref{fig:cap_across_exec}; si
noti come in particolare il \textit{capabilities bounding set} non viene
comunque modificato e resta lo stesso sia attraverso una \func{fork} che
attraverso una \func{exec}.
\itindend{capabilities~bounding~set}
A queste regole se ne aggiungono delle altre che servono a riprodurre il
-comportamento tradizionale di un sistema unix-like quando viene eseguito un
-file senza \textit{capabilities}, se si applicassero sempre così infatti, non
-essendo definite delle capacità né nel \textit{permitted set} né
-nell'\textit{inheritable set} del file, anche l'amministratore perderebbe
-tutti i privilegi eventualmente avuti dal processo.
-
-Per questo motivo se un programma senza \textit{capabilities} viene eseguito
-da un processo con \textit{real user-ID} 0, o se ha attivo il \acr{suid} bit
-ed appartiene all'amministratore, esso viene trattato come se tanto il
-\textit{permitted set} che l'\textit{inheritable set} fossero con tutte le
-\textit{capabilities} abilitate, e con l'\textit{effective set} attivo, col
-risultato di fornire comunque al processo tutte le capacità presenti nel
-proprio \textit{bounding set}.
-
-
+comportamento tradizionale di un sistema unix-like in tutta una serie di
+circostanze. La prima di queste è relativa a quello che avviene quando si
+esegue un file senza \textit{capabilities}; se infatti si considerasse questo
+equivalente al non averne assegnata alcuna, non essendo presenti capacità né
+nel \textit{permitted set} né nell'\textit{inheritable set} del file,
+nell'esecuzione di un qualunque programma l'amministratore perderebbe tutti i
+privilegi originali dal processo.
+
+Per questo motivo se un programma senza \textit{capabilities} assegnate viene
+eseguito da un processo con \textit{real user-ID} 0, esso verrà trattato come
+se tanto il \textit{permitted set} che l'\textit{inheritable set} fossero con
+tutte le \textit{capabilities} abilitate, con l'\textit{effective set} attivo,
+col risultato di fornire comunque al processo tutte le capacità presenti nel
+proprio \textit{bounding set}. Lo stesso avviene quando l'eseguibile ha attivo
+il \acr{suid} bit ed appartiene all'amministratore, in entrambi i casi si
+riesce così a riottenere il comportamento classico di un sistema unix-like.
+
+Una seconda circostanza è quella relativa a cosa succede alle
+\textit{capabilities} di un processo nelle possibili transizioni da
+\textit{user-ID} nullo a \textit{user-ID} non nullo o viceversa (corrispondenti
+rispettivamente a cedere o riottenere i i privilegi di amministratore) che si
+possono effettuare con le varie funzioni viste in
+sez.~\ref{sec:proc_setuid}. In questo caso la casistica è di nuovo alquanto
+complessa, considerata anche la presenza dei diversi gruppi di identificatori
+illustrati in tab.~\ref{tab:proc_uid_gid}, si avrà allora che:
+\begin{enumerate*}
+\item se si passa da \textit{effective user-ID} nullo a non nullo
+ l'\textit{effective set} del processo viene totalmente azzerato, se
+ viceversa si passa da \textit{effective user-ID} non nullo a nullo il
+ \textit{permitted set} viene copiato nell'\textit{effective set};
+\item se si passa da \textit{file system user-ID} nullo a non nullo verranno
+ cancellate dall'\textit{effective set} del processo tutte le capacità
+ attinenti i file, e cioè \const{CAP\_LINUX\_IMMUTABLE}, \const{CAP\_MKNOD},
+ \const{CAP\_DAC\_OVERRIDE}, \const{CAP\_DAC\_READ\_SEARCH},
+ \const{CAP\_MAC\_OVERRIDE}, \const{CAP\_CHOWN}, \const{CAP\_FSETID} e
+ \const{CAP\_FOWNER} (le prime due a partire dal kernel 2.2.30), nella
+ transizione inversa verranno invece inserite nell'\textit{effective set}
+ quelle capacità della precedente lista che sono presenti nel suo
+ \textit{permitted set}.
+\item se come risultato di una transizione riguardante gli identificativi dei
+ gruppi \texttt{real}, \textit{saved} ed \textit{effective} in cui si passa
+ da una situazione in cui uno di questi era nullo ad una in cui sono tutti
+ non nulli,\footnote{in sostanza questo è il caso di quando si chiama
+ \func{setuid} per rimuovere definitivamente i privilegi di amministratore
+ da un processo.} verranno azzerati completamente sia il \textit{permitted
+ set} che l'\textit{effective set}.
+\end{enumerate*}
+La combinazione di tutte queste regole consente di riprodurre il comportamento
+ordinario di un sistema di tipo Unix tradizionale, ma può risultare
+problematica qualora si voglia passare ad una configurazione di sistema
+totalmente basata sull'applicazione delle \textit{capabilities}; in tal caso
+infatti basta ad esempio eseguire un programma con \acr{suid} bit di proprietà
+dell'amministratore per far riottenere ad un processo tutte le capacità
+presenti nel suo \textit{bounding set}, anche se si era avuta la cura di
+cancellarle dal \textit{permitted set}.
+
+\itindbeg{securebits}
+
+Per questo motivo a partire dal kernel 2.6.26, se le \textit{file
+ capabilities} sono abilitate, ad ogni processo viene stata associata una
+ulteriore maschera binaria, chiamata \textit{securebits flags}, il cui sono
+mantenuti una serie di flag (vedi tab.~\ref{tab:securebits_values}) il cui
+valore consente di modificare queste regole speciali che si applicano ai
+processi con \textit{user-ID} nullo. La maschera viene sempre mantenuta
+attraverso una \func{fork}, mentre attraverso una \func{exec} viene sempre
+cancellato il flag \const{SECURE\_KEEP\_CAPS}.
-Quando un programma viene messo in esecuzione\footnote{cioè quando viene
- eseguita la \func{execve} con cui lo si lancia; in corrispondenza di una
- \func{fork} le \textit{capabilities} non vengono modificate.} esso eredita
-(nel senso che assume negli insiemi \textit{effective} e \textit{permitted})
-le \textit{capabilities} mantenute nell'insieme \textit{inherited}, a meno che
-non sia eseguito un programma \acr{suid} di root o la \func{exec} sia stata
-eseguita da un programma con \textsl{uid} reale zero; in tal caso il programma
-ottiene tutte le \textit{capabilities} presenti nel \textit{capabilities
- bounding set}. In questo modo si può far si che ad un processo eseguito in
-un secondo tempo possano essere trasmesse solo un insieme limitato di
-capacità, impedendogli di recuperare quelle assenti nell'insieme
-\textit{inherited}.
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}{|l|p{10cm}|}
+ \hline
+ \textbf{Flag} & \textbf{Descrizione} \\
+ \hline
+ \hline
+ \const{SECURE\_KEEP\_CAPS}& Il processo non subisce la cancellazione delle
+ sue \textit{capabilities} quando tutti i suoi
+ \textit{user-ID} passano ad un valore non
+ nullo (regola di compatibilità per il cambio
+ di \textit{user-ID} n. 3 del precedente
+ elenco), sostituisce il precedente uso
+ dell'operazione \const{PR\_SET\_KEEPCAPS} di
+ \func{prctl}.\\
+ \const{SECURE\_NO\_SETUID\_FIXUP}&Il processo non subisce le modifiche
+ delle sue \textit{capabilities} nel passaggio
+ da nullo a non nullo degli \textit{user-ID}
+ dei gruppi \textit{effective} e
+ \textit{file system} (regole di compatibilità
+ per il cambio di \textit{user-ID} nn. 1 e 2 del
+ precedente elenco).\\
+ \const{SECURE\_NOROOT} & Il processo non assume nessuna capacità
+ aggiuntiva quando esegue un programma, anche
+ se ha \textit{user-ID} nullo o il programma ha
+ il \acr{suid} bit attivo ed appartiene
+ all'amministratore (regola di compatibilità
+ per l'esecuzione di programmi senza
+ \textit{capabilities}).\\
+ \hline
+ \end{tabular}
+ \caption{Costanti identificative dei flag che compongono la maschera dei
+ \textit{securebits}.}
+ \label{tab:securebits_values}
+\end{table}
+A ciascuno dei flag di tab.~\ref{tab:securebits_values} è inoltre abbinato un
+corrispondente flag di blocco, identificato da una costante omonima con
+l'estensione \texttt{\_LOCKED}, la cui attivazione è irreversibile ed ha
+l'effetto di rendere permanente l'impostazione corrente del corrispondente
+flag ordinario; in sostanza con \const{SECURE\_KEEP\_CAPS\_LOCKED} si rende
+non più modificabile \const{SECURE\_KEEP\_CAPS}, ed analogamente avviene con
+\const{SECURE\_NO\_SETUID\_FIXUP\_LOCKED} per
+\const{SECURE\_NO\_SETUID\_FIXUP} e con \const{SECURE\_NOROOT\_LOCKED} per
+\const{SECURE\_NOROOT}.
+
+Per l'impostazione di questi flag sono stata predisposte due specifiche
+operazioni di \func{prctl} (vedi sez.~\ref{sec:process_prctl}),
+\const{PR\_GET\_SECUREBITS}, che consente di ottenerne il valore, e
+\const{PR\_SET\_SECUREBITS}, che consente di modificarne il valore; per
+quest'ultima sono comunque necessari i privilegi di amministratore ed in
+particolare la capacità \const{CAP\_SETPCAP}. Prima dell'introduzione dei
+\textit{securebits} era comunque possibile ottenere lo stesso effetto di
+\const{SECURE\_KEEP\_CAPS} attraverso l'uso di un'altra operazione di
+\func{prctl}, \const{PR\_SET\_KEEPCAPS}.
+
+\itindend{securebits}
+
+Oltre alla gestione dei \textit{securebits} la nuova versione delle
+\textit{file capabilities} prevede l'uso di \func{prctl} anche per la gestione
+del \textit{capabilities bounding set}, attraverso altre due operazioni
+dedicate, \const{PR\_CAPBSET\_READ} per controllarne il valore e
+\const{PR\_CAPBSET\_DROP} per modificarlo; quest'ultima di nuovo è una
+operazione privilegiata che richiede la capacità \const{CAP\_SETPCAP} e che,
+come indica chiaramente il nome, permette solo la rimozione di una
+\textit{capability} dall'insieme; per i dettagli sull'uso di tutte queste
+operazioni si rimanda alla rilettura di sez.~\ref{sec:process_prctl}.
% TODO verificare per process capability bounding set, vedi:
% http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3b7391de67da515c91f48aa371de77cb6cc5c07e
% LocalWords: INDENT major number IDE Documentation makedev proc copy LNK long
% LocalWords: euidaccess eaccess delete def tag qualifier permset calendar NOW
% LocalWords: mutt noatime relatime strictatime atim nsec mtim ctim atimensec
-% LocalWords: mtimensec utimes timeval futimes lutimes ENOSYS futimens OMIT
+% LocalWords: mtimensec utimes timeval futimes lutimes ENOSYS futimens OMIT PR
% LocalWords: utimensat timespec sec futimesat LIDS DAC OVERRIDE SEARCH chattr
% LocalWords: Discrectionary KILL SETGID domain SETUID setuid setreuid SETPCAP
% LocalWords: setresuid setfsuid IMMUTABLE immutable append only BIND SERVICE
% LocalWords: BROADCAST broadcast multicast multicasting RAW PACKET IPC LOCK
% LocalWords: memory mlock mlockall shmctl mmap MODULE RAWIO ioperm iopl PACCT
-% LocalWords: ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup
-% LocalWords: LEASE lease SETFCAP AUDIT permitted inherited inheritable AND
+% LocalWords: ptrace accounting NICE RESOURCE TTY CONFIG hangup vhangup dell'
+% LocalWords: LEASE lease SETFCAP AUDIT permitted inherited inheritable AND nn
% LocalWords: bounding execve fork capget capset header hdrp datap ESRCH undef
% LocalWords: version libcap lcap clear ncap caps pag capgetp CapInh CapPrm
% LocalWords: fffffeff CapEff getcap scheduling lookup dqinfo SETINFO GETFMT
% LocalWords: REALTIME securebits GETSTATS QFMT curspace curinodes btime itime
% LocalWords: QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit
% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace
-% LocalWords: Python Truelite Srl quotamodule Repository who
+% LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP
+% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I
%%% Local Variables:
%%% mode: latex
definire una della macro di funzionalità (vedi
sez.~\ref{sec:intro_gcc_glibc_std}) fra \macro{\_BSD\_SOURCE},
\macro{\_SVID\_SOURCE} e \macro{\_XOPEN\_SOURCE} (ad un valore maggiore o
-ugiale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
+uguale di 500). La prima funzione è \funcd{brk}, ed il suo prototipo è:
\begin{prototype}{unistd.h}{int brk(void *end\_data\_segment)}
Sposta la fine del segmento dei dati.
tal caso l'uso di \func{malloc} non è sufficiente, ed occorre utilizzare una
funzione specifica.
-Tradizionalmente per rispondere a questa esigenza sono state crate due
+Tradizionalmente per rispondere a questa esigenza sono state create due
funzioni diverse, \funcd{memalign} e \funcd{valloc}, oggi obsolete; i
rispettivi prototipi sono:
\begin{functions}
compare in POSIX.1), ed inoltre ci sono indicazioni discordi sui file che ne
contengono la definizione;\footnote{secondo SUSv2 \func{valloc} è definita in
\texttt{stdlib.h}, mentre sia le \acr{glibc} che le precedenti \acr{libc4} e
- \acr{lic5} la dichiarano in \texttt{malloc.h}, lo stesso vale per
+ \acr{libc5} la dichiarano in \texttt{malloc.h}, lo stesso vale per
\func{memalign} che in alcuni sistemi è dichiarata in \texttt{stdlib.h}.}
per questo motivo il loro uso è sconsigliato, essendo state sostituite dalla
nuova \funcd{posix\_memalign}, che è stata standardizzata in POSIX.1d; il suo
buffer.\\
\macro{MCHECK\_TAIL} & i dati immediatamente seguenti il buffer sono
stati modificati, succede quando si va scrivere
- oltre la dimensione correttta del buffer.\\
+ oltre la dimensione corretta del buffer.\\
\macro{MCHECK\_FREE} & il buffer è già stato disallocato.\\
\hline
\end{tabular}
\caption{Valori dello stato dell'allocazione di memoria ottenibili dalla
- funzione di teminazione installata con \func{mcheck}.}
+ funzione di terminazione installata con \func{mcheck}.}
\label{tab:mcheck_status_value}
\end{table}
L'indirizzo della lista delle variabili di ambiente è passato attraverso la
variabile globale \var{environ}, che viene definita automaticamente per
-cisascun processo, e a cui si può accedere attraverso una semplice
+ciascun processo, e a cui si può accedere attraverso una semplice
dichiarazione del tipo:
\includecodesnip{listati/env_ptr.c}
un esempio della struttura di questa lista, contenente alcune delle variabili
Per convenzione le stringhe che definiscono l'ambiente sono tutte del tipo
\textsl{\texttt{nome=valore}} ed in questa forma che le funzioni di gestione
che vedremo a breve se le aspettano, se pertanto si dovesse costruire
-manualemente un ambiente si abbia cura di rispettare questa convenzione.
+manualmente un ambiente si abbia cura di rispettare questa convenzione.
Inoltre alcune variabili, come quelle elencate in
fig.~\ref{fig:proc_envirno_list}, sono definite dal sistema per essere usate
da diversi programmi e funzioni: per queste c'è l'ulteriore convenzione di
\index{salto~non-locale|)}
+\subsection{La \textit{endianess}}
+\label{sec:sock_endianess}
+
+\itindbeg{endianess}
+
+Uno dei problemi di programmazione che può dar luogo ad effetti imprevisti è
+quello relativo alla cosiddetta \textit{endianess}. Questa è una
+caratteristica generale dell'architettura hardware di un computer che dipende
+dal fatto che la rappresentazione di un numero binario può essere fatta in due
+modi, chiamati rispettivamente \textit{big endian} e \textit{little endian} a
+seconda di come i singoli bit vengono aggregati per formare le variabili
+intere (ed in genere in diretta corrispondenza a come sono poi in realtà
+cablati sui bus interni del computer).
+
+\begin{figure}[htb]
+ \centering
+ \includegraphics[height=3cm]{img/endianess}
+ \caption{Schema della disposizione dei dati in memoria a seconda della
+ \textit{endianess}.}
+ \label{fig:sock_endianess}
+\end{figure}
+
+Per capire meglio il problema si consideri un intero a 32 bit scritto in una
+locazione di memoria posta ad un certo indirizzo. Come illustrato in
+fig.~\ref{fig:sock_endianess} i singoli bit possono essere disposti in memoria
+in due modi: a partire dal più significativo o a partire dal meno
+significativo. Così nel primo caso si troverà il byte che contiene i bit più
+significativi all'indirizzo menzionato e il byte con i bit meno significativi
+nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
+dato che si trova per prima la parte più grande. Il caso opposto, in cui si
+parte dal bit meno significativo è detto per lo stesso motivo \textit{little
+ endian}.
+
+Si può allora verificare quale tipo di \textit{endianess} usa il proprio
+computer con un programma elementare che si limita ad assegnare un valore ad
+una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
+Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
+allora se lo eseguiamo su un normale PC compatibile, che è \textit{little
+ endian} otterremo qualcosa del tipo:
+\begin{verbatim}
+[piccardi@gont sources]$ ./endtest
+Using value ABCDEF01
+val[0]= 1
+val[1]=EF
+val[2]=CD
+val[3]=AB
+\end{verbatim}%$
+mentre su un vecchio Macintosh con PowerPC, che è \textit{big endian} avremo
+qualcosa del tipo:
+\begin{verbatim}
+piccardi@anarres:~/gapil/sources$ ./endtest
+Using value ABCDEF01
+val[0]=AB
+val[1]=CD
+val[2]=EF
+val[3]= 1
+\end{verbatim}%$
+
+L'attenzione alla \textit{endianess} nella programmazione è importante, perché
+se si fanno assunzioni relative alla propria architettura non è detto che
+queste restino valide su un'altra architettura. Inoltre, come vedremo ad
+esempio in sez.~\ref{sec:sock_addr_func}, si possono avere problemi quando ci
+si trova a usare valori di un formato con una infrastruttura che ne usa
+un altro.
+
+La \textit{endianess} di un computer dipende essenzialmente dalla architettura
+hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
+IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
+formato dei dati contenuti nelle intestazioni dei protocolli di rete (il
+cosiddetto \textit{network order} è anch'esso \textit{big endian}; altri
+esempi di uso di questi due diversi formati sono quello del bus PCI, che è
+\textit{little endian}, o quello del bus VME che è \textit{big endian}.
+
+Esistono poi anche dei processori che possono scegliere il tipo di formato
+all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
+da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
+in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
+in genere resta sempre lo stesso,\footnote{su architettura PowerPC è possibile
+ cambiarlo, si veda sez.~\ref{sec:process_prctl}.} anche quando il processore
+permetterebbe di eseguire questi cambiamenti.
+
+\begin{figure}[htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{15cm}
+ \includecodesample{listati/endian.c}
+ \end{minipage}
+ \normalsize
+ \caption{La funzione \func{endian}, usata per controllare il tipo di
+ architettura della macchina.}
+ \label{fig:sock_endian_code}
+\end{figure}
+
+Per controllare quale tipo di ordinamento si ha sul proprio computer si è
+scritta una piccola funzione di controllo, il cui codice è riportato
+fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
+l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
+è \textit{little endian}.
+
+Come si vede la funzione è molto semplice, e si limita, una volta assegnato
+(\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
+di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
+Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
+accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
+ 11}) il valore della seconda assumendo che il primo byte sia quello meno
+significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
+\textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
+il valore del confronto delle due variabili.
+\itindend{endianess}
+
+
% LocalWords: like exec kernel thread main ld linux static linker char envp Gb
% LocalWords: sez POSIX exit system call cap abort shell diff errno stdlib int
% LocalWords: SUCCESS FAILURE void atexit stream fclose unistd descriptor init
% LocalWords: SIGCHLD wait function glibc SunOS arg argp execve fig high kb Mb
% LocalWords: memory alpha swap table printf Unit MMU paging fault SIGSEGV BSS
-% LocalWords: multitasking text segment NULL Block Started Symbol
+% LocalWords: multitasking text segment NULL Block Started Symbol fill black
% LocalWords: heap stack calling convention size malloc calloc realloc nmemb
% LocalWords: ENOMEM ptr uClib cfree error leak smartpointers hook Dmalloc brk
% LocalWords: Gray Watson Electric Fence Bruce Perens sbrk longjmp SUSv BSD ap
% LocalWords: clearenv libc value overwrite string reference result argument
% LocalWords: socket variadic ellipsis header stdarg execl self promoting last
% LocalWords: float double short register type dest src extern setjmp jmp buf
-% LocalWords: env return if while Di page cdecl
-% LocalWords: environment
+% LocalWords: env return if while Di page cdecl rectangle node anchor west PS
+% LocalWords: environment rounded corners dashed south width height draw east
+% LocalWords: exithandler handler violation inline SOURCE SVID XOPEN mincore
+% LocalWords: length unsigned vec EFAULT EAGAIN dell'I memalign valloc posix
+% LocalWords: boundary memptr alignment sizeof overrun mcheck abortfn enum big
+% LocalWords: mprobe DISABLED HEAD TAIL touch right emacs OSTYPE endianess IBM
+% LocalWords: endian little endtest Macintosh PowerPC Intel Digital Motorola
+% LocalWords: Sun order VME
%%% Local Variables:
%%% mode: latex
\begin{figure}[htb]
\centering
- \includegraphics[width=12cm]{img/task_struct}
+ \includegraphics[width=14cm]{img/task_struct}
\caption{Schema semplificato dell'architettura delle strutture usate dal
kernel nella gestione dei processi.}
\label{fig:proc_task_struct}
adottarli e provvedere a concluderne la terminazione.
-\subsection{La funzione \func{waitpid} e le funzioni di ricezione degli stati
- di uscita}
+\subsection{Le funzioni di attesa e ricezione degli stati di uscita}
\label{sec:proc_wait}
Uno degli usi più comuni delle capacità multitasking di un sistema unix-like
processi figli. Si è già sottolineato al paragrafo precedente come in questo
caso diventi necessario gestire esplicitamente la conclusione dei figli onde
evitare di riempire di \index{zombie} \textit{zombie} la tabella dei processi;
-le funzioni deputate a questo compito sono principalmente due, \funcd{wait} e
-\func{waitpid}. La prima, il cui prototipo è:
+le funzioni deputate a questo compito sono principalmente due, la prima è
+\funcd{wait} ed il suo prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
\end{errlist}}
\end{functions}
\noindent
-è presente fin dalle prime versioni di Unix; la funzione ritorna non appena un
-processo figlio termina. Se un figlio è già terminato la funzione ritorna
-immediatamente, se più di un figlio è terminato occorre chiamare la funzione
-più volte se si vuole recuperare lo stato di terminazione di tutti quanti.
+
+Questa funzione è presente fin dalle prime versioni di Unix; essa ritorna non
+appena un qualunque processo figlio termina. Se un figlio è già terminato
+prima della chiamata la funzione ritorna immediatamente, se più di un figlio è
+già terminato occorre continuare chiamare la funzione più volte se si vuole
+recuperare lo stato di terminazione di tutti quanti.
Al ritorno della funzione lo stato di terminazione del figlio viene salvato
nella variabile puntata da \param{status} e tutte le risorse del kernel
-relative al processo (vedi sez.~\ref{sec:proc_termination}) vengono rilasciate.
-Nel caso un processo abbia più figli il valore di ritorno (il \acr{pid} del
-figlio) permette di identificare qual è quello che è uscito.
+relative al processo (vedi sez.~\ref{sec:proc_termination}) vengono
+rilasciate. Nel caso un processo abbia più figli il valore di ritorno della
+funzione sarà impostato al \acr{pid} del processo di cui si è ricevuto lo
+stato di terminazione, cosa che permette di identificare qual è il figlio che
+è terminato.
Questa funzione ha il difetto di essere poco flessibile, in quanto ritorna
all'uscita di un qualunque processo figlio. Nelle occasioni in cui è
provvedere a ripetere la chiamata alla funzione nel caso il processo cercato
sia ancora attivo.
-Per questo motivo lo standard POSIX.1 ha introdotto la funzione
-\funcd{waitpid} che effettua lo stesso servizio, ma dispone di una serie di
-funzionalità più ampie, legate anche al controllo di sessione (si veda
+Per questo motivo lo standard POSIX.1 ha introdotto una seconda funzione che
+effettua lo stesso servizio, ma dispone di una serie di funzionalità più
+ampie, legate anche al controllo di sessione (si veda
sez.~\ref{sec:sess_job_control}). Dato che è possibile ottenere lo stesso
comportamento di \func{wait}\footnote{in effetti il codice
\code{wait(\&status)} è del tutto equivalente a \code{waitpid(WAIT\_ANY,
- \&status, 0)}.} si consiglia di utilizzare sempre questa funzione, il cui
-prototipo è:
+ \&status, 0)}.} si consiglia di utilizzare sempre questa nuova funzione,
+\funcd{waitpid}, il cui prototipo è:
\begin{functions}
\headdecl{sys/types.h}
\headdecl{sys/wait.h}
Nelle precedenti sezioni si sono trattate la gran parte delle funzioni che
attengono alla gestione ordinaria dei processi e delle loro proprietà più
-comuni. Tratteremo qui alcune \textit{system call} specialistiche dedicate
-alla gestione di alcune funzionalità specifiche ed avanzate il cui uso è in
-genere piuttosto ridotto.
+comuni. Tratteremo qui alcune \textit{system call} dedicate alla gestione di
+funzionalità dei processi molto specifiche ed avanzate, il cui uso è in genere
+piuttosto ridotto. Trattandosi di problematiche relativamente complesse, che
+spesso presuppongono la conoscenza di altri argomenti trattati più avanti
+nella guida, si può saltare questa lezione ad una prima lettura, tornando su
+di essa in un secondo tempo.
\subsection{La system call \func{clone}}
\label{sec:process_clone}
\subsection{La funzione \func{prctl}}
\label{sec:process_prctl}
-Da fare
+Benché la gestione ordinaria possa essere effettuata attraverso le funzioni
+che abbiamo già esaminato nelle sezioni precedenti, esistono una serie di
+proprietà e caratteristiche particolari dei processi non coperte da esse, per
+la cui gestione è stata predisposta una apposita \textit{system call} che
+fornisce una interfaccia generica per tutte le operazioni specialistiche. La
+funzione è \funcd{prctl} ed il suo prototipo è:\footnote{la funzione non è
+ standardizzata ed è specifica di Linux, anche se ne esiete una analoga in
+ IRIX, è stata introdotta con il kernel 2.1.57.}
+\begin{functions}
+ \headdecl{sys/prctl.h}
+
+ \funcdecl{int prctl(int option, unsigned long arg2, unsigned long arg3,
+ unsigned long arg4, unsigned long arg5)}
+
+ Esegue una operazione speciale sul processo corrente.
+
+ \bodydesc{La funzione ritorna 0 o un valore positivo dipendente
+ dall'operazione in caso di successo e $-1$ in caso di errore, nel qual
+ caso \var{errno} assumerà valori diversi a seconda del tipo di operazione
+ richiesta (in genere \errval{EINVAL} o \errval{EPERM}). }
+\end{functions}
+
+La funzione ritorna un valore nullo o positivo in caso di successo e $-1$ in
+caso di errore; il significato degli argomenti della funzione successivi al
+primo, il valore di ritorno in caso di successo, il tipo di errore restituito
+in \var{errno} dipendono dall'operazione eseguita, indicata tramite il primo
+argomento, \param{option}. Questo è un valore intero che identifica
+l'operazione, e deve essere specificato con l'uso di una delle costanti
+predefinite del seguente elenco, che illustra quelle disponibili al momento:
+
+\begin{basedescript}{\desclabelstyle{\pushlabel}}
+\item[\const{PR\_CAPBSET\_READ}] Controlla la disponibilità di una delle
+ \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}). La funzione
+ ritorna 1 se la capacità specificata nell'argomento \param{arg2} (con una
+ delle costanti di tab.~\ref{tab:proc_capabilities}) è presente nel
+ \textit{capabilities bounding set} del processo e zero altrimenti,
+ se \param{arg2} non è un valore valido si avrà un errore di \errval{EINVAL}.
+ Introdotta a partire dal kernel 2.6.25.
+\item[\const{PR\_CAPBSET\_DROP}] Rimuove permanentemente una delle
+ \textit{capabilities} (vedi sez.~\ref{sec:proc_capabilities}) dal processo e
+ da tutti i suoi discendenti. La funzione cancella la capacità specificata
+ nell'argomento \param{arg2} con una delle costanti di
+ tab.~\ref{tab:proc_capabilities} dal \textit{capabilities bounding set} del
+ processo. L'operazione richiede i privilegi di amministratore (la capacità
+ \const{CAP\_SETPCAP}), altrimenti fallisce con un errore di \errval{EPERM};
+ se il valore di \param{arg2} non è valido o se il supporto per le
+ \textit{file capabilities} non è stato compilato nel kernel fallisce con un
+ errore di \errval{EINVAL}. Introdotta a partire dal kernel 2.6.25.
+\item[\const{PR\_SET\_DUMPABLE}] Imposta il flag che determina se la
+ terminazione di un processo a causa di un segnale per il quale è prevista la
+ generazione di un file di \itindex{core~dump} \textit{core dump} (vedi
+ sez.~\ref{sec:sig_standard}) lo genera effettivamente. In genere questo flag
+ viene attivato automaticamente, ma per evitare problemi di sicurezza (la
+ generazione di un file da parte di processi privilegiati può essere usata
+ per sovrascriverne altri) viene cancellato quando si mette in esecuzione un
+ programma con i bit \acr{suid} e \acr{sgid} attivi (vedi
+ sez.~\ref{sec:file_special_perm}) o con l'uso delle funzioni per la modifica
+ degli \textit{user-ID} dei processi (vedi
+ sez.~\ref{sec:proc_setuid}). L'operazione è stata introdotta a partire dal
+ kernel 2.3.20, fino al kernel 2.6.12 e per i kernel successivi al 2.6.17 era
+ possibile usare solo un valore 0 di \param{arg2} per disattivare il flag ed
+ un valore 1 per attivarlo, nei kernel dal 2.6.13 al 2.6.17 è stato
+ supportato anche il valore 2 che causava la generazione di un
+ \itindex{core~dump} \textit{core dump} leggibile solo
+ dall'amministratore.\footnote{la funzionalità è stata rimossa per motivi di
+ sicurezza, in quanto consentiva ad un utente normale di creare un file di
+ \textit{core dump} appartenente all'amministratore in directory dove
+ l'utente avrebbe avuto permessi di accesso.}
+\item[\const{PR\_GET\_DUMPABLE}] Ottiene come valore di ritorno della funzione
+ lo stato corrente del flag che controlla la effettiva generazione dei
+ \itindex{core~dump} \textit{core dump}. Introdotta a partire dal kernel
+ 2.3.20.
+\item[\const{PR\_SET\_ENDIAN}] Imposta la \textit{endianess} del processo
+ chiamante secondo il valore fornito in \param{arg2}. I valori possibili sono
+ sono: \const{PR\_ENDIAN\_BIG} (\textit{big endian}),
+ \const{PR\_ENDIAN\_LITTLE} (\textit{little endian}), e
+ \const{PR\_ENDIAN\_PPC\_LITTLE} (lo pseudo \textit{little endian} del
+ PowerPC) Introdotta a partire dal kernel 2.6.18, solo per architettura
+ PowerPC.
+\item[\const{PR\_GET\_ENDIAN}] Ottiene il valore della \textit{endianess} del
+ processo chiamante, salvato sulla variabile puntata da \param{arg2} che deve
+ essere passata come di tipo \type{(int *)}. Introdotta a partire dal kernel
+ 2.6.18, solo su PowerPC.
+\item[\const{PR\_SET\_FPEMU}] Introdotta a partire dal kernel 2.4.18, solo su
+ ia64.
+\item[\const{PR\_GET\_FPEMU}] Introdotta a partire dal kernel 2.4.18, solo su
+ ia64.
+\item[\const{PR\_SET\_FPEXC}] Introdotta a partire dal kernel 2.4.21, solo su
+ PowerPC.
+\item[\const{PR\_GET\_FPEXC}] Introdotta a partire dal kernel 2.4.21, solo su
+ PowerPC.
+\item[\const{PR\_SET\_KEEPCAPS}] Introdotta a partire dal kernel 2.2.18.
+\item[\const{PR\_GET\_KEEPCAPS}] Introdotta a partire dal kernel 2.2.18.
+\item[\const{PR\_SET\_NAME}] Introdotta a partire dal kernel 2.6.9.
+\item[\const{PR\_GET\_NAME}] Introdotta a partire dal kernel 2.6.9.
+\item[\const{PR\_SET\_PDEATHSIG}] Introdotta a partire dal kernel 2.1.57.
+\item[\const{PR\_GET\_PDEATHSIG}] Introdotta a partire dal kernel 2.3.15.
+\item[\const{PR\_SET\_SECCOMP}] Introdotta a partire dal kernel 2.6.23.
+\item[\const{PR\_GET\_SECCOMP}] Introdotta a partire dal kernel 2.6.23.
+\item[\const{PR\_SET\_SECUREBITS}] Introdotta a partire dal kernel 2.6.26.
+\item[\const{PR\_GET\_SECUREBITS}] Introdotta a partire dal kernel 2.6.26.
+\item[\const{PR\_SET\_TIMING}] Introdotta a partire dal kernel 2.6.0-test4.
+\item[\const{PR\_GET\_TIMING}] Introdotta a partire dal kernel 2.6.0-test4.
+\item[\const{PR\_SET\_TSC}] Introdotta a partire dal kernel 2.6.26, solo su
+ x86.
+\item[\const{PR\_GET\_TSC}] Introdotta a partire dal kernel 2.6.26, solo su
+ x86.
+\item[\const{PR\_SET\_UNALIGN}] Introdotta con diverse versioni su diverse
+ architetture.
+\item[\const{PR\_GET\_UNALIGN}] Introdotta con diverse versioni su diverse
+ architetture.
+\label{sec:prctl_operation}
+\end{basedescript}
+
+
+
\subsection{La funzione \func{ptrace}}
\label{sec:process_ptrace}
Infine occorre sottolineare che sia gli indirizzi che i numeri di porta devono
essere specificati in quello che viene chiamato \textit{network order}, cioè
-con i bit ordinati in formato \textit{big endian}, questo comporta la
-necessità di usare apposite funzioni di conversione per mantenere la
-portabilità del codice (vedi sez.~\ref{sec:sock_addr_func} per i dettagli del
-problema e le relative soluzioni).
+con i bit ordinati in formato \textit{big endian} (vedi
+sez.~\ref{sec:sock_endianess}), questo comporta la necessità di usare apposite
+funzioni di conversione per mantenere la portabilità del codice (vedi
+sez.~\ref{sec:sock_addr_func} per i dettagli del problema e le relative
+soluzioni).
\subsection{La struttura degli indirizzi IPv6}
In questa sezione tratteremo delle varie funzioni usate per manipolare gli
indirizzi, limitandoci però agli indirizzi internet. Come accennato gli
-indirizzi e i numeri di porta usati nella rete devono essere forniti in
-formato opportuno (il \textit{network order}). Per capire cosa significa tutto
-ciò occorre introdurre un concetto generale che tornerà utile anche in
-seguito.
-
-
-\subsection{La \textit{endianess}}
-\label{sec:sock_endianess}
-
-\itindbeg{endianess}
-La rappresentazione di un numero binario in un computer può essere fatta in
-due modi, chiamati rispettivamente \textit{big endian} e \textit{little
- endian} a seconda di come i singoli bit vengono aggregati per formare le
-variabili intere (ed in genere in diretta corrispondenza a come sono poi in
-realtà cablati sui bus interni del computer).
-
-\begin{figure}[htb]
- \centering
- \includegraphics[height=3cm]{img/endianess}
- \caption{Schema della disposizione dei dati in memoria a seconda della
- \textit{endianess}.}
- \label{fig:sock_endianess}
-\end{figure}
-
-Per capire meglio il problema si consideri un intero a 32 bit scritto in una
-locazione di memoria posta ad un certo indirizzo. Come illustrato in
-fig.~\ref{fig:sock_endianess} i singoli bit possono essere disposti in memoria
-in due modi: a partire dal più significativo o a partire dal meno
-significativo. Così nel primo caso si troverà il byte che contiene i bit più
-significativi all'indirizzo menzionato e il byte con i bit meno significativi
-nell'indirizzo successivo; questo ordinamento è detto \textit{big endian},
-dato che si trova per prima la parte più grande. Il caso opposto, in cui si
-parte dal bit meno significativo è detto per lo stesso motivo \textit{little
- endian}.
-
-Si può allora verificare quale tipo di \textit{endianess} usa il proprio
-computer con un programma elementare che si limita ad assegnare un valore ad
-una variabile per poi ristamparne il contenuto leggendolo un byte alla volta.
-Il codice di detto programma, \file{endtest.c}, è nei sorgenti allegati,
-allora se lo eseguiamo su un PC otterremo:
-\begin{verbatim}
-[piccardi@gont sources]$ ./endtest
-Using value ABCDEF01
-val[0]= 1
-val[1]=EF
-val[2]=CD
-val[3]=AB
-\end{verbatim}%$
-mentre su di un Mac avremo:
-\begin{verbatim}
-piccardi@anarres:~/gapil/sources$ ./endtest
-Using value ABCDEF01
-val[0]=AB
-val[1]=CD
-val[2]=EF
-val[3]= 1
-\end{verbatim}%$
-
-
-La \textit{endianess} di un computer dipende essenzialmente dalla architettura
-hardware usata; Intel e Digital usano il \textit{little endian}, Motorola,
-IBM, Sun (sostanzialmente tutti gli altri) usano il \textit{big endian}. Il
-formato dei dati contenuti nelle intestazioni dei protocolli di rete è
-anch'esso \textit{big endian}; altri esempi di uso di questi due diversi
-formati sono quello del bus PCI, che è \textit{little endian}, o quello del
-bus VME che è \textit{big endian}.
-
-Esistono poi anche dei processori che possono scegliere il tipo di formato
-all'avvio e alcuni che, come il PowerPC o l'Intel i860, possono pure passare
-da un tipo di ordinamento all'altro con una specifica istruzione. In ogni caso
-in Linux l'ordinamento è definito dall'architettura e dopo l'avvio del sistema
-resta sempre lo stesso, anche quando il processore permetterebbe di eseguire
-questi cambiamenti.
-
-\begin{figure}[htb]
- \footnotesize \centering
- \begin{minipage}[c]{15cm}
- \includecodesample{listati/endian.c}
- \end{minipage}
- \normalsize
- \caption{La funzione \func{endian}, usata per controllare il tipo di
- architettura della macchina.}
- \label{fig:sock_endian_code}
-\end{figure}
-
-Per controllare quale tipo di ordinamento si ha sul proprio computer si è
-scritta una piccola funzione di controllo, il cui codice è riportato
-fig.~\ref{fig:sock_endian_code}, che restituisce un valore nullo (falso) se
-l'architettura è \textit{big endian} ed uno non nullo (vero) se l'architettura
-è \textit{little endian}.
-
-Come si vede la funzione è molto semplice, e si limita, una volta assegnato
-(\texttt{\small 9}) un valore di test pari a \texttt{0xABCD} ad una variabile
-di tipo \ctyp{short} (cioè a 16 bit), a ricostruirne una copia byte a byte.
-Per questo prima (\texttt{\small 10}) si definisce il puntatore \var{ptr} per
-accedere al contenuto della prima variabile, ed infine calcola (\texttt{\small
- 11}) il valore della seconda assumendo che il primo byte sia quello meno
-significativo (cioè, per quanto visto in fig.~\ref{fig:sock_endianess}, che sia
-\textit{little endian}). Infine la funzione restituisce (\texttt{\small 12})
-il valore del confronto delle due variabili.
-\itindend{endianess}
-
+indirizzi e i numeri di porta usati nella rete devono essere forniti nel
+cosiddetto \textit{network order}, che corrisponde al formato \textit{big
+ endian}, anche quando la proprio macchina non usa questo formati, cosa che
+può comportare la necessità di eseguire delle conversioni.
\subsection{Le funzioni per il riordinamento}
\label{sec:sock_func_ord}
-Il problema connesso \itindex{endianess} all'endianess è che quando si passano
-dei dati da un tipo di architettura all'altra i dati vengono interpretati in
-maniera diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà
-con i due byte in cui è suddiviso scambiati di posto. Per questo motivo si
-usano delle funzioni di conversione che servono a tener conto automaticamente
-della possibile differenza fra l'ordinamento usato sul computer e quello che
-viene usato nelle trasmissione sulla rete; queste funzioni sono \funcd{htonl},
+Come già visto in sez.~\ref{sec:sock_endianess} il problema connesso
+\itindex{endianess} all'\textit{endianess} è che quando si passano dei dati da
+un tipo di architettura all'altra i dati vengono interpretati in maniera
+diversa, e ad esempio nel caso dell'intero a 16 bit ci si ritroverà con i due
+byte in cui è suddiviso scambiati di posto. Per questo motivo si usano delle
+funzioni di conversione che servono a tener conto automaticamente della
+possibile differenza fra l'ordinamento usato sul computer e quello che viene
+usato nelle trasmissione sulla rete; queste funzioni sono \funcd{htonl},
\funcd{htons}, \funcd{ntohl} e \funcd{ntohs} ed i rispettivi prototipi sono:
\begin{functions}
\headdecl{netinet/in.h}
projects / gapil.git / commitdiff