2. Termes et conventions
Précédent |  | Suivant

## 2. Termes et conventions

### 2.1. Définitions

La terminologie de PAM est plutôt confuse. Ni la publication originale de Samar et Lai, ni la spécification XSSO n'ont essayé de définir formellement des termes pour les acteurs et les entités intervenant dans PAM, les termes qu'ils utilisent (mais ne définissent pas) sont parfois trompeurs et ambigus. Le premier essai d'établir une terminologie consistante et non ambiguë fut un papier écrit par Andrew G. Morgan (l'auteur de Linux-PAM) en 1999. Bien que les choix de Morgan furent un énorme pas en avant, ils ne sont pas parfait d'après l'auteur de ce document. Ce qui suit, largement inspiré par Morgan, est un essai de définir précisément et sans ambiguïté des termes pour chaque acteur ou entité utilisé dans PAM.

compte

  L'ensemble de permissions que le demandeur demande a l'arbitre.

demandeur

  L'utilisateur ou l'entité demandant authentification.

arbitre

  L'utilisateur ou l'entité possédant les privilèges nécessaires pour vérifier la requête du demandeur ainsi que l'autorité d'accorder ou de rejeter la requête.

chaîne

  Une séquence de modules qui sera invoquée pour répondre à une requête PAM. La chaîne comprend les informations concernant l'ordre dans lequel invoquer les modules, les arguments à leur passer et la façon d'interpréter les résultats.

client

  L'application responsable de la requête d'authentification au nom du demandeur et de recueillir l'information d'authentification nécessaire.

mécanisme

  Il s'agit de l'un des quatre groupes basiques de fonctionnalités fournit par PAM : authentification, gestion de compte, gestion de session et mise à jour du jeton d'authentification.

module

  Une collection d'une ou plusieurs fonctions implémentant un service d'authentification particulier, rassemblées dans un fichier binaire (normalement chargeable dynamiquement) et identifié par un nom unique.

règles

  Le jeu complet de configuration des règles décrivant comment traiter les requêtes PAM pour un service particulier. Une règle consiste normalement en quatre chaînes, une pour chaque mécanisme, bien que quelques services n'utilisent pas les quatre mécanismes.

serveur

  L'application agissant au nom de l'arbitre pour converser avec le client, récupérer les informations d'authentification, vérifier les droits du demandeur et autoriser ou rejeter la requête.

service

  Un ensemble de serveurs fournissant des fonctionnalités similaires ou liées et nécessitant une authentification similaire. Les règles de PAM sont définies sur un le principe de par-service; ainsi tous les serveurs qui demandent le même nom de service seront soumis aux mêmes règles.

session

  Le contexte dans lequel le service est délivré au demandeur par le serveur. L'un des quatre mécanismes de PAM, la gestion de session, s'en occupe exclusivement par la mise en place et le relâchement de ce contexte.

jeton

  Un morceau d'information associé avec un compte tel qu'un mot de passe ou une passphrase que le demandeur doit fournir pour prouver son identité.

transaction

  Une séquence de requêtes depuis le même demandeur vers la même instance du même serveur, commençant avec l'authentification et la mise en place de la session et se terminant avec le démontage de la session.

### 2.2. Exemples d'utilisation

Cette section a pour but d'illustrer quelques-uns des termes définis précédemment à l'aide d'exemples basiques.

#### 2.2.1. Client et serveurs ne font qu'un

Cet exemple simple montre `alice` utilisant su(1) pour devenir `root`.

`%` `whoami` alice `%` `ls -l `which su`` -r-sr-xr-x 1 root wheel 10744 Dec 6 19:06 /usr/bin/su `%` `su -` Password: `xi3kiune` `#` whoami root

- Le demandeur est `alice`.

- Le compte est `root`.

- Le processus su(1) est à la fois client et serveur.

- Le jeton d'authentification est `xi3kiune`.

- L'arbitre est `root`, ce qui explique pourquoi su(1) est setuid `root`.

#### 2.2.2. Client et serveur sont distincts.

L'exemple suivant montre `eve` essayant d'initier une connexion ssh(1) vers `login.exemple.com`, en demandant à se logguer en tant que `bob`. La connexion réussit. Bob aurait du choisir un meilleur mot de passe !

`%` `whoami` eve `%` `ssh bob@login.example.com` bob@login.example.com's password: `god` Last login: Thu Oct 11 09:52:57 2001 from 192.168.0.1 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.4-STABLE (LOGIN) #4: Tue Nov 27 18:10:34 PST 2001 Welcome to FreeBSD! `%`

- Le demandeur est `eve`.

- Le client d'`eve` est représenté par les processus ssh(1)

- Le serveur est le processus sshd(8) sur `login.example.com`

- Le compte est `bob`.

- Le jeton d'identification est `god`.

- Bien que cela ne soit pas montré dans cet exemple, l'arbitre est `root`.

#### 2.2.3. Exemple de règles

Les lignes qui suivent sont les règles par défaut de `sshd`:

sshd auth required pam_nologin.so no_warn sshd auth required pam_unix.so no_warn try_first_pass sshd account required pam_login_access.so sshd account required pam_unix.so sshd session required pam_lastlog.so no_fail sshd password required pam_permit.so

- Cette politique s'applique au service `sshd` (qui n'est pas nécessairement restreint au serveur sshd(8))

- `auth`, `account`, `session` et `password` sont des mécanismes.

- `pam_nologin.so`, `pam_unix.so`, `pam_login_access.so`, `pam_lastlog.so` et `pam_permit.so` sont des modules. Il est clair dans cet exemple que `pam_unix.so` fournit au moins deux mécanismes ( authentification et gestion de compte).

### 2.3. Conventions

Cette section n'a pas encore été écrite.

Précédent |  | Suivant
Pluggable Authentication Modules | Sommaire | 3. Les bases de PAM

Ce document, ainsi que d'autres peut être téléchargé sur ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/

Pour toutes questions à propos de FreeBSD, lisez la documentation avant de contacter <questions@FreeBSD.org>.
Pour les questions sur cette documentation, contactez <doc@FreeBSD.org>.