Guida alla Programmazione in Linux. Simone Piccardi

Transcript

1 GaPiL Guida alla Programmazione in Linux Simone Piccardi 8 novembre 2003

2 ii Copyright c Simone Piccardi. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being Prefazione, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled GNU Free Documentation License.

3 Indice Prefazione xiii I Programmazione di sistema 1 1 L architettura del sistema Una panoramica Concetti base User space e kernel space Il kernel e il sistema Chiamate al sistema e librerie di funzioni Un sistema multiutente Gli standard Lo standard ANSI C I tipi di dati primitivi Lo standard IEEE POSIX Lo standard X/Open XPG Gli standard Unix Open Group Lo standard BSD Lo standard System V Il comportamento standard del gcc e delle glibc L interfaccia base con i processi Esecuzione e conclusione di un programma La funzione main Come chiudere un programma Le funzioni exit e _exit Le funzioni atexit e on_exit Conclusioni I processi e l uso della memoria I concetti generali La struttura della memoria di un processo Allocazione della memoria per i programmi C Le funzioni malloc, calloc, realloc e free La funzione alloca Le funzioni brk e sbrk Il controllo della memoria virtuale Parametri, opzioni ed ambiente di un processo Il formato dei parametri La gestione delle opzioni iii

4 iv INDICE Opzioni in formato esteso Le variabili di ambiente Problematiche di programmazione generica Il passaggio delle variabili e dei valori di ritorno Il passaggio di un numero variabile di argomenti Potenziali problemi con le variabili automatiche Il controllo di flusso non locale La gestione dei processi Introduzione L architettura della gestione dei processi Una panoramica sulle funzioni fondamentali Le funzioni di base Gli identificatori dei processi La funzione fork La funzione vfork La conclusione di un processo Le funzioni wait e waitpid Le funzioni wait3 e wait Le funzioni exec Il controllo di accesso Gli identificatori del controllo di accesso Le funzioni setuid e setgid Le funzioni setreuid e setregid Le funzioni seteuid e setegid Le funzioni setresuid e setresgid Le funzioni setfsuid e setfsgid Le funzioni setgroups e getgroups La gestione della priorità di esecuzione I meccanismi di scheduling Il meccanismo di scheduling standard Il meccanismo di scheduling real-time Problematiche di programmazione multitasking Le operazioni atomiche Le race condition e i deadlock Le funzioni rientranti L architettura dei file L architettura generale L organizzazione di file e directory I tipi di file Le due interfacce ai file L architettura della gestione dei file Il Virtual File System di Linux Il funzionamento del VFS Il funzionamento di un filesystem Unix Il filesystem ext

5 INDICE v 5 File e directory La gestione di file e directory Le funzioni link e unlink Le funzioni remove e rename I link simbolici La creazione e la cancellazione delle directory La creazione di file speciali Accesso alle directory La directory di lavoro I file temporanei La manipolazione delle caratteristiche dei files Le funzioni stat, fstat e lstat I tipi di file Le dimensioni dei file I tempi dei file La funzione utime Il controllo di accesso ai file I permessi per l accesso ai file I bit suid e sgid Il bit sticky La titolarità di nuovi file e directory La funzione access Le funzioni chmod e fchmod La funzione umask Le funzioni chown, fchown e lchown Un quadro d insieme sui permessi La funzione chroot I file: l interfaccia standard Unix L architettura di base L architettura dei file descriptor I file standard Le funzioni base La funzione open La funzione close La funzione lseek La funzione read La funzione write Caratteristiche avanzate La condivisione dei files Operazioni atomiche con i file La funzioni sync e fsync La funzioni dup e dup La funzione fcntl La funzione ioctl I file: l interfaccia standard ANSI C Introduzione I file stream Gli oggetti FILE Gli stream standard

6 vi INDICE Le modalità di bufferizzazione Funzioni base Apertura e chiusura di uno stream Lettura e scrittura su uno stream Input/output binario Input/output a caratteri Input/output di linea L input/output formattato Posizionamento su uno stream Funzioni avanzate Le funzioni di controllo Il controllo della bufferizzazione Gli stream e i thread La gestione del sistema, del tempo e degli errori Capacità e caratteristiche del sistema Limiti e parametri di sistema La funzione sysconf I limiti dei file La funzione pathconf La funzione uname Opzioni e configurazione del sistema La funzione sysctl ed il filesystem /proc La gestione delle proprietà dei filesystem La gestione di utenti e gruppi Il database di accounting Limitazione ed uso delle risorse L uso delle risorse Limiti sulle risorse Le risorse di memoria e processore La gestione dei tempi del sistema La misura del tempo in Unix La gestione del process time Le funzioni per il calendar time La gestione delle date La gestione degli errori La variabile errno Le funzioni strerror e perror Alcune estensioni GNU I segnali Introduzione I concetti base Le semantiche del funzionamento dei segnali Tipi di segnali La notifica dei segnali La classificazione dei segnali I segnali standard Segnali di errore di programma I segnali di terminazione I segnali di allarme

