chapitre i : introduction générale · – un mécanisme de protection contre les programmes...

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


Historique

● Unix est né, en 1969, dans les Bell Laboratories (AT&T)

– Ken Thompson et Dennis Ritchie.


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.


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


Définition d'un S.E

Har

dw

are

Sof

war

e

Kernel ModeKernel Mode

User ModeUser ModeInterface prorgamme utilisateur


Notion de Système d'Exploitation

● Multi-tâche ?

● Pseudo-parallélisme ?

● Temps partagé ?

● Multi-programmation ?

● Multi-utilisateurs ?


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


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


● 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


• 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


● 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


● 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


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


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


● 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


● 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


● 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


● 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


● 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


● 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


● 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


● 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

chapitre i : introduction générale · – un mécanisme de protection contre les programmes...

Documents