Techniquement, le noyau LINUX a les caractéristiques suivantes:
Comme tout logiciel d'une certaine taille, Linux est d'une grande complexité. Cette complexité implique un grand nombre d'erreurs, d'anomalies et de dysfonctionnement possibles. En effet, pour qu'un système informatique fonctionne correctement, il faut tout prévoir pour donner une action appropriée à tous les événements possibles. Cela n'est pas humainement réalisable quand le système devient trop complexe. Pour résoudre ce problème, il est courant de subdiviser le système en composants indépendants, dont le mauvais fonctionnement potentiel ne peut perturber que partiellement les autres parties du système. Il va de soi que, lorsqu'un composant se plante, ceux qui l'utilisent risquent fort de se retrouver dans un état d'erreur assez difficile à gérer. Cela peut souvent provoquer leur propre perte. Par conséquent, plus un composant est utilisé, plus il doit être fiable. Or il est un composant à la base de tout dans Linux : le noyau (``kernel'' en anglais). C'est le coeur du système, et en fait c'est précisément le système Linux. Heureusement, ce composant est d'une très, très grande fiabilité, et il n'est pas rare de voir un système Linux fonctionner plusieurs mois ou années sur des serveurs.
Lorsque l'on parle de Linux en temps que système d'exploitation, on désigne le noyau Linux accompagné d'outils permettant d'utiliser ce dernier. Ces outils sont en grande partie issus du projet GNU. Tous ces outils mis bouts à bouts représentent bien plus que le noyau Linux lui même.
C'est pour cette raison qu'il est plus correct de parler d'un système GNU/Linux, bien qu'il soit courant de ne citer que le nom du noyau.
Le noyau Unix joue le rôle d'intermédiaire entre vos programmes et votre matériel. Premièrement, il gère la mémoire pour tous les programmes en cours d'exécution (processus), et s'assure qu'ils occupent tous une part équitable (ou non) du temps processeur. En plus, il fournit une interface (simple à utiliser) aux programmes pour communiquer avec votre matériel (appels système).
Géneralement, le noyau est constitué d'un seul fichier binaire comportant l'ensemble des fonctions. Ce fichier binaire est issu de la compilation du noyau. On parle alors d'un noyau monolythique. Tout changement du noyau nécessite alors une nouvelle compilation de ce dernier et un redémarrage du système. Il est possible d'obtenir plus de souplesse en utilisant le mécanisme des modules. Les modules sont des parties du noyau (pilotes de périphériques généralement) qui ne sont pas compilées dans celui-ci. On peut les compiler séparément, les insérer et les retirer du noyau à n'importe quel moment. En raison de cette souplesse, c'est devenu la méthode préférée pour coder certaines fonctionnalités du noyau. Bon nombre de pilotes de périphériques tels que PCMCIA et les gestionnaires de cartouches QIC-80/40 sont des modules chargeables.
Le noyau gère quasiment tout (mémoire, disques, systèmes de fichiers, réseau, clavier, droits des utilisateurs, etc.), mais il n'est pas exploitable tel quel. Il n'est par exemple pas capable d'offrir une interface utilisateur permettant de lui donner les commandes qu'il doit exécuter.
Ces opérations sont du ressort d'autres modules développés par la Free Software Foundation. Parmi ces modules, on trouve le ``shell'' (ce qui signifie grosso modo ``environnement utilisateur''). Le shell est capable de lire des commandes saisies au clavier, de les exécuter et d'afficher leurs résultats à l'écran. En général, les programmes capables de réaliser ces opérations sont appelés des interpréteurs de commandes. Mais le shell est bien plus que cela, car il peut être programmé, et il peut gérer les processus (en arrêter un, en lancer un autre, etc.). En fait, les commandes que le shell peut exécuter sont en nombre très réduit. La plupart des commandes sont tout simplement d'autres programmes (voir figure 2.1).
Les programmes que l'on peut utiliser dans le shell sont des programmes dits ``en ligne de commande'', parce qu'ils sont propres à être utilisés dans les lignes de commandes que l'on saisit au clavier dans le shell2.1. Ces programmes sont, encore une fois, développés soit par la Free Software Foundation, soit par des bénévoles, toujours sous la licence GNU. Toutes ces commandes sont des commandes compatibles Unix. Ces commandes sont absolument essentielles pour pouvoir utiliser le système, mais elles sont assez rébarbatives et peu d'utilisateurs acceptent de s'en contenter2.2.
C'est pour cela qu'une couche graphique a été développée, pour introduire une interface graphique plus conviviale : XWindow. Encore une fois, cette couche logicielle est constituée de plusieurs composants dont les plus importants sont :
En résumé, un système GNU/Linux est structuré de la manière suivante
(voir figure 2.3, page
) :
Il n'est pas évident d'établir un parallèle avec MS Windows, puisque ce système est réellement monolithique2.4. Cependant, on peut considérer que le noyau Linux correspond aux modules KERNEL ou IO.SYS de Windows, que le shell correspond aux interpréteurs de commandes COMMAND.COM ou CMD.EXE, que les programmes en ligne de commande correspondent aux programmes DOS ou console classiques (xcopy, fdisk, format...), que le serveur X correspond au couple pilote de carte graphique (GDI), que le gestionnaire de fenêtre correspond au module USER, et le gestionnaire de bureau à l'explorateur, les fonctionnalités d'OLE et aux programmes fournis avec Windows.
La différence essentielle vient du fait que le shell est à peine programmable sous Windows, que les commandes DOS ont tendance à accéder aux ressources de la machine directement, sans passer par le noyau, que le driver de carte graphique, la GDI et le module USER sont tous intégrés dans le système au lieu d'en être séparés (ce qui multiplie les chances de crash du système complet), et que la plupart des applications Windows ne peuvent fonctionner que dans l'environnement graphique. Elles sont donc entraînées par le système lorsque les modules graphiques de Windows plantent (il semble d'ailleurs peu probable qu'un processus DOS survivre à un crash de l'interface graphique de Windows).
Un processus est un programme en exécution. Pour tout travail, Linux utilise des processus, le noyau n'étant là que pour gérer ces processus et leur permettre d'interagir avec le monde extérieur. Dès son lancement, le noyau lance un premier processus (init) qui est l'ancêtre de tous les processus lancés sur le système par la suite (appels systèmes fork et exec). Le système maintient une table des processus en fonctionnement avec tous les attributs qui les caractérisent.
Toute l'information maintenue par le système est enregistrée dans des fichiers organisés dans une structure hiérarchique de répertoires. Comme pour les processus, chaque fichier possède des attributs qui peuvent être modifiés par les utilisateurs par l'intermédiaire des commandes du système.
Linux étant un système multi-utilisateurs, la plupart des attributs des processus et des fichiers déterminent les droits des utilisateurs à les utiliser ou à les modifier. Ces droits sont associés à une identification de chaque utilisateur pour le système.
Les différents types de fichiers sous Linux sont :
).
Il est nécessaire de définir un peu les termes qui vont être utilisés dans cette section, car les systèmes de fichiers Unix sont très différents des systèmes de fichiers du DOS et de Windows. La connaissance de ce vocabulaire est nécessaire pour la compréhension de la structure du système de fichiers de Linux.
Comme la plupart des systèmes de fichiers, les systèmes de fichiers Unix sont structurés hiérarchiquement, et regroupent les fichiers dans des répertoires. Il existe un répertoire racine, d'où débutent tous les chemins possibles dans le système de fichiers. Chaque fichier ou répertoire a un nom qui permet aux utilisateurs du système de l'identifier. Le seul répertoire qui n'a pas de nom est le répertoire racine.
Les systèmes de fichiers Unix n'ont pas les mêmes limitations sur les noms que les systèmes de fichiers FAT et FAT32 utilisés par Windows. Les noms des fichiers et des répertoires peuvent être très longs (jusqu'à 256 caractères par nom), et ils prennent en compte la casse des lettres2.7.
Les fichiers contiennent des données au sens large, ce peut être des
données (texte, image, film, son, paramètres de programmes ou du
système... ), ou des programmes. En fait, Unix (et donc Linux)
manipule généralement l'ensemble de ses composants sous la forme de
fichiers. Les répertoires sont eux-mêmes des fichiers spéciaux,
interprétés par le système différemment des autres fichiers. Nous
verrons plus loin (voir 3.2.3, page
) que les périphériques du système sont,
eux aussi, représentés sous la forme de fichiers. Cette orientation
``fichier'' systématique facilite grandement l'utilisation avancée
d'un système Unix, mais peut dérouter les habitués des systèmes
Windows.
Les noms de répertoires et de fichiers sont séparés par un caractère spécial. Ce caractère est traditionnellement, sous Unix, la barre oblique de division (nommée ``slash'' en anglais) : ``/''. Comme le répertoire racine n'a pas de nom, il peut être accédé directement avec un simple ``slash''.
La qualification complète d'un fichier se fait en précisant le nom du répertoire à chaque niveau et en séparant par des slashes chacun de ces noms. Cette qualification porte le nom de ``chemin'' d'accès (``path'' en anglais). L'exemple suivant vous montre l'allure d'un chemin d'accès typique sous Unix :
cd /usr/src rm linux mkdir linux-2.4.17 ln -s linux-2.4.17 linux tar xvfz linux-2.4.17.tar.gz
Les utilisateurs du DOS et de Windows prendront garde ici au fait que Microsoft a préféré la barre oblique inverse (nommée ``backslash'' en anglais) ``backslash'', rendant ainsi tous ses systèmes incompatibles avec les systèmes Unix, et générant ainsi beaucoup de problèmes supplémentaires là où il n'était pas nécessaire d'en avoir2.8.
Les utilisateurs du DOS et de Windows constateront ici que les chemins
d'accès Unix ne comportent pas de spécification de lecteurs. Les
systèmes de fichiers Unix sont dits mono-tête, ce qui signifie qu'ils
n'ont qu'un seul point de départ : le répertoire racine
(voir figure 2.6, page
). Les systèmes Microsoft sont multi-têtes, puisqu'ils
ont un point de départ par lecteur et par partition (voir figure 2.5, page
).
Le fait de n'avoir qu'un seul point de départ est beaucoup plus simple, et permet, encore une fois, d'écrire les programmes plus simplement et donc avec moins de bogues potentiels. Les habitués du DOS ne manquerons pas de se poser la question :
``Mais alors, comment spécifie-t-on le lecteur que l'on veut utiliser ?''
Cette question a deux réponses :
make dep make clean make bzImage
Cette solution permet d'accéder à tous les systèmes de fichiers de la même manière, à partir d'un seul répertoire racine, que ces systèmes de fichiers soient EXT2, FAT, ISO9660, NTFS ou Amiga... En pratique, c'est nettement plus simple.
On prendra garde à toujours démonter les systèmes de fichiers pour les lecteurs amovibles. Linux utilise en effet des zones de la mémoire que l'on appelle les tampons (``buffers'' en anglais), pour y stocker des données des systèmes de fichiers montés, et il n'écrit ces données que lorsque c'est nécessaire. Ce mécanisme permet d'accélérer les lectures et les écritures sur les disques, mais a l'inconvénient de nécessiter une requête de vidange des tampons (opération que l'on appelle ``sync'') avant de retirer le lecteur ou avant d'éteindre le système. Si on ne le fait pas, des données seront certainement perdues. Le système effectue le sync lorsqu'il s'arrête (par l'une des commandes halt, shutdown ou reboot), mais il ne le fait pas si on coupe le courant brutalement. C'est pour cela qu'il faut toujours arrêter le système proprement. De manière similaire, Linux empêche l'éjection des CD-ROM tant qu'ils sont montés. En revanche, il ne peut rien faire pour les lecteurs de disquettes, c'est à l'utilisateur de prendre garde à les démonter avant de retirer la disquette.
Deux derniers points auxquels les utilisateurs de DOS et Windows devront faire attention :
Linux est un système multi-utilisateur. Cela signifie que plusieurs personnes peuvent utiliser l'ordinateur simultanément (et pas uniquement les unes à la suite des autres), et que le système se charge de faire respecter la loi entre elles. Les ressources de la machine sont ainsi partagées équitablement, tant au niveau de la puissance de calcul qu'au niveau de la mémoire, du disque, des imprimantes...
Évidemment, une question se pose : comment plusieurs utilisateurs peuvent-ils se partager le clavier et l'écran ? La réponse est simple : en pratique, ils ne le peuvent pas. Par conséquent, il n'y a que trois solutions possibles :
Pour être multi-utilisateur, le système doit satisfaire certains critères :
Le multitâche est assuré au niveau du noyau. Chaque programme en cours d'exécution (on les appelle ``processus'') fonctionne dans sa propre zone de mémoire, qui est complètement contrôlée par le noyau. Les ressources du processeur sont partagées entre les processus, et il est impossible à l'un d'entre eux de monopoliser la mémoire, le disque ou quoi que ce soit. Les processus doivent toujours passer par le noyau pour effectuer une opération, ce qui permet un contrôle absolu.
La fiabilité est également assurée au niveau du noyau. Les zones de mémoire utilisées par chaque processus (encore appelées ``espaces d'adressage'') sont bien distinctes et bien identifiées par le noyau. Cela implique qu'il est impossible à un processus de perturber le fonctionnement d'un autre processus. Ainsi, si un processus fait une faute, il est purement et simplement terminé par le noyau. Cela est sans appel : le noyau est le seul maître à bord.
Enfin, la sécurité est assurée par le noyau et par le système de fichiers.
Au niveau du système de fichiers, la sécurité est assurée par le stockage d'informations additionnelles pour chaque fichier ou répertoire. Ces informations permettent de connaître :
).
Au niveau du noyau, chaque utilisateur est identifié de manière unique par un numéro dans le système : son uid (User IDentifier). Ce numéro est utilisé pour vérifier les droits de l'utilisateur, ou, autrement dit, ce qu'il peut faire. Les droits des utilisateurs comprennent la possibilité de lire ou écrire un fichier, d'accéder ou non à une ressource ou d'exécuter un programme.
Il est possible de définir plusieurs utilisateurs ayant le même uid. Ceux-ci auront les mêmes droits d'accès, mais pourront bénéficier de mots de passe, de répertoires de départ ou d'interpréteur de commandes différents.
Il est également possible de créer un ou plusieurs ``groupes'' d'utilisateurs, et de leur donner des droits particuliers. Chaque groupe est aussi identifié par un numéro : gid (Group IDentifier). Tous les utilisateurs qui font partie de ce groupe recevront les droits du groupe. Ainsi, des classes d'utilisateurs peuvent être facilement définies, et ces classes peuvent se voir attribuer un peu plus de privilèges que les utilisateurs normaux selon les nécessités. Il existe toutefois un utilisateur spécial, qui a tous les droits : l'administrateur du système (``root'' en anglais). Aucune restriction ne s'applique à cet utilisateur, car il doit être capable de gérer le système, l'installer, l'arrêter, le mettre à jour si nécessaire, et de définir les utilisateurs et leurs droits.
Il existe plusieurs façon de gérer les utilisateurs et les groupes :
L'identification par fichier locaux se base principalement sur deux fichiers :
Par exemple, un utilisateur est représenté par une ligne du type :
[root@pc1 linux]# lsmod Module Size Used by es1371 26528 0 ac97_codec 9248 0 [es1371] soundcore 3440 4 [es1371] af_packet 11984 0 (autoclean) nls_iso8859-15 3392 3 (autoclean) nls_cp850 3632 3 (autoclean) vfat 9744 3 (autoclean) fat 30240 0 (autoclean) [vfat] floppy 46608 1 (autoclean) nls_iso8859-1 2880 1 (autoclean) isofs 17104 1 (autoclean)
Cette ligne comporte les champs suivants séparés par le caractère `:' :
/etc/group est un fichier ASCII qui définit les groupes auxquels appartient chaque utilisateur. Il y a une ligne par groupe, et chaque ligne a le format :
[remi@pc1 remi]$ ls C/ GNUstep/ Lettres/ Nautilus/ remi.leblond.free.fr/ CNAM/ guide.zip Mail/ nohup.out RPMS/ Desktop/ Guide.zip mbox nsmail/ sciemat/ email/ IMAGES/ memoire/ portable/ src/ emap_264.exe kvirc-2.0.0/ MIDI/ prog/ tmp/
Par exemple :
[remi@pc1 remi]$ ls guide.zip guide.zip [remi@pc1 remi]$ ls email/ photo1.jpg photo3.jpg photo5.jpg photo7.jpg photo9.jpg photo2.jpg photo4.jpg photo6.jpg photo8.jpg
Une ligne de ce fichier comporte les champs suivants, séparés par des caractères `:' :
Lors de la connexion, un utilisateur est associé à tous les groupes dans lesquels il est inscrit. Il peut le vérifier à l'aide de la commande id, ou groups.
[remi@pc1 remi]$ ls e* emap_264.exe email: photo1.jpg photo3.jpg photo5.jpg photo7.jpg photo9.jpg photo2.jpg photo4.jpg photo6.jpg photo8.jpg
Nous voyons ici que le groupe principal de l'utilisateur ``remi'' est le groupe ``remi'' et qu'il fait également partie des groupes ``users'', ``cvs'' et ``compta''.
Les droits d'accès peuvent être décomposés en droits élémentaires
définissant les droits d'accès aux fichiers. Ces droits élémentaires
sont décrits plus loin (voir tableau 2.1, page
et
voir tableau 2.2, page
).
Le droit de lecture correspond à la possibilité d'ouvrir et de consulter un fichier, ou de lister le contenu d'un répertoire. Le droit d'écriture correspond à la possibilité de modifier un fichier, ou de créer ou supprimer un fichier d'un répertoire. Enfin, le droit d'exécution correspond à la possibilité d'exécuter un fichier contenant un programme, ou d'entrer dans un répertoire. On notera par exemple qu'il est possible d'obtenir la liste des fichiers d'un répertoire sans pouvoir s'y déplacer, ou encore de modifier un fichier sans pouvoir le lire. On prendra garde également que le fait d'avoir le droit d'écriture sur un fichier ne donne pas le droit de le supprimer (cependant, on peut le vider !). Pour cela, il faut avoir le droit d'écriture sur le répertoire contenant ce fichier. Comme on le voit, les droits d'accès aux fichiers et aux répertoires sont très souples.
Ces droits sont attribués séparément pour le propriétaire, le groupe et les autres utilisateurs (c'est-à-dire les utilisateurs qui ne font pas partie du groupe auquel appartient le fichier). Il est donc possible de donner par exemple tous les droits au propriétaire d'un fichier, et seulement le droit de lecture aux autres utilisateurs. Cette configuration est celle qui est choisie par défaut lors de la création d'un fichier, elle assure que seul le propriétaire peut modifier ou exécuter ce fichier, tout en laissant la possibilité aux autres de le lire. Ce choix privilégie la sécurité des données de chacun en laissant le maximum de liberté aux autres. Si plusieurs personnes doivent travailler sur les mêmes fichiers, il suffit de les regrouper dans un groupe, de donner les fichiers sur lesquels ils doivent travailler à ce groupe, et de donner les droits d'écriture aux membres de ce groupe sur ces fichiers.
La sécurité du système est transitive, cela signifie que tout programme lancé par un utilisateur s'exécute en son nom et reçoit donc les droits de cet utilisateur. Le processus correspondant se voit donc attribuer les mêmes restrictions que l'utilisateur qui l'a lancé. Il dispose également des droits du groupe auquel le fichier du programme appartient. Il existe toutefois quelques exceptions à cette règle, pour les programmes dont le comportement est bien connu et qu'il est impossible de détourner de leur fonction initiale. C'est notamment le cas de quelques commandes systèmes (comme passwd, qui permet de changer de mot de passe), qui peuvent être lancées par les utilisateurs et qui s'exécutent toutefois au nom du système (dans le compte root). Il est donc impossible à un utilisateur de violer les règles de sécurité du système. Pour parvenir à ce comportement, il faut utiliser des attributs spéciaux sur les fichiers de ces programmes.
Le premier attribut spécial est le bit ``setuid'' (qui est l'abréviation de l'anglais ``SET User IDentifier''. Il ne peut être placé qu'au niveau des droits du propriétaire sur le fichier. Il permet d'indiquer que le fichier est exécutable, et que lorsque le programme qu'il contient est lancé par un utilisateur, le processus correspondant s'exécute avec les droits du propriétaire du fichier et non pas avec ceux de l'utilisateur qui l'a lancé. Cependant, le système conserve tout de même le numéro de l'utilisateur réel qui a lancé le processus, ce qui fait que le programme peut savoir par qui il a été lancé et au nom de qui il s'exécute. Un processus dispose donc toujours de deux numéros d'utilisateur :
Le bit setuid permet donc simplement d'affecter le numéro du propriétaire du fichier au numéro d'utilisateur effectif du processus lorsqu'il est lancé. Le fait de conserver le numéro de l'utilisateur réel permet au programme de réaliser des vérifications de sécurité additionnelles. Par exemple, la commande passwd, qui permet de changer le mot de passe d'un utilisateur, a besoin des droits de l'utilisateur root pour enregistrer le nouveau mot de passe. Il dispose donc du bit setuid pour que tous les utilisateurs puissent l'utiliser. Cependant, même s'il s'exécute au nom de l'utilisateur root, il ne doit pas permettre à n'importe qui de changer le mot de passe des autres utilisateurs : seul l'utilisateur root a le droit de faire cette opération. Il utilise donc le numéro de l'utilisateur réel qui a lancé la commande pour savoir si c'est bien l'utilisateur root qui l'a lancé.
Le bit setuid est l'attribut le plus couramment utilisé, essentiellement pour certaines commandes systèmes. Il est représenté par la lettre 's' (comme ``Setuid''), et il remplace le droit d'exécution ('x') des fichiers pour le propriétaire des fichiers (rappelons que le bit setuid implique que le fichier est exécutable). Il n'a aucune signification pour les répertoires.
Le deuxième attribut spécial est le bit ``setgid'' (qui est l'abréviation de l'anglais ``SET Group IDentifier''). Ce bit fonctionne un peu de la même manière que le bit setuid, à ceci près qu'il fixe le numéro de groupe effectif du processus lancé à celui de son fichier exécutable. Cet attribut est également représenté par la lettre 's', et remplace le droit d'exécution ('x') pour les utilisateurs du groupe auquel appartient le fichier exécutable. Contrairement au bit setuid cependant, il a une signification pour les répertoires. Un répertoire disposant du bit setgid permet de faire en sorte que tous les fichiers qui sont créés dans ce répertoire se voient automatiquement attribués le même groupe que le répertoire. Ce bit est relativement peu utilisé.
Enfin, le troisième et dernier attribut spécial est le bit ``sticky''. Cet attribut remplace l'attribut exécutable pour les autres utilisateurs que le propriétaire du fichier ou du répertoire et les membres du groupe auquel il appartient. Contrairement aux bits setuid et setgid, il est représenté par la lettre 't' (pour ``sTickky''). Sa signification est assez spéciale : elle permet de faire en sorte que les programmes restent chargés en mémoire après leur terminaison, ce qui permet de les relancer plus rapidement. Afin de ne pas consommer la mémoire de manière permanente, le code du programme est placé automatiquement dans le swap s'il n'est toujours pas relancé après un certain temps, mais même dans ce cas, tous les calculs de chargement sont déjà effectués. Le lancement des programmes marqués de ce bit sera donc toujours accéléré. Sachez cependant ne pas abuser du bit sticky car la mémoire (même virtuelle) est encore une ressource rare.
Pour les répertoires, sa signification est totalement différente : elle permet de restreindre les droits des utilisateurs sur les répertoires ayant ce bit positionné. Ce bit fait en sorte que même si un utilisateur dispose des droits d'écriture sur le répertoire, il ne peut pas supprimer tous les fichiers de ce répertoire. Les seuls fichiers qu'il est autorisé à supprimer sont ses propres fichiers. Bien entendu, il est toujours possible d'ajouter des fichiers dans le répertoire en question.
En résumé, on a donc deux symboles supplémentaires, `s' et `t', pouvant prendre la place du `x' dans la liste des droits. Ces symboles signifient :
Lorqu'un utilisateur désire se connecter à un système Linux, le système lui présente une mire de connexion lui demandant de décliner son identité. L'utilisateur entre alors son nom de connexion (appellé communément ``login'').
Le système recherche alors dans le fichier passwd s'il trouve une entrée correspondant au login saisi par l'utilisateur. Si ce n'est pas le cas, il retourne une erreur, sinon, il demande éventuellement2.12 la saisie d'un mot de passe.
Nous avons vu que, pour des raisons évidentes de sécurité, le mot de passe ne figure pas en clair dans fichier passwd, qui ne contenient qu'un mot de passe crypté. Le cryptage se fait à l'aide de la fonction de cryptage à sens unique crypt. Cette fonction permet de crypter une chaîne de caractère pour obtenir une autre chaîne à partir de laquelle il est impossible de retrouver la chaîne initiale.
Le système crypte donc le mot de passe saisi par l'utilisateur et compare la chaîne otenue avec celle qui est contenue dans le fichier passwd. Si les deux chaînes correspondent, c'est que le mot de passe est correct, sion, la connexion est refusée.
Lors de l'établissement de la connexion, l'utilisateur est placé dans son répertoire de base et le programme de base est lancé. La session de l'utilisateur se terminera avec ce dernier.
Les alias permettent à chaque utilisateur de définir ses propres commandes
[remi@pc1 essai]$ ls
bilan1999 bilan2001 prévision2000 prévision2002
bilan2000 prévision1999 prévision2001
[remi@pc1 essai]$ ls bilan*
bilan1999 bilan2000 bilan2001
[remi@pc1 essai]$ ls *2001
bilan2001 prévision2001
[remi@pc1 essai]$ ls bilan{1999,2001}
bilan1999 bilan2001
[remi@pc1 essai]$ ls prévision200[12]
prévision2001 prévision2002
[remi@pc1 essai]$ ls bilan200?
bilan2000 bilan2001
[remi@pc1 essai]$ ls prévision200[0-2]
prévision2000 prévision2001 prévision2002
Utilisée seule, la commande alias permet de lister les alias définis pour l'utilisateur courant.
[remi@pc1 remi]$ ls -l total 2196 drwxrwxr-x 2 remi remi 4096 fév 24 23:42 aide/ ... drwx------ 2 remi remi 4096 fév 20 22:55 tmp/
La commande unalias permet de supprimer un alias.
bash$ stat file1
File: "file1"
Size: 3562 Filetype: Regular File
Mode: (0777/-rwxrwxrwx) Uid: ( 500/ sandra) Gid: ( 500/ sandra)
Device: 8,0 Inode: 2043 Links: 1
Access: Wed Nov 18 18:52:42 1997(00000.00:26:18)
Modify: Wed Nov 18 18:52:42 1997(00000.00:26:18)
Change: Wed Nov 18 18:52:59 1997(00000.00:26:01)
Lorsque l'on utilise le shell bash, ce qui correspond à la plupart des cas, l'environnement utilisateur est défini dans les deux fichiers suivants :
). Par convention, ce fichier
se contente de définir les variables d'environnement, les
définitions d'alias et de fonctions sont définies dans le fichier
.bashrc,
, qui fait appel au fichier /etc/bashrc).