7 INDICE vii I segnali di I/O asincrono I segnali per il controllo di sessione I segnali di operazioni errate Ulteriori segnali Le funzioni strsignal e psignal La gestione dei segnali Il comportamento generale del sistema La funzione signal Le funzioni kill e raise Le funzioni alarm e abort Le funzioni di pausa e attesa Un esempio elementare Gestione avanzata Alcune problematiche aperte Gli insiemi di segnali o signal set La funzione sigaction La gestione della maschera dei segnali o signal mask Ulteriori funzioni di gestione I segnali real-time Terminali e sessioni di lavoro Il job control Una panoramica introduttiva I process group e le sessioni Il terminale di controllo e il controllo di sessione Dal login alla shell Prescrizioni per un programma daemon L I/O su terminale L architettura La gestione delle caratteristiche di un terminale La gestione della disciplina di linea Operare in modo non canonico La gestione avanzata dei file Le funzioni di I/O avanzato La modalità di I/O non-bloccante L I/O multiplexing L I/O asincrono I/O vettorizzato File mappati in memoria Il file locking L advisory locking La funzione flock Il file locking POSIX La funzione lockf Il mandatory locking

8 viii INDICE 12 La comunicazione fra processi La comunicazione fra processi tradizionale Le pipe standard Un esempio dell uso delle pipe Le funzioni popen e pclose Le pipe con nome, o fifo La funzione socketpair La comunicazione fra processi di System V Considerazioni generali Il controllo di accesso Gli identificatori ed il loro utilizzo Code di messaggi Semafori Memoria condivisa Tecniche alternative Alternative alle code di messaggi I file di lock La sincronizzazione con il file locking Il memory mapping anonimo La comunicazione fra processi di POSIX Considerazioni generali Code di messaggi Semafori Memoria condivisa II Programmazione di rete Introduzione alla programmazione di rete Modelli di programmazione Il modello client-server Il modello peer-to-peer Il modello three-tier I protocolli di rete Il modello ISO/OSI Il modello TCP/IP (o DoD) Criteri generali dell architettura del TCP/IP Il protocollo TCP/IP Il quadro generale Internet Protocol (IP) User Datagram Protocol (UDP) Transport Control Protocol (TCP) Limiti e dimensioni riguardanti la trasmissione dei dati Introduzione ai socket Una panoramica I socket Concetti base La creazione di un socket La funzione socket Il dominio, o protocol family

9 INDICE ix Il tipo, o stile Le strutture degli indirizzi dei socket La struttura generica La struttura degli indirizzi IPv La struttura degli indirizzi IPv La struttura degli indirizzi locali La struttura degli indirizzi AppleTalk La struttura degli indirizzi dei packet socket Le funzioni di conversione degli indirizzi La endianess Le funzioni per il riordinamento Le funzioni inet_aton, inet_addr e inet_ntoa Le funzioni inet_pton e inet_ntop Socket TCP elementari Il funzionamento di una connessione TCP La creazione della connessione: il three way handshake Le opzioni TCP La terminazione della connessione Un esempio di connessione Lo stato TIME_WAIT I numeri di porta Le porte ed il modello client/server Le funzioni di base per la gestione dei socket La funzione bind La funzione connect La funzione listen La funzione accept Le funzioni getsockname e getpeername La funzione close Un esempio elementare: il servizio daytime Il comportamento delle funzioni di I/O Il client daytime Un server daytime iterativo Un server daytime concorrente Un esempio più completo: il servizio echo Il servizio echo Il client: prima versione Il server: prima versione L avvio e il funzionamento normale La conclusione normale La gestione dei processi figli I vari scenari critici La terminazione precoce della connessione La terminazione precoce del server Altri scenari di terminazione della connessione

