chapitre i : introduction générale · – un mécanisme de protection contre les programmes...
TRANSCRIPT
Atelier Systèmes d’Exploitation
Chapitre I :
Introduction GénéraleAmine DHRAIEF
1ère année Licence LFIG
03/10/17 Atelier S.E 2
Présentation de Linux
03/10/17 Atelier S.E 3
Historique
● Unix est né, en 1969, dans les Bell Laboratories (AT&T)
– Ken Thompson et Dennis Ritchie.
03/10/17 Atelier S.E 4
Historique● En 1974, la version 4 d’Unix est « donnée » à
l’université de Berkeley, Californie, qui commence alors son propre développement du système. C’est le début d’une divergence entre les deux versions d’Unix : AT&T et BSD (Berkeley Software Distribution).
● De 1977 à 1979, Ken Thompson et Dennis Ritchie réécrivent Unix pour le rendre réellement portable. Et en 1980 les premières licences de distribution d’Unix System V d’AT&T sont délivrées aux constructeurs.
03/10/17 Atelier S.E 5
Historique● Linux, système Unix libre sur
plate–forme PC, était au départ un projet de loisirs de Linus Torvalds, étudiant finlandais. – Le 5 octobre 1991, Linus Torvalds
annonça la première version officielle de Linux
● Linux fut inspiré de Minix, un petit système Unix développé par Andrew Tanenbaum
03/10/17 Atelier S.E 6
Définition d'un S.E
Har
dw
are
Sof
war
e
Kernel ModeKernel Mode
User ModeUser ModeInterface prorgamme utilisateur
03/10/17 Atelier S.E 7
Notion de Système d'Exploitation
● Multi-tâche ?
● Pseudo-parallélisme ?
● Temps partagé ?
● Multi-programmation ?
● Multi-utilisateurs ?
03/10/17 Atelier S.E 8
Notion de Système d'Exploitationmulti-tâche (multitasking)
● Selon Silbershatz :
« Time sharing (or multitasking)….»
« In time-sharing systems, the CPU executes multiple jobs by switching among them, but the switches occur so frequently that the users can interact with each program while it is running. »
Source : Operating System Concepts Essentials. Second Edition, 2013.Chapter 1 Introduction, page 20
03/10/17 Atelier S.E 9
Notion de Système d'Exploitationmulti-tâche (multitasking)
● Selon Tannenbaum:
« timesharing, a variant of multiprogramming….»
« In reality, of course, the real CPU switches back and forth from process to process, but to understand the system, it is much easier to think about a collection of processes running in (pseudo) parallel than to try to keep track of how the CPU switches from program to program. This rapid switching back and forth is called multiprogramming, »
Source : MODERN OPERATING SYSTEMS. Fourth Edition, 2014.Chapter 2 Process and Threads, page 86
03/10/17 Atelier S.E 10
Notion de Système d'Exploitation multi-tâche cas d'UNIX
● La plupart des systèmes d'exploitation modernes permettent l'exécution de plusieurs tâches à la fois
– un ordinateur peut, pendant qu'il exécute le programme d'un utilisateur, lire les données d'un disque ou afficher des résultats sur un terminal ou une imprimante.
● On parle de système d'exploitation multi-tâches ou multi-programmé dans ce cas.
03/10/17 Atelier S.E 11
Notion de Système d'Exploitation multi-tâche cas d'UNIX
● La plupart des systèmes d'exploitation multi-tâches sont implémentés sur un ordinateur ayant un seul micro-processeur.
● Celui-ci, à un instant donné, n'exécute réellement qu'un seul programme, mais le système peut le faire passer d'un programme à un autre ceci donne aux utilisateurs l'impression que tous les programmes sont exécutés en même temps.
03/10/17 Atelier S.E 12
Notion de Système d'Exploitation cas d'UNIX
● Unix est un système d’exploitation, constitué– du noyau Unix, – d’un interpréteur de commandes – et d’un grand nombre d’utilitaires.
● Le noyau assure la gestion des ressources physiques (processeur, mémoires, périphériques) et logicielles (processus, fichiers...). – Le noyau est constitué d’un ensemble de procédures et de
fonctions écrites pour l’essentiel en langage C
● Unix est un système multi–utilisateur, temps partagé, multi-tâche
03/10/17 Atelier S.E 13
Notion de Système d'Exploitation cas d'UNIX
● Un système multi-utilisateurs est capable d'exécuter de façon (pseudo-) concurrente et indépendante des applications appartenant à plusieurs utilisateurs.
– Concurrente signifie que les applications peuvent être actives au même moment et se disputer l'accès à différentes ressources comme le processeur, la mémoire, les disques durs…
– Indépendante signifie que chaque application peut réaliser son travail sans se préoccuper de ce que font les applications des autres utilisateurs.
03/10/17 Atelier S.E 14
Notion de Système d'Exploitation cas d'UNIX
• Un système multi-utilisateurs est nécessairement multi-tâches mais la réciproque est fausse : – le système d'exploitation MS-DOS
est mono-utilisateur et mono-tâche ;
– les systèmes MacOS 6.1 et Windows 3.1 sont mono-utilisateurs mais multi-tâches ;
– Unix et Windows NT sont multiutilisateurs.
03/10/17 Atelier S.E 15
Notion de Système d'Exploitation cas d'UNIX
● Comme pour les systèmes multi-tâches, la multi-utilisation est émulée en attribuant des laps de temps à chaque utilisateur.
● Naturellement, le fait de basculer d'une application à l'autre ralentit chacune d'entre elles et affecte le temps de réponse perçu par les utilisateurs.
03/10/17 Atelier S.E 16
Notion de Système d'Exploitation cas d'UNIX
● Lorsqu'ils permettent la multi-utilisation, les systèmes d'exploitation doivent prévoir un certain nombre de mécanismes :
– Un mécanisme d'authentification permettant de vérifier l'identité de l'utilisateur ;
– Un mécanisme de protection contre les programmes utilisateur erronés, qui pourraient bloquer les autres applications en cours d'exécution sur le système, ou mal intentionnés, qui pourraient perturber ou espionner les activités des autres utilisateurs ;
– Un mécanisme de comptabilité pour limiter le volume des ressources allouées à chaque utilisateur.
03/10/17 Atelier S.E 17
Connexion d’un utilisateur
03/10/17 Atelier S.E 18
Connexion d’un utilisateur
● Tout utilisateur est identifié par un nom (login) et ne peut utiliser le système que si son nom a préalablement été défini par l’administrateur du système (ou super–utilisateur), dont le nom est généralement root.
● Ce dernier a tous les droits et aucune restriction d’accès ne lui est applicable.
03/10/17 Atelier S.E 19
Connexion d’un utilisateurConnexion en mode texte
03/10/17 Atelier S.E 20
Connexion d’un utilisateurConnexion en mode graphique
03/10/17 Atelier S.E 21
Connexion d’un utilisateurMot de passe
● Un utilisateur peut à tout moment changer son mot de passe, ou s’en attribuer un par la commande passwd. – Lors du changement, il faut fournir l’ancien mot de
passe
03/10/17 Atelier S.E 22
Connexion d’un utilisateurMot de passe
« La sécurité d'un mot de passe repose sur la force de l'algorithme de chiffrement et sur la taille de l'espace de clés utilisé. La méthode de chiffrement des systèmes UNIX est basée sur l'algorithme NBS DES. Des méthodes plus récentes sont maintenant recommandées (voir ENCRYPT_METHOD). La taille de l'espace de clés dépend de l'aléa du mot de passe utilisé. »
Extrait $man passwd
03/10/17 Atelier S.E 23
Fichier /etc/passwd
● Lors des diverses connexions de l’utilisateur, la lecture du mot de passe se fera sans écho.
● Lorsque le nom et le mot de passe sont corrects, login récupère dans le fichier /etc/passwd toutes les informations utiles pour cet utilisateur.
03/10/17 Atelier S.E 24
Fichier /etc/passwd
03/10/17 Atelier S.E 25
Fichier /etc/passwd● root:x:0:0:root:/root:/bin/bash
● Ce fichier est accessible en lecture à tous les utilisateurs et contient, pour chaque utilisateur, les champs suivants :– nom de connexion (login) de l’utilisateur,– un caractère x (indique qu’un mot de passe existe pour le compte)– le numéro de l’utilisateur (UID = user identifier),– le numéro de groupe (GID = group identifier),– Commentaires : informations complémentaire sur l'utilisateur (num
de téléphone, adresse courriel,...)– le répertoire d’accueil,– programme à lancer
03/10/17 Atelier S.E 26
Fichier /etc/shadow
● Le fichier /etc/shadow contient les mots de passe et l'information sur l'expiration des comptes
03/10/17 Atelier S.E 27
Fichier /etc/shadowamine :$6$VnYAAYRG$pwj1PIa25WRqaoqQcUvr68J/JjnnqG.IL3RiOCc582kcP7Ii54nL.luoZGTt6yuetLzmIoYR.dZvXqWxX/gb00:16686:0:99999:7:::
– Nom d'utilisateur, jusqu'à 8 caractères. Case-sensitive, habituellement uniquement des minuscules. Exactement la même entrée que dans le fichier /etc/passwd.
– Mot de passe, 13 caractères codés. Une entrée nulle (eg. ::) indique qu'un mot de passe n'est pas demandé pour entrer dans le système (une mauvaise idée en général), et une entrée ``*'' (eg. :*:) indique que le compte a été désactivé.
– Le nombre de jours (depuis le 1er Janvier 1970) depuis le dernier changement du mot de passe.
– Le nombre de jours avant que le mot de passe ne puisse être changé (un 0 indique qu'il peut être changé à n'importe quel moment).
– Le nombre de jours après lesquels le mot de passe doit être changé (99999 indique que l'utilisateur peut garder son mot de passe inchangé pendant beaucoup, beaucoup d'années)
– Le nombre de jours pour avertir l'utilisateur qu'un mot de passe ne va plus être valable (7 pour une semaine entière)
– Le nombre de jours avant de désactiver le compte après expiration du mot de passe
– Le nombre de jours depuis le 1er Janvier 1970 pendant lesquels un compte a été désactivé
– Un champ réservé pour une utilisation future possible
03/10/17 Atelier S.E 28
Algorithme de hashage utilisé dans /etc/shadow
● Format du mot de passe $ID$Salage$Hash– ID: l’algorithme utilisé :
● $1$ is MD5● $2a$ is Blowfish● $2y$ is Blowfish● $5$ is SHA-256● $6$ is SHA-512
– Salage : dynamique/statique– Hash : empreinte du mot de passe
03/10/17 Atelier S.E 29
Principe de hashage
03/10/17 Atelier S.E 30
Les shellsLes commandes & les terminaux
03/10/17 Atelier S.E 31
Les shells
● Un script est fichier contenant une série d’ordres que l’on va soumettre à un programme externe pour qu’il les exécute.– Ce programme est appelé interpréteur de
commandes.
ÉcrisLis
ÉcrisLis…..
Interpréteur de commandeScript Résultat
03/10/17 Atelier S.E 32
Les shellslangage interprété
● Il existe de nombreux interpréteurs de commandes. – Naturellement, le shell en fait partie, tout comme
certains outils tels que Sed et Awk, ainsi que d’autres langages tels que Perl, Python, Tcl/Tk, Ruby, etc.
● Ces langages sont dits interprétés, par opposition aux langages compilés (comme C, C++, Fortran, Ada, etc.).
03/10/17 Atelier S.E 33
Les langages compilés● Un code source écrit en langage compilé doit être
traduit en instructions de code machine compréhensibles pour le processeur.
– Cette étape de compilation nécessite plusieurs outils et peut parfois s’avérer longue.
ÉcrisLis
ÉcrisLis…..
CompilationCode source Fichier binaire Résultat
03/10/17 Atelier S.E 34
Les shellslangages interprétés vs compilés
Le code compilé étant directement compris par le processeur du système, son exécution est très rapide
Un script doit être interprété
dynamiquement, ce qui ralentit sensiblement
l’exécution
03/10/17 Atelier S.E 35
Les shellslangages interprétés vs compilés
Le fichier exécutable issu d’une compilation est souvent volumineux et n’est utilisable que sur un seul type de processeur et un seul système d’exploitation.
À l’inverse, un fichier script est généralement assez réduit et
directement portable sur d’autres processeurs ou
d’autres systèmes d’exploitation (pour peu que l’interpréteur de commandes
correspondant soit disponible)
03/10/17 Atelier S.E 36
Les shellslangages interprétés vs compilés
Un fichier compilé est incompréhensible par un lecteur humain. Il n’est pas « possible » d’en retrouver le code source. Cela peut garantir le secret commercial d’un logiciel
Inversement, un fichier script est directement lisible et
modifiable, et peut contenir sa propre documentation
sous forme de commentaires, ce qui est
intéressant dans le cadre des logiciels libres.
03/10/17 Atelier S.E 37
Les shells
● Le shell fait partie intégrante d’Unix depuis les débuts de celui-ci en 1971.
● Le shell est avant tout un interpréteur de commandes, chargé de lire les ordres que l’utilisateur saisit au clavier, de les analyser, et d’exécuter les commandes correspondantes.
03/10/17 Atelier S.E 38
Les shellsBourne Shell
● Le premier shell fut écrit par Steve Bourne et le fichier exécutable correspondant était traditionnellement /bin/sh .
– Il permettait d’écrire de véritables scripts complets, avec des structures de contrôle performantes.
– Toutefois, son utilisation quotidienne de manière interactive péchait quelque peu par manque d’ergonomie.
03/10/17 Atelier S.E 39
Les shellsC Shell
● Un nouveau shell – dit shell C – fut donc mis au point par William Joy à l’université de Berkeley. Cet outil fut officiellement introduit dans certaines distributions Unix en 1978.
● Le fichier exécutable était /bin/csh .
● Le shell C fut doté d’un langage de programmation ressemblant quelque peu au langage C, mais dont l’implémentation était fortement boguée. – En dépit des corrections qui y furent apportées, le comportement des
scripts pour shell C n’était pas satisfaisant.
03/10/17 Atelier S.E 40
Les shellsKorn Shell
● En 1983, David G. Korn, travaillant aux laboratoires AT&T Bell, développa un nouveau shell, nommé Korn Shell, dont le but était de réunir à la fois les qualités du shell C et du shell Bourne.
● Le fichier exécutable était /bin/ksh .
03/10/17 Atelier S.E 41
Les shellsStandard POSIX
● À la fin des années 1980, il existait une pléthore de systèmes compatibles Unix – ou prétendument compatibles Unix – qui implémentaient chacun de nouvelles fonctionnalités par rapport au système Unix original.
● Chaque fabricant de matériel, chaque éditeur de logiciels désirait disposer de sa propre version compatible Unix, et la situation était devenue catastrophique en ce qui concerne la portabilité des applications.
03/10/17 Atelier S.E 42
Les shellsStandard POSIX
● Même les commandes shell simples pouvaient disposer de variantes différentes sur chaque système. Il fut donc nécessaire d’uniformiser le paysage proposé par toutes ces versions d’Unix.
● Une norme fut proposée par l’IEEE : POSIX.
● Elle décrivait l’interface entre le cœur du système d’exploitation (le noyau) et les applications, ainsi que le comportement d’un certain nombre d’outils système dont le shell
03/10/17 Atelier S.E 43
Premier script shell
03/10/17 Atelier S.E 44
Exécution d’un scriptInvocation de l’interpréteur
03/10/17 Atelier S.E 45
Exécution d’un scriptInvocation de l’interpréteur
● Remarquez que le suffixe .sh ajouté à la fin du nom du script n’a aucune importance ; il ne s’agit que d’une information pour l’utilisateur.
● Le système Unix ne tient aucun compte des suffixes éventuels des noms de fichiers.
● Par exemple, renommons-le et réessayons :
03/10/17 Atelier S.E 46
Exécution d’un scriptAppel direct
● Le shell ne reconnaît pas essai comme une commande
03/10/17 Atelier S.E 47
Exécution d’un scriptAppel direct
● Lorsque nous invoquons une commande Unix (par exemple, echo ), le système devra trouver un fichier exécutable de ce nom ( /bin/echo en l’occurrence).
● Mais il est impossible de parcourir tous les répertoires de tous les disques pour rechercher ce fichier, le temps de réponse serait horriblement long !
03/10/17 Atelier S.E 48
Exécution d’un scriptAppel direct
● Pour améliorer les performances, le système Unix ne recherche les fichiers implémentant les commandes que dans un nombre restreint de répertoires.
● Ceux-ci sont énumérés dans la variable d’environnement PATH , que nous pouvons consulter.
03/10/17 Atelier S.E 49
Exécution d’un scriptAppel direct
● Le script ne s’exécute pas plus qu’avant, mais le message d’erreur a changé.
● Ceci est dû aux permissions accordées pour ce fichier, et que l’on peut observer avec l’option -l de ls
● La première colonne décrit le type de fichier et les permissions concernant sa manipulation
03/10/17 Atelier S.E 50
Exécution d’un scriptAppel direct
● Le premier tiret - correspond à un fichier normal ( d pour un répertoire, l pour un lien symbolique, etc.).
● Les trois lettres suivantes indiquent que le propriétaire amine du fichier a les droits de lecture ( r ) et d’écriture ( w ) sur son fichier, mais l’absence de lettre x , remplacée ici par un tiret, signifie que le propriétaire ne peut pas exécuter ce fichier. C’est justement notre problème.
● Les trois lettres rw- suivantes décrivent les droits fournis aux autres utilisateurs appartenant au même groupe que le fichier ( users ).
● Enfin les trois dernières lettres indiquent les permissions accordées à tous les autres utilisateurs du système ( r-- lecture seulement).
03/10/17 Atelier S.E 51
Exécution d’un scriptAppel direct
● Le fichier n’étant pas exécutable, il est impossible de le lancer. Pour modifier les permissions d’un fichier, il faut utiliser la commande chmod
03/10/17 Atelier S.E 52
Exécution d’un scriptLigne shebang
● Nous avons créé le fichier essai contenant une seule ligne affichant un message ; nous avons rendu le fichier exécutable avec chmod ; puis nous l’avons lancé en utilisant la notation ./essai .
● Nous savons que ce fichier doit être interprété par un shell, c’est-à-dire qu’un shell disponible sur le système ( sh , bash , ksh ...) doit lire le script et traduire son contenu ligne à ligne.
03/10/17 Atelier S.E 53
Exécution d’un scriptLigne shebang
● Mais comment le système sait-il que ce fichier doit être interprété par un shell ? Comment sait-il qu’il s’agit d’un script shell et non d’un script Sed, Awk, Perl, ou autre ? Comment se fait l’association entre notre fichier et le shell du système ?
● En réalité, nous n’avons rien précisé, et si le script fonctionne quand même, c’est uniquement grâce à un comportement par défaut dans le cas où cette information est absente
03/10/17 Atelier S.E 54
Exécution d’un scriptLigne shebang
● On précise l’interpréteur à employer, on utilise le principe de la ligne shebang (contraction de shell et de bang – point d’exclamation en anglais).
● Lorsque le noyau s’aperçoit que les deux premiers caractères du fichier sont #! , il considère que tout le reste de la ligne représente le nom de l’interpréteur à utiliser.
● Et si l’on demande à exécuter le fichier mon_script.sh écrit ainsi :
03/10/17 Atelier S.E 55
Exécution d’un scriptLigne shebang
● le système d’exploitation traduira l’invocation :
$ ./mon_script.sh
En
$ /bin/bash ./mon_script.sh
03/10/17 Atelier S.E 56
The END