10 x INDICE 16 Socket TCP avanzati Socket I/O multiplexing Il comportamento della funzione select con i socket Un esempio di I/O multiplexing La funzione shutdown Un server basato sull I/O multiplexing Un esempio di I/O multiplexing con poll Le opzioni dei socket I dati out-of-band A Il livello di rete 421 A.1 Il protocollo IP A.1.1 Introduzione A.2 Il protocollo IPv A.2.1 I motivi della transizione A.2.2 Principali caratteristiche di IPv A.2.3 L intestazione di IPv A.2.4 Gli indirizzi di IPv A.2.5 La notazione A.2.6 La architettura degli indirizzi di IPv A.2.7 Indirizzi unicast provider-based A.2.8 Indirizzi ad uso locale A.2.9 Indirizzi riservati A.2.10 Multicasting A.2.11 Indirizzi anycast A.2.12 Le estensioni A.2.13 Qualità di servizio A.2.14 Etichette di flusso A.2.15 Priorità A.2.16 Sicurezza a livello IP A.2.17 Autenticazione A.2.18 Riservatezza A.2.19 Autoconfigurazione A.2.20 Autoconfigurazione stateless A.2.21 Autoconfigurazione stateful B Il livello di trasporto 439 B.1 Il protocollo TCP B.1.1 Gli stati del TCP C I codici di errore 441 C.1 Gli errori dei file C.2 Gli errori dei processi C.3 Gli errori di rete C.4 Errori generici C.5 Errori del kernel D Ringraziamenti 449

11 INDICE xi E GNU Free Documentation License 451 E.1 Applicability and Definitions E.2 Verbatim Copying E.3 Copying in Quantity E.4 Modifications E.5 Combining Documents E.6 Collections of Documents E.7 Aggregation With Independent Works E.8 Translation E.9 Termination E.10 Future Revisions of This License

12

13 Prefazione Nelle motivazioni in cui si introduce la GNU Free Documentation License (FDL) (reperibili su si dà una grande rilevanza all importanza di disporre di buoni manuali, in quanto la fruibilità e la possibilità di usare appieno il software libero vengono notevolmente ridotte senza la presenza di un valido manuale che sia altrettanto liberamente disponibile. E, come per il software libero, anche in questo caso è di fondamentale importanza la libertà di accedere ai sorgenti (e non solo al risultato finale, sia questo una stampa o un file formattato) e la libertà di modificarli per apportarvi migliorie, aggiornamenti, etc. Per questo la Free Software Foundation ha approntato una licenza apposita per la documentazione, che tiene conto delle differenze che restano fra un testo e un programma. Esiste però un altro campo, diverso dalla documentazione e dai manuali, in cui avere a disposizione testi liberi, aperti e modificabili è essenziale ed estremamente utile: quello della didattica e dell educazione. E benché anche questo campo sia citato dalla FDL non è altrettanto comune trovarlo messo in pratica. In particolare sarebbe di grande interesse poter disporre di testi didattici in grado di crescere, essere adattati alle diverse esigenze, modificati e ampliati, o anche ridotti per usi specifici, nello stesso modo in cui si fa per il software libero. Questo progetto mira alla stesura di un libro il più completo e chiaro possibile sulla programmazione in un sistema basato su un kernel Linux. Essendo i concetti in gran parte gli stessi, il testo dovrebbe restare valido anche per la programmazione in ambito Unix generico, ma resta una attenzione specifica alle caratteristiche peculiari del kernel Linux e delle versioni delle librerie del C in uso con esso, ed in particolare per le glibc del progetto GNU (che ormai sono usate nella stragrande maggioranza dei casi). Nonostante l uso nel titolo del solo Linux, (che si è fatto sia per brevità sia perché il libro ha a che fare principalmente con le interfacce del kernel e dei principali standard supportati delle librerie del C), voglio sottolineare che trovo assolutamente scorretto chiamare in questo modo un sistema completo. Il kernel infatti, senza tutte le librerie e le applicazioni di base fornite dal progretto GNU, sarebbe sostanzialmente inutile: per questo il nome del sistema nella sua interezza non può che essere GNU/Linux. L obiettivo finale di questo progetto è quello di riuscire a ottenere un testo utilizzabile per apprendere i concetti fondamentali della programmazione di sistema della stessa qualità dei libri del compianto R. W. Stevens (è un progetto molto ambizioso...). Infatti benché le pagine di manuale del sistema (quelle che si accedono con il comando man) e il manuale delle librerie del C GNU siano una fonte inesauribile di informazioni (da cui si è costantemente attinto nella stesura di tutto il testo) la loro struttura li rende totalmente inadatti ad una trattazione che vada oltre la descrizione delle caratteristiche particolari dello specifico argomento in esame (ed in particolare lo GNU C Library Reference Manual non brilla per chiarezza espositiva). Per questo motivo si è cercato di fare tesoro di quanto appreso dai testi di R. Stevens (in xiii

14 xiv PREFAZIONE particolare [1] e [2]) per rendere la trattazione dei vari argomenti in una sequenza logica il più esplicativa possibile, corredata, quando possibile, da programmi di esempio. Il progetto prevede il rilascio del testo sotto licenza FDL, ed una modalità di realizzazione aperta che permetta di accogliere i contributi di chiunque sia interessato. Tutti i programmi di esempio sono invece rilasciati sotto GNU GPL. Dato che sia il kernel che tutte le librerie fondamentali di GNU/Linux sono scritte in C, questo sarà il linguaggio di riferimento del testo. In particolare il compilatore usato per provare tutti i programmi e gli esempi descritti nel testo è lo GNU GCC. Il testo presuppone una conoscenza media del linguaggio, e di quanto necessario per scrivere, compilare ed eseguire un programma. Infine, dato che lo scopo del progetto è la produzione di un libro, si è scelto di usare LATEX come ambiente di sviluppo del medesimo, sia per l impareggiabile qualità tipografica ottenibile, che per la congruenza dello strumento, tanto sul piano pratico, quanto su quello filosofico. Il testo sarà, almeno inizialmente, in italiano.

15 Parte I Programmazione di sistema 1

16

17 Capitolo 1 L architettura del sistema In questo primo capitolo sarà fatta un introduzione ai concetti generali su cui è basato un sistema operativo di tipo Unix come GNU/Linux, in questo modo potremo fornire una base di comprensione mirata a sottolineare le peculiarità del sistema che sono più rilevanti per quello che riguarda la programmazione. Dopo un introduzione sulle caratteristiche principali di un sistema di tipo Unix passeremo ad illustrare alcuni dei concetti base dell architettura di GNU/Linux (che sono comunque comuni a tutti i sistemi unix-like) ed introdurremo alcuni degli standard principali a cui viene fatto riferimento. 1.1 Una panoramica In questa prima sezione faremo una breve panoramica sull architettura del sistema. Chi avesse già una conoscenza di questa materia può tranquillamente saltare questa sezione Concetti base Il concetto base di un sistema unix-like è quello di un nucleo del sistema (il cosiddetto kernel, nel nostro caso Linux) a cui si demanda la gestione delle risorse essenziali (la CPU, la memoria, le periferiche) mentre tutto il resto, quindi anche la parte che prevede l interazione con l utente, deve venire realizzato tramite programmi eseguiti dal kernel e che accedano alle risorse hardware tramite delle richieste a quest ultimo. Fin dall inizio uno Unix si presenta come un sistema operativo multitasking, cioè in grado di eseguire contemporaneamente più programmi, e multiutente, in cui è possibile che più utenti siano connessi ad una macchina eseguendo più programmi in contemporanea (in realtà, almeno per macchine a processore singolo, i programmi vengono eseguiti singolarmente a rotazione). I kernel Unix più recenti, come Linux, sono realizzati sfruttando alcune caratteristiche dei processori moderni come la gestione hardware della memoria e la modalità protetta. In sostanza con i processori moderni si può disabilitare temporaneamente l uso di certe istruzioni e l accesso a certe zone di memoria fisica. Quello che succede è che il kernel è il solo programma ad essere eseguito in modalità privilegiata, con il completo accesso all hardware, mentre i programmi normali vengono eseguiti in modalità protetta (e non possono accedere direttamente alle zone di memoria riservate o alle porte di input/output). Una parte del kernel, lo scheduler, si occupa di stabilire, ad intervalli fissi e sulla base di un opportuno calcolo delle priorità, quale processo deve essere posto in esecuzione (il cosiddetto preemptive scheduling). Questo verrà comunque eseguito in modalità protetta; quando necessario il processo potrà accedere alle risorse hardware soltanto attraverso delle opportune chiamate al sistema che restituiranno il controllo al kernel. 3

18 4 CAPITOLO 1. L ARCHITETTURA DEL SISTEMA La memoria viene sempre gestita dal kernel attraverso il meccanismo della memoria virtuale, che consente di assegnare a ciascun processo uno spazio di indirizzi virtuale (vedi sez. 2.2) che il kernel stesso, con l ausilio della unità di gestione della memoria, si incaricherà di rimappare automaticamente sulla memoria disponibile, salvando su disco quando necessario (nella cosiddetta area di swap) le pagine di memoria in eccedenza. Le periferiche infine vengono viste in genere attraverso un interfaccia astratta che permette di trattarle come fossero file, secondo il concetto per cui everything is a file, su cui torneremo in dettaglio in cap. 4, (questo non è vero per le interfacce di rete, che hanno un interfaccia diversa, ma resta valido il concetto generale che tutto il lavoro di accesso e gestione a basso livello è effettuato dal kernel) User space e kernel space Uno dei concetti fondamentali su cui si basa l architettura dei sistemi Unix è quello della distinzione fra il cosiddetto user space, che contraddistingue l ambiente in cui vengono eseguiti i programmi, e il kernel space, che è l ambiente in cui viene eseguito il kernel. Ogni programma vede sé stesso come se avesse la piena disponibilità della CPU e della memoria ed è, salvo i meccanismi di comunicazione previsti dall architettura, completamente ignaro del fatto che altri programmi possono essere messi in esecuzione dal kernel. Per questa separazione non è possibile ad un singolo programma disturbare l azione di un altro programma o del sistema e questo è il principale motivo della stabilità di un sistema unixlike nei confronti di altri sistemi in cui i processi non hanno di questi limiti, o che vengono per vari motivi eseguiti al livello del kernel. Pertanto deve essere chiaro a chi programma in Unix che l accesso diretto all hardware non può avvenire se non all interno del kernel; al di fuori dal kernel il programmatore deve usare le opportune interfacce che quest ultimo fornisce allo user space Il kernel e il sistema Per capire meglio la distinzione fra kernel space e user space si può prendere in esame la procedura di avvio di un sistema unix-like; all avvio il BIOS (o in generale il software di avvio posto nelle EPROM) eseguirà la procedura di avvio del sistema (il cosiddetto boot), incaricandosi di caricare il kernel in memoria e di farne partire l esecuzione; quest ultimo, dopo aver inizializzato le periferiche, farà partire il primo processo, init, che è quello che a sua volta farà partire tutti i processi successivi. Fra questi ci sarà pure quello che si occupa di dialogare con la tastiera e lo schermo della console, e quello che mette a disposizione dell utente che si vuole collegare, un terminale e la shell da cui inviare i comandi. E da rimarcare come tutto ciò, che usualmente viene visto come parte del sistema, non abbia in realtà niente a che fare con il kernel, ma sia effettuato da opportuni programmi che vengono eseguiti, allo stesso modo di un qualunque programma di scrittura o di disegno, in user space. Questo significa, ad esempio, che il sistema di per sé non dispone di primitive per tutta una serie di operazioni (come la copia di un file) che altri sistemi (come Windows) hanno invece al loro interno. Pertanto buona parte delle operazioni di normale amministrazione di un sistema, come quella in esempio, sono implementate come normali programmi. Per questo motivo quando ci si riferisce al sistema nella sua interezza è corretto parlare di un sistema GNU/Linux: da solo il kernel è assolutamente inutile; quello che costruisce un sistema operativo utilizzabile è la presenza di tutta una serie di librerie e programmi di utilità (che di norma sono quelli realizzati dal progetto GNU della Free Software Foundation) che permettono di eseguire le normali operazioni che ci si aspetta da un sistema operativo.

19 1.1. UNA PANORAMICA Chiamate al sistema e librerie di funzioni Come accennato le interfacce con cui i programmi possono accedere all hardware vanno sotto il nome di chiamate al sistema (le cosiddette system call), si tratta di un insieme di funzioni che un programma può chiamare, per le quali viene generata un interruzione del processo passando il controllo dal programma al kernel. Sarà poi quest ultimo che (oltre a compiere una serie di operazioni interne come la gestione del multitasking e l allocazione della memoria) eseguirà la funzione richiesta in kernel space restituendo i risultati al chiamante. Ogni versione di Unix ha storicamente sempre avuto un certo numero di queste chiamate, che sono riportate nella seconda sezione del Manuale di programmazione di Unix (quella cui si accede con il comando man 2 <nome>) e Linux non fa eccezione. Queste sono poi state codificate da vari standard, che esamineremo brevemente in sez Uno schema elementare della struttura del sistema è riportato in fig Figura 1.1: Schema di massima della struttura di interazione fra processi, kernel e dispositivi in Linux. Normalmente ciascuna di queste chiamate al sistema viene rimappata in opportune funzioni con lo stesso nome definite dentro la Libreria Standard del C, che, oltre alle interfacce alle system call, contiene anche tutta la serie delle ulteriori funzioni definite dai vari standard, che sono comunemente usate nella programmazione. Questo è importante da capire perché programmare in Linux significa anzitutto essere in grado di usare le varie interfacce contenute nella Libreria Standard del C, in quanto né il kernel, né il linguaggio C, implementano direttamente operazioni comuni come l allocazione dinamica della memoria, l input/output bufferizzato o la manipolazione delle stringhe, presenti in qualunque programma. Quanto appena illustrato mette in evidenza il fatto che nella stragrande maggioranza dei casi, 1 si dovrebbe usare il nome GNU/Linux (piuttosto che soltanto Linux) in quanto una parte essenziale del sistema (senza la quale niente funzionerebbe) è la GNU Standard C Library (in breve glibc), ovvero la libreria realizzata dalla Free Software Foundation nella quale sono state 1 esistono implementazioni diverse delle librerie Standard del C, come le libc5 o le uclib, che non derivano dal progetto GNU. Le libc5 oggi sono, tranne casi particolari, completamente soppiantate dalle glibc, le uclib pur non essendo complete come le glibc, restano invece molto diffuse nel mondo embedded per le loro di dimensioni ridotte (e soprattutto la possibilità di togliere le parti non necessarie), e pertanto costituiscono un valido rimpiazzo delle glibc in tutti quei sistemi specializzati che richiedono una minima occupazione di memoria.

20 6 CAPITOLO 1. L ARCHITETTURA DEL SISTEMA implementate tutte le funzioni essenziali definite negli standard POSIX e ANSI C, utilizzabili da qualunque programma. Le funzioni di questa libreria sono quelle riportate dalla terza sezione del Manuale di Programmazione di Unix (cioè accessibili con il comando man 3 <nome>) e sono costruite sulla base delle chiamate al sistema del kernel; è importante avere presente questa distinzione, fondamentale dal punto di vista dell implementazione, anche se poi, nella realizzazione di normali programmi, non si hanno differenze pratiche fra l uso di una funzione di libreria e quello di una chiamata al sistema Un sistema multiutente Linux, come gli altri kernel Unix, nasce fin dall inizio come sistema multiutente, cioè in grado di fare lavorare più persone in contemporanea. Per questo esistono una serie di meccanismi di sicurezza, che non sono previsti in sistemi operativi monoutente, e che occorre tenere presente. Il concetto base è quello di utente (user) del sistema, le cui capacità rispetto a quello che può fare sono sottoposte a ben precisi limiti. Sono così previsti una serie di meccanismi per identificare i singoli utenti ed una serie di permessi e protezioni per impedire che utenti diversi possano danneggiarsi a vicenda o danneggiare il sistema. Ogni utente è identificato da un nome (l username), che è quello che viene richiesto all ingresso nel sistema dalla procedura di login (descritta in dettaglio in sez ). Questa procedura si incarica di verificare l identità dell utente, in genere attraverso la richiesta di una parola d ordine (la password), anche se sono possibili meccanismi diversi. 2 Eseguita la procedura di riconoscimento in genere il sistema manda in esecuzione un programma di interfaccia (che può essere la shell su terminale o un interfaccia grafica) che mette a disposizione dell utente un meccanismo con cui questo può impartire comandi o eseguire altri programmi. Ogni utente appartiene anche ad almeno un gruppo (il cosiddetto default group), ma può essere associato ad altri gruppi (i supplementary group), questo permette di gestire i permessi di accesso ai file e quindi anche alle periferiche, in maniera più flessibile, definendo gruppi di lavoro, di accesso a determinate risorse, etc. L utente e il gruppo sono identificati da due numeri (la cui corrispondenza ad un nome espresso in caratteri è inserita nei due file /etc/passwd e /etc/groups). Questi numeri sono l user identifier, detto in breve user-id, ed indicato dall acronimo uid, e il group identifier, detto in breve group-id, ed identificato dall acronimo gid, e sono quelli che vengono usati dal kernel per identificare l utente. In questo modo il sistema è in grado di tenere traccia per ogni processo dell utente a cui appartiene ed impedire ad altri utenti di interferire con esso. Inoltre con questo sistema viene anche garantita una forma base di sicurezza interna in quanto anche l accesso ai file (vedi sez. 5.3) è regolato da questo meccanismo di identificazione. Infine in ogni Unix è presente un utente speciale privilegiato, il cosiddetto superuser, il cui username è di norma root, ed il cui uid è zero. Esso identifica l amministratore del sistema, che deve essere in grado di fare qualunque operazione; per l utente root infatti i meccanismi di controllo descritti in precedenza sono disattivati. 3 2 Ad esempio usando la libreria PAM (Pluggable Autentication Methods) è possibile astrarre completamente dai meccanismi di autenticazione e sostituire ad esempio l uso delle password con meccanismi di identificazione biometrica. 3 i controlli infatti vengono sempre eseguiti da un codice del tipo if (uid) {... }

21 1.2. GLI STANDARD Gli standard In questa sezione faremo una breve panoramica relativa ai vari standard che nel tempo sono stati formalizzati da enti, associazioni, consorzi e organizzazioni varie al riguardo del sistema o alle caratteristiche che si sono stabilite come standard di fatto in quanto facenti parte di alcune implementazioni molto diffuse come BSD o SVr4. Ovviamente prenderemo in considerazione solo gli standard riguardanti interfacce di programmazione e le altre caratteristiche di un sistema unix-like (alcuni standardizzano pure i comandi base del sistema e la shell) ed in particolare ci concentreremo sul come ed in che modo essi sono supportati sia per quanto riguarda il kernel che le librerie del C (con una particolare attenzione alle glibc) Lo standard ANSI C Lo standard ANSI C è stato definito nel 1989 dall American National Standard Institute, come standard del linguaggio C ed è stato successivamente adottato dalla International Standard Organisation come standard internazionale con la sigla ISO/IEC 9899:1990, e va anche sotto il nome di standard ISO C. Scopo dello standard è quello di garantire la portabilità dei programmi C fra sistemi operativi diversi, ma oltre alla sintassi ed alla semantica del linguaggio C (operatori, parole chiave, tipi di dati) lo standard prevede anche una libreria di funzioni che devono poter essere implementate su qualunque sistema operativo. Per questo motivo, anche se lo standard non ha alcun riferimento ad un sistema di tipo Unix, GNU/Linux (per essere precisi le glibc), come molti Unix moderni, provvede la compatibilità con questo standard, fornendo le funzioni di libreria da esso previste. Queste sono dichiarate in una serie di header file 4 (anch essi provvisti dalla glibc), In tab. 1.1 si sono riportati i principali header file definiti nello standard POSIX, insieme a quelli definiti negli altri standard descritti nelle sezioni successive. Header Standard ANSI C POSIX Contenuto assert.h Verifica le asserzioni fatte in un programma. errno.h Errori di sistema. fcntl.h Controllo sulle opzioni dei file. limits.h Limiti e parametri del sistema stdio.h I/O bufferizzato in standard ANSI C. stdlib.h definizioni della libreria standard. Tabella 1.1: Elenco dei vari header file definiti dallo standard POSIX. In realtà glibc ed i relativi header file definiscono un insieme di funzionalità in cui sono incluse come sottoinsieme anche quelle previste dallo standard ANSI C. È possibile ottenere una conformità stretta allo standard (scartando le funzionalità addizionali) usando il gcc con l opzione -ansi. Questa opzione istruisce il compilatore a definire nei vari header file soltanto le funzionalità previste dallo standard ANSI C e a non usare le varie estensioni al linguaggio e al preprocessore da esso supportate. 4 i file di dichiarazione di variabili, tipi e funzioni, usati normalmente da un compilatore C. Per poter accedere alle funzioni occorre includere con la direttiva #include questi file nei propri programmi; per ciascuna funzione che tratteremo in seguito indicheremo anche gli header file necessari ad usarla.

22 8 CAPITOLO 1. L ARCHITETTURA DEL SISTEMA I tipi di dati primitivi Uno dei problemi di portabilità del codice più comune è quello dei tipi di dati utilizzati nei programmi, che spesso variano da sistema a sistema, o anche da una architettura ad un altra (ad esempio passando da macchine con processori 32 bit a 64). In particolare questo è vero nell uso dei cosiddetti tipi elementari del linguaggio C (come int) la cui dimensione varia a seconda dell architettura hardware. Storicamente alcuni tipi nativi dello standard ANSI C sono sempre stati associati ad alcune variabili nei sistemi Unix, dando per scontata la dimensione. Ad esempio la posizione corrente all interno di un file è sempre stata associata ad un intero a 32 bit, mentre il numero di dispositivo è sempre stato associato ad un intero a 16 bit. Storicamente questi erano definiti rispettivamente come int e short, ma tutte le volte che, con l evolversi ed il mutare delle piattaforme hardware, alcuni di questi tipi si sono rivelati inadeguati o sono cambiati, ci si è trovati di fronte ad una infinita serie di problemi di portabilità. Tipo caddr_t clock_t dev_t gid_t ino_t key_t loff_t mode_t nlink_t off_t pid_t rlim_t sigset_t size_t ssize_t ptrdiff_t time_t uid_t Contenuto core address. contatore del tempo di sistema. Numero di dispositivo. Identificatore di un gruppo. Numero di inode. Chiave per il System V IPC. Posizione corrente in un file. Attributi di un file. Contatore dei link su un file. Posizione corrente in un file. Identificatore di un processo. Limite sulle risorse. Insieme di segnali. Dimensione di un oggetto. Dimensione in numero di byte ritornata dalle funzioni. Differenza fra due puntatori. Numero di secondi (in tempo di calendario). Identificatore di un utente. Tabella 1.2: Elenco dei tipi primitivi, definiti in sys/types.h. Per questo motivo tutte le funzioni di libreria di solito non fanno riferimento ai tipi elementari dello standard del linguaggio C, ma ad una serie di tipi primitivi del sistema, riportati in tab. 1.2, e definiti nell header file sys/types.h, in modo da mantenere completamente indipendenti i tipi utilizzati dalle funzioni di sistema dai tipi elementari supportati dal compilatore C Lo standard IEEE POSIX Uno standard più attinente al sistema nel suo complesso (e che concerne sia il kernel che le librerie) è lo standard POSIX. Esso prende origine dallo standard ANSI C, che contiene come sottoinsieme, prevedendo ulteriori capacità per le funzioni in esso definite, ed aggiungendone di nuove. In realtà POSIX è una famiglia di standard diversi, il cui nome, suggerito da Richard Stallman, sta per Portable Operating System Interface, ma la X finale denuncia la sua stretta relazione con i sistemi Unix. Esso nasce dal lavoro dell IEEE (Institute of Electrical and Electronics Engeneers) che ne produsse una prima versione, nota come IEEE , mirante a standardizzare l interfaccia con il sistema operativo. Ma gli standard POSIX non si limitano alla standardizzazione delle funzioni di libreria, e in seguito sono stati prodotti anche altri standard per la shell e i comandi di sistema (1003.2), per le estensioni realtime e per i thread (1003.1d e c) e vari altri. In tab. 1.3 è riportata una

23 1.2. GLI STANDARD 9 classificazione sommaria dei principali documenti prodotti, e di come sono identificati fra IEEE ed ISO; si tenga conto inoltre che molto spesso si usa l estensione IEEE anche come aggiunta al nome POSIX (ad esempio si può parlare di POSIX.4 come di POSIX.1b). Si tenga presente inoltre che nuove specifiche e proposte di standardizzazione si aggiungono continuamente, mentre le versioni precedenti vengono riviste; talvolta poi i riferimenti cambiamo nome, per cui anche solo seguire le denominazioni usate diventa particolarmente faticoso; una pagina dove si possono recuperare varie (e di norma piuttosto intricate) informazioni è: Standard IEEE ISO Contenuto POSIX Interfacce di base POSIX.1a a Estensioni a POSIX.1 POSIX Comandi POSIX TR13210 Metodi di test POSIX b Estensioni real-time POSIX.4a c Thread POSIX.4b d Ulteriori estensioni real-time POSIX Interfaccia per il linguaggio ADA POSIX c,1e Sicurezza POSIX f Accesso ai file via rete POSIX Interfaccia per il Fortran-77 POSIX g Socket Tabella 1.3: Elenco dei vari standard POSIX e relative denominazioni. Benché l insieme degli standard POSIX siano basati sui sistemi Unix essi definiscono comunque un interfaccia di programmazione generica e non fanno riferimento ad una implementazione specifica (ad esempio esiste un implementazione di POSIX.1 anche sotto Windows NT). Lo standard principale resta comunque POSIX.1, che continua ad evolversi; la versione più nota, cui gran parte delle implementazioni fanno riferimento, e che costituisce una base per molti altri tentativi di standardizzazione, è stata rilasciata anche come standard internazionale con la sigla ISO/IEC :1996. Linux e le glibc implementano tutte le funzioni definite nello standard POSIX.1, queste ultime forniscono in più alcune ulteriori capacità (per funzioni di pattern matching e per la manipolazione delle regular expression), che vengono usate dalla shell e dai comandi di sistema e che sono definite nello standard POSIX.2. Nelle versioni più recenti del kernel e delle librerie sono inoltre supportate ulteriori funzionalità aggiunte dallo standard POSIX.1c per quanto riguarda i thread (vedi cap.??), e dallo standard POSIX.1b per quanto riguarda i segnali e lo scheduling real-time (sez e sez ), la misura del tempo, i meccanismi di intercomunicazione (sez. 12.4) e l I/O asincrono (sez ) Lo standard X/Open XPG3 Il consorzio X/Open nacque nel 1984 come consorzio di venditori di sistemi Unix per giungere ad un armonizzazione delle varie implementazioni. Per far questo iniziò a pubblicare una serie di documentazioni e specifiche sotto il nome di X/Open Portability Guide (a cui di norma si fa riferimento con l abbreviazione XPGn). Nel 1989 produsse una terza versione di questa guida particolarmente voluminosa (la X/Open Portability Guide, Issue 3 ), contenente un ulteriore standardizzazione dell interfaccia di sistema di Unix, che venne presa come riferimento da vari produttori. Questo standard, detto anche XPG3 dal nome della suddetta guida, è sempre basato sullo standard POSIX.1, ma prevede una serie di funzionalità aggiuntive fra cui le specifiche delle API (Application Programmable Interface) per l interfaccia grafica (X11).