# GNOME Display Manager Reference Manual

0.0
2008-09

GDM est le gestionnaire de connexions de GNOME, une application graphique pour s'identifier

Martin
K.
Petersen

    mkp@mkp.net

George
Lebl

    jirka@5z.com

Jon
McCann

    mccann@jhu.edu

Ray
Strode

    rstrode@redhat.com

Brian
Cameron

    Brian.Cameron@Sun.COM

1998
1999
Martin K. Petersen
2001
2003
2004
George Lebl
2003
2007
2008
Red Hat, Inc.
2003
2004
2005
2006
2007
2008
Sun Microsystems Inc.
2006,2007
Jonathan Ernst (jonathan@ernstfamily.ch)
2007
Gabriel De Sa (gabriel.desa@gmail.com)
2007-2008
Claude Paroz (claude@2xlibre.net)

Permission vous est donnée de copier, distribuer et/ou modifier ce document selon les termes de la Licence GNU Free Documentation License, Version 1.1 ou ultérieure publiée par la Free Software Foundation sans section inaltérable, sans texte de première page de couverture ni texte de dernière page de couverture. Vous trouverez un exemplaire de cette licence en suivant ce lien ou dans le fichier COPYING-DOCS fourni avec le présent manuel.

Ce manuel fait partie de la collection de manuels GNOME distribués selon les termes de la licence de documentation libre GNU. Si vous souhaitez distribuer ce manuel indépendamment de la collection, vous devez joindre un exemplaire de la licence au document, comme indiqué dans la section 6 de celle-ci.

La plupart des noms utilisés par les entreprises pour distinguer leurs produits et services sont des marques déposées. Lorsque ces noms apparaissent dans la documentation GNOME et que les membres du projet de Documentation GNOME sont informés de l'existence de ces marques déposées, soit ces noms entiers, soit leur première lettre est en majuscule.

LE PRÉSENT DOCUMENT ET SES VERSIONS MODIFIÉES SONT FOURNIS SELON LES TERMES DE LA LICENCE DE DOCUMENTATION LIBRE GNU SACHANT QUE :

1. LE PRÉSENT DOCUMENT EST FOURNI « TEL QUEL », SANS AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS, ET SANS LIMITATION, LES GARANTIES DE BONNE QUALITÉ MARCHANDE OU D'APTITUDE À UN EMPLOI PARTICULIER OU AUTORISÉ DU DOCUMENT OU DE SA VERSION MODIFIÉE. L'UTILISATEUR ASSUME TOUT RISQUE RELATIF À LA QUALITÉ, À LA PERTINENCE ET À LA PERFORMANCE DU DOCUMENT OU DE SA VERSION DE MISE À JOUR. SI LE DOCUMENT OU SA VERSION MODIFIÉE S'AVÉRAIT DÉFECTUEUSE, L'UTILISATEUR (ET NON LE RÉDACTEUR INITIAL, L'AUTEUR, NI TOUT AUTRE PARTICIPANT) ENDOSSERA LES COÛTS DE TOUTE INTERVENTION, RÉPARATION OU CORRECTION NÉCESSAIRE. CETTE DÉNÉGATION DE RESPONSABILITÉ CONSTITUE UNE PARTIE ESSENTIELLE DE CETTE LICENCE. AUCUNE UTILISATION DE CE DOCUMENT OU DE SA VERSION MODIFIÉE N'EST AUTORISÉE AUX TERMES DU PRÉSENT ACCORD, EXCEPTÉ SOUS CETTE DÉNÉGATION DE RESPONSABILITÉ ;

2. EN AUCUNE CIRCONSTANCE ET SOUS AUCUNE INTERPRÉTATION DE LA LOI, QU'IL S'AGISSE DE RESPONSABILITÉ CIVILE (Y COMPRIS LA NÉGLIGENCE), CONTRACTUELLE OU AUTRE, L'AUTEUR, LE RÉDACTEUR INITIAL, TOUT PARTICIPANT ET TOUT DISTRIBUTEUR DE CE DOCUMENTOU DE SA VERSION DE MISE À JOUR AINSI QUE TOUT FOURNISSEUR DE QUELQUE PARTIE QUE CE SOIT NE POURRONT ÊTRE TENUS RESPONSABLES À L'ÉGARD DE QUICONQUE POUR TOUT DOMMAGE DIRECT, INDIRECT, PARTICULIER OU ACCIDENTEL DE TOUT TYPE Y COMPRIS, SANS LIMITATION, LES DOMMAGES LIÉS À LA PERTE DE CLIENTÈLE, AUX ARRÊTS DE TRAVAIL, AUX DÉFAILLANCES ET AUX DYSFONCTIONNEMENTS INFORMATIQUES OU TOUT AUTRE DOMMAGE OU PERTE LIÉE À L'UTILISATION DU PRÉSENT DOCUMENT ET DE SES VERSIONS DE MISE À JOUR, ET CE MÊME SI CES PARTIES ONT ÉTÉ INFORMÉES DE LA POSSIBILITÉ DE TELS DOMMAGES.

This manual describes version 2.26.0 of the GNOME Display Manager. It was last updated on 02/10/2009.

## Termes et conventions utilisés dans ce manuel

This manual describes version 2.26.0 of the GNOME Display Manager. It was last updated on 02/10/2009.

Chooser - A program used to select a remote host for managing a display remotely on the attached display (`gdm-host-chooser`).

FreeDesktop - The organization providing desktop standards, such as the Desktop Entry Specification used by GDM. http://www.freedesktop.org.

GDM - GNOME Display Manager. Used to describe the software package as a whole.

Greeter - The graphical login window (`gdm-simple-greeter`).

PAM - Mécanisme d'authentification enfichable (Pluggable Authentication Mechanism).

XDMCP - Protocole de gestion d'affichage X.

Xserver - An implemention of the X Window System. For example the Xorg webserver provided by the X.org Foundation http://www.x.org.

Paths that start with a word in angle brackets are relative to the installation prefix. I.e. `<share>/pixmaps/` refers to `/usr/share/pixmaps` if GDM was configured with `--prefix=/usr`.

## Vue d'ensemble

### Introduction

The GNOME Display Manager (GDM) is a display manager that implements all significant features required for managing attached and remote displays. GDM was written from scratch and does not contain any XDM or X Consortium code.

Note that GDM is configurable, and many configuration settings have an impact on security. Issues to be aware of are highlighted in this document.

Please note that some Operating Systems configure GDM to behave differently than the default values as described in this document. If GDM does not seem to behave as documented, then check to see if any related configuration may be different than described here.

For further information about GDM, refer to the project website at http://www.gnome.org/projects/gdm and the project Wiki http://live.gnome.org/GDM.

For discussion or queries about GDM, refer to the

    gdm-list@gnome.org

mail list. This list is archived, and is a good resource to check to seek answers to common questions. This list is archived at http://mail.gnome.org/archives/gdm-list/ and has a search facility to look for messages with keywords.

Please submit any bug reports or enhancement requests to the "gdm" category in http://bugzilla.gnome.org.

### Stabilité de l'interface

GDM 2.20 and earlier supported stable configuration interfaces. However, the codebase was completely rewritten for GDM 2.22, and is not completely backward compatible with older releases. This is in part because things work differently, so some options just don't make sense, in part because some options never made sense, and in part because some functionaly hasn't been reimplemented yet.

Interfaces which continue to be supported in a stable fashion include the Init, PreSession, PostSession, PostLogin, and Xsession scripts. Some daemon configuration options in the `<etc>/gdm/custom.conf` file continue to be supported. Also, the `~/.dmrc`, and face browser image locations are still supported.

GDM 2.20 and earlier supported the ability to manage multiple displays with separate graphics cards, such as used in terminal server environments, login in a window via a program like Xnest or Xephyr, the gdmsetup program, XML-based greeter themes, and the ability to run the XDMCP chooser from the login screen. These features are did not get added back during the 2.22 rewrite.

### Functional Description

GDM is responsible for managing displays on the system. This includes authenticating users, starting the user session, and terminating the user session. GDM is configurable and the ways it can be configured are described in the "Configuring GDM" section of this document. GDM is also accessible for users with disabilities.

GDM provides the ability to manage the main console display, and displays launched via VT. It is integrated with other programs, such as the Fast User Switch Applet (FUSA) and gnome-screensaver to manage multiple displays on the console via the Xserver Virtual Terminal (VT) interface. It also can manage XDMCP displays.

Regardless of the display type, GDM will do the following when it manages the display. It will start an Xserver process, then run the `Init` script as the root user, and start the greeter program on the display.

The greeter program is run as the unpriviledged "gdm" user/group. This user and group are described in the "Security" section of this document. The main function of the greeter program is to authenticate the user. The authentication process is driven by Pluggable Authentication Modules (PAM). The PAM modules determine what prompts (if any) are shown to the user to authenticate. On the average system, the greeter program will request a username and password for authentication. However some systems may be configured to use alternative mechanisms such as a fingerprint or SmartCard reader. GDM and PAM can be configured to not require any input, which will cause GDM to automatically log in and simply start a session, which can be useful for some environments, such as for kiosks.

In addition to authentication, the greeter program allows the user to select which session to start and which language to use. Sessions are defined by files that end in the .desktop suffix and more information about these files can be found in the "Configuration" section of this document. By default, GDM is configured to display a face browser so the user can select their user account by clicking on an image instead of having to type their username. GDM keeps track of the user's default session and language in the user's `~/.dmrc` and will use these defaults if the user did not pick a session or language in the login GUI.

After authenticating a user, the daemon runs the `PostLogin` script as root, then runs the `PreSession` script as root. After running these scripts, the user session is started. When the user exits their session, the `PostSession` script is run as root. These scripts are provided as hooks for distributions and end-users to customize how sessions are managed. For example, using these hooks you could set up a machine which creates the user's $HOME directory on the fly, and erases it on logout. The difference between the `PostLogin` and `PreSession` scripts is that `PostLogin` is run before the pam_open_session call so is the right place to do anything which should be run before the user session is initialized. The `PreSession` script is called after session initialization.

### Greeter Panel

The GDM greeter program displays a panel docked at the bottom of the screen which provides additional functionality. When a user is selected, the panel allows the user to select which session, language, and keyboard layout to use after logging in. The keyboard layout selector also changes the keyboard layout used when typing your password. The panel also contains an area for login services to leave status icons. Some example status icons include a battery icon for current battery usage, and an icon for enabling accessibility features. The greeter program also provides buttons which allow the user to shutdown or restart the system. It is possible to configure GDM to not provide the shutdown and restart buttons, if desired. GDM can also be configured via PolicyKit (or via RBAC on Solaris) to require the user have appropriate authorization before accepting the shutdown or restart request.

Note that keyboard layout features are only available on systems that support libxklavier.

### Accessibilité

GDM supports "Accessible Login", allowing users to log into their desktop session even if they cannot easily use the screen, mouse, or keyboard in the usual way. Accessible Technology (AT) features such as an on-screen keyboard, screen reader, screen magnifier, and Xserver AccessX keyboard accessibility are available. It is also possible to enable large text or high contrast icons and controls, if needed. Refer to the "Accessibility Configuration" section of the document for more information how various accessibility features can be configured.

On some Operating Systems, it is necessary to make sure that the GDM user is a member of the "audio" group for AT programs that require audio output (such as text-to-speech) to be functional.

### Le navigateur de figures GDM

The Face Browser is the interface which allows users to select their username by clicking on an image. This feature can be enabled or disabled via the /apps/gdm/simple-greeter/disable_user_list GConf key and is on by default. When disabled, users must type their complete username by hand. When enabled, it displays all local users which are available for login on the system (all user accounts defined in the /etc/passwd file that have a valid shell and sufficiently high UID) and remote users that have recently logged in. The face browser in GDM 2.20 and earlier would attempt to display all remote users, which caused performance problems in large, enterprise deployments.

The Face Browser is configured to display the users who log in most frequently at the top of the list. This helps to ensure that users who log in frequently can quickly find their login image.

The Face Browser supports "type-ahead search" which dynamically moves the face selection as the user types to the corresponding username in the list. This means that a user with a long username will only have to type the first few characters of the username before the correct item in the list gets selected.

The icons used by GDM can be installed globally by the sysadmin or can be located in the user's home directories. If installed globally they should be in the `<share>/pixmaps/faces/` directory and the filename should be the name of the user. Face image files should be a standard image that GTK+ can read, such as PNG or JPEG. Face icons placed in the global face directory must be readable to the GDM user.

If there is no global icon for the user, GDM will look in the user's $HOME directory for the image file. GDM will first look for the user's face image in `~/.face`. If not found, it will try `~/.face.icon`. If still not found, it will use the value defined for "face/picture=" in the `~/.gnome2/gdm` file.

If a user has no defined face image, GDM will use the "stock_person" icon defined in the current GTK+ theme. If no such image is defined, it will fallback to a generic face image.

Please note that loading and scaling face icons located in remote user home directories can be a very time-consuming task. Since it not practical to load images over NIS or NFS, GDM does not attempt to load face images from remote home directories.

When the browser is turned on, valid usernames on the computer are exposed for everyone to see. If XDMCP is enabled, then the usernames are exposed to remote users. This, of course, limits security somewhat since a malicious user does not need to guess valid usernames. In some very restrictive environments the face browser may not be appropriate.

### XDMCP

Le démon GDM peut être configuré pour écouter et gérer les requêtes XDMCP (X Display Manage Protocol) provenant d'hôtes distants. Par défaut, XDMCP est désactivé, mais il peut être activé au besoin. Si GDM a été compilé avec la prise en charge de TCP Wrapper, le démon ne donnera accès qu'aux hôtes indiqués dans la section de service GDM du fichier de configuration de TCP Wrappers.

GDM includes several measures making it more resistant to denial of service attacks on the XDMCP service. A lot of the protocol parameters, handshaking timeouts, etc. can be fine tuned. The default configuration should work reasonably most systems.

GDM by default listens for XDMCP requests on the normal UDP port used for XDMCP, port 177, and will respond to QUERY and BROADCAST_QUERY requests by sending a WILLING packet to the originator.

GDM peut aussi être configuré pour répondre aux requêtes INDIRECT et présenter un sélecteur d'hôte à l'affichage distant. GDM mémorise le choix de l'utilisateur et fait suivre les requêtes suivantes au gestionnaire sélectionné. GDM gère également une extension au protocole qui lui fait oublier la redirection dès que la connexion de l'utilisateur a réussi. Cette extension n'est prise en charge que si les deux démons sont GDM. Ceci est transparent et est ignoré par XDM ou d'autres démons qui implémentent XDMCP.

Si XDMCP semble ne pas fonctionner, assurez-vous que toutes les machines sont présentes dans `/etc/hosts`.

Référez-vous à la section « Sécurité » pour des informations sur les questions de sécurité lors de l'utilisation de XDMCP.

### Journalisation

GDM uses syslog to log errors and status. It can also log debugging information, which can be useful for tracking down problems if GDM is not working properly. This can be enabled by starting the GDM daemon with the "--debug" option.

Output from the various Xservers is stored in the GDM log directory, which is normally `<var>/log/gdm/`. Any Xserver messages are saved to a file associated with the display value, `<display>.log`.

The session output is piped through the GDM daemon to the `~/.xsession-errors` file. The file is overwritten on each login, so logging out and logging back into the same user via GDM will cause any messages from the previous session to be lost.

Note that if GDM can not create this file for some reason, then a fallback file will be created named `~/.xsession-errors.XXXXXXXX` where the `XXXXXXXX` are some random characters.

### Fast User Switching

GDM allows multiple users to be logged in at the same time. After one user is logged in, additional, users can log in via the User Switcher on the GNOME Panel, or from the "Switch User" button in Lock Screen dialog of GNOME Screensaver. The active session can be changed back and forth using the same mechanism. Note that some distributions may not add the User Switcher to the default panel configuration. It can be added using the panel context menu.

Note this feature is available on systems that support Virtual Terminals. This feature will not function if Virtual Terminals is not available.

## Sécurité

### The GDM User And Group

For security reasons a dedicated user and group id are recommended for proper operation. This user and group are normally "gdm" on most systems, but can be configured to any user or group. All GDM GUI programs are run as this user, so that the programs which interact with the user are run in a sandbox. This user and group should have limited privilege.

The only special privilege the "gdm" user requires is the ability to read and write Xauth files to the `<var>/run/gdm` directory. The `<var>/run/gdm` directory should have root:gdm ownership and 1777 permissions.

You should not, under any circumstances, configure the GDM user/group to a user which a user could easily gain access to, such as the user `nobody`. Any user who gains access to an Xauth key can snoop on and control running GUI programs running in the associated or perform a denial-of-service attack on that session. It is important to ensure that the system is configured properly so that only the "gdm" user has access to these files and that it is not easy to login to this account. For example, the account should be setup to not have a password or allow non-root users to login to the account.

The GDM greeter configuration is stored in GConf. To allow the GDM user to be able to write configuration, it is necessary for the "gdm" user to have a writable $HOME directory. Users may configure the default GConf configuration as desired to avoid the need to provide the "gdm" user with a writable $HOME directory. However, some features of GDM may be disabled if it is unable to write state information to GConf configuration.

### PAM

GDM uses PAM for login authentication. PAM stands for Pluggable Authentication Module, and is used by most programs that request authentication on your computer. It allows the administrator to configure specific authentication behavior for different login programs (such as ssh, login GUI, screensaver, etc.)

PAM is complicated and highly configurable, and this documentation does not intend to explain this in detail. Instead, it is intended to give an overview of how PAM configuration relates with GDM, how PAM is commonly configured with GDM, and known issues. It is expected that a person needing to do PAM configuration would need to do further reading of PAM documentation to understand how to configure PAM and to understand terms used in this section.

PAM configuration has different, but similar, interfaces on different Operating Systems, so check the pam.d or pam.conf man page for details. Be sure to you read the PAM documentation and are comfortable with the security implications of any changes you intend to make to your configuration.

Note that, by default, GDM uses the "gdm" PAM service name for normal login and the "gdm-autologin" PAM service name for automatic login. These services may not be defined in your pam.d or pam.conf configured file. If there is no entry, then GDM will use the default PAM behavior. On most systems this should work fine. However, the automatic login feature may not work if the gdm-autologin service is not defined.

The `PostLogin` script is run before pam_open_session is called, and the `PreSession` script is called after. This allows the system administrator to add any scripting to the login process either before or after PAM initializes the session.

If you wish to make GDM work with other types of authentication mechanisms (such as a fingerprint or SmartCard reader), then you should implement this by using a PAM service module for the desired authentication type rather than by trying to modify the GDM code directly. Refer to the PAM documentation on your system. How to do this is frequently discussed on the

    gdm-list@gnome.org

mail list, so you can refer to the list archives for more information.

PAM does have some limitations regarding being able to work with multiple types of authentication at the same time, like supporting the ability to accept either SmartCard and the ability to type the username and password into the login program. There are techniques that are used to make this work, and it is best to research how this problem is commonly solved when setting up such a configuration.

If automatic login does not work on a system, check to see if the "gdm-autologin" PAM stack is defined in the PAM configuration. For this to work, it is necessary to use a PAM module that simply does no authentication, or which simply returns PAM_SUCCESS from all of its public interfaces. Assuming your system has a pam_allow.so PAM module which does this, a PAM configuration to enable "gdm-autologin" would look like this:

           gdm-autologin auth  required    pam_unix_cred.so.1
           gdm-autologin auth  sufficient  pam_allow.so.1
           gdm-autologin account  sufficient  pam_allow.so.1
           gdm-autologin session  sufficient  pam_allow.so.1
           gdm-autologin password  sufficient  pam_allow.so.1

La configuration ci-dessus ne produit aucune journalisation dans lastlog. Si vous souhaitez une telle journalisation, utilisez la configuration suivante pour l'élément session :

           gdm-autologin session required pam_unix_session.so.1

### utmp and wtmp

GDM generates utmp and wtmp User Accounting Database entries upon session login and logout. The utmp database contains user access and accounting information that is accessed by commands such as `finger`, `last`, `login`, and `who`. The wtmp database contains the history of user access and accounting information for the utmp database. Refer to the utmp and wtmp man pages on your system for more information.

### Processus d'authentification du serveur X

X server authorization files are stored in a newly created subdirectory of `<var>/run/gdm` at start up. These files contain a is used to store a "password" between X clients and the X server. This "password" is unqiue for each logged in session, so users from one session can't snoop on users from another.

GDM only supports the MIT-MAGIC-COOKIE-1 Xserver authentication scheme. Normally little is gained from the other schemes, and no effort has been made to implement them so far. Be especially careful about using XDMCP because the Xserver authentication cookie goes over the wire as clear text. If snooping is possible, then an attacker could simply snoop your authentication password as you log in, regardless of the authentication scheme being used. If snooping is possible and undesirable, then you should use ssh for tunneling an X connection rather then using XDMCP. You could think of XDMCP as a sort of graphical telnet, having the same security issues. In most cases, ssh -Y should be prefered over GDM's XDMCP features.

### Sécurité XDMCP

Même si votre affichage est protégé par des cookies, XEvents et donc aussi les frappes au clavier lors de la saisie des mots de passe transitent toujours sur le réseau en texte clair. Il est trivial de les capturer.

XDMCP is primarily useful for running thin clients such as in terminal labs. Those thin clients will only ever need the network to access the server, and so it seems like the best security policy to have those thin clients on a separate network that cannot be accessed by the outside world, and can only connect to the server. The only point from which you need to access outside is the server. This type of set up should never use an unmanaged hub or other sniffable network.

### Contrôle d'accès XDMCP

XDMCP access control is done using TCP wrappers. It is possible to compile GDM without TCP wrapper support, so this feature may not be supported on some Operating Systems.

Vous devriez utiliser le nom de démon `gdm` dans les fichiers `<etc>/hosts.allow` et `<etc>/hosts.deny`. Par exemple, pour empêcher les ordinateurs de `.danger.domaine` de se connecter, ajoutez

    gdm: .danger.domaine

à `<etc>/hosts.deny`. Il se peut que vous deviez aussi ajouter

    gdm: .votre.domaine

à `<etc>/hosts.allow`, dans le cas habituel où vous refusez tous les services de tous les hôtes. Consultez la page de manuel de hosts.allow(5) pour les détails.

### Sécurité du pare-feu

Even though GDM tries to outsmart potential attackers trying to take advantage of XDMCP, it is still advised that you block the XDMCP port (normally UDP port 177) on your firewall unless really needed. GDM guards against denial of service attacks, but the X protocol is still inherently insecure and should only be used in controlled environments. Also each remote connection takes up lots of resources, so it is much easier to do a denial of service attack via XDMCP then a webserver.

Il est également sage de bloquer tous les ports du serveur X sur votre pare-feu. Cela correspond aux ports TCP 6000 + le numéro d'affichage. Il est à relever que GDM utilise des numéros d'affichage à partir de 20 pour les serveurs flexibles sur demande.

X is not a very safe protocol for using over the net, and XDMCP is even less safe.

### PolicyKit

GDM may be configured to use PolicyKit to allow the system administrator to control whether the login screen should provide the shutdown and restart buttons on the greeter screen.

These buttons are controlled by the `org.freedesktop.consolekit.system.stop-multiple-users` and `org.freedesktop.consolekit.system.restart-multiple-users` actions respectively. Policy for these actions can be set up using the polkit-gnome-authorization tool, or the polkit-auth command line program.

### RBAC (Contrôle d'accès basé sur les rôles)

GDM may be configured to use RBAC instead of PolicyKit. In this case, RBAC configuration is used to control whether the login screen should provide the shutdown and restart buttons on the greeter screen.

For example, on Solaris, the "solaris.system.shutdown" authorization is used to control this. Simply modify the `/etc/user_attr` file so that the "gdm" user has this authorization.

## Prise en charge de ConsoleKit

GDM includes support for publishing user login information with the user and login session accounting framework known as ConsoleKit. ConsoleKit is able to keep track of all the users currently logged in. In this respect, it can be used as a replacement for the utmp or utmpx files that are available on most Unix-like Operating Systems.

Lorsque GDM est sur le point de créer un nouveau processus de connexion pour un utilisateur, il appelle une méthode privilégiée de ConsoleKit dans le but d'ouvrir une nouvelle session pour cet utilisateur. À cet instant, GDM fournit aussi à ConsoleKit des informations au sujet de cette session : l'identifiant de l'utilisateur, le nom d'affichage X11 qui sera associé à la session, le nom d'hôte de provenance de la session (utile dans le cas d'un session XDMCP), si la session est liée, etc. En tant qu'entité à l'origine du processus utilisateur, GDM est dans une position unique pour fournir de manière sûre ces éléments d'information sur la session de l'utilisateur. L'utilisation de cette méthode privilégiée est limitée par le respect de la politique de sécurité du bus de messages système D-Bus.

Dans le cas d'un utilisateur ayant une session existante et s'authentifiant par GDM pour demander la reprise de cette session, GDM appelle une méthode privilégiée de ConsoleKit pour déverrouiller la session. Les détails précis de ce qui se passe lorsque la session reçoit ce signal de déverrouillage ne sont pas définis et sont spécifiques à la session. Cependant, la plupart des sessions répondent en déverrouillant un économiseur d'écran.

Lorsque l'utilisateur choisit de fermer sa session ou si GDM ou la session se ferme de manière inattendue, la session utilisateur ne sera plus référencée par ConsoleKit.

Si la prise en charge de ConsoleKit n'est pas souhaitée, il peut être désactivé au moment de la compilation à l'aide de l'option « --with-console-kit=no » lors de l'exécution de « configure ».

## Configuration

GDM has a number of configuration interfaces. These include scripting integration points, daemon configuration, greeter configuration, general session settings, integration with gnome-settings-daemon configuration, and session configuration. These types of integration are described in detail below.

### Scripting Integration Points

The GDM script integration points can be found in the `<etc>/gdm/` directory:

    Xsession
    Init/
    PostLogin/
    PreSession/
    PostSession/

The `Init`, `PostLogin`, `PreSession`, and `PostSession` scripts all work as described below.

For each type of script, the default one which will be executed is called "Default" and is stored in a directory associated with the script type. So the default `Init` script is `<etc>/gdm/Init/Default`. A per-display script can be provided, and if it exists it will be run instead of the default script. Such scripts are stored in the same directory as the default script and have the same name as the Xserver DISPLAY value for that display. For example, if the `<Init>/:0` script exists, it will be run for DISPLAY ":0".

All of these scripts are run with root privilege return 0 if run successfully, and a non-zero return code if there was any failure that should cause the login session to be aborted. Also note that GDM will block until the scripts finish, so if any of these scripts hang, this will cause the login process to also hang.

When the Xserver for the login GUI has been successfully started, but before the login GUI is actually displayed, GDM will run the `Init` script. This script is useful for starting programs that should be run while the login screen is showing, or for doing any special initialization required.

After the user has been successfully authenticated GDM will run the `PostLogin` script. This is done before any session setup has been done, including before the pam_open_session call. This script is useful for doing any session initialization that needs to happen before the session starts. For example, you might setup the user's $HOME directory if needed.

After the user session has been initialized, GDM will run the `PreSession` script. This script is useful for doing any session initialization that needs to happen after the session has been initialized. It can be used for session management or accounting, for example.

When the user terminates his session, GDM will run the `PostSession` script. Note that the Xserver will have been stopped by the time this script is run, so it should not be accessed.

Il faut savoir que le script `PostSession` est exécuté même lorsque l'affichage ne répond plus suite à une erreur d'entrée/sortie ou autre. Il n'existe donc aucune garantie que les applications X fonctionnent durant l'exécution de ce script.

All of the above scripts will set the `$RUNNING_UNDER_GDM` environment variable to `yes`. If the scripts are also shared with other display managers, this allows you to identify when GDM is calling these scripts, so you can run specific code when GDM is used.

### Autostart Configuration

The `<share>/gdm/autostart/LoginWindow` directory contains files in the format specified by the "FreeDesktop.org Desktop Application Autostart Specification". Standard features in the specification may be used to specify programs should auto-restart or only be launched if a GConf configuration value is set, etc.

Any `.desktop` files in this directory will cause the associated program to automatically start with the login GUI greeter. By default, GDM is shipped with files which will autostart the gdm-simple-greeter login GUI greeter itself, the gnome-power-manager application, the gnome-settings-daemon, and the metacity window manager. These programs are needed for the greeter program to work. In addition, desktop files are provided for starting various AT programs if the configuration values specified in the Accessibility Configuration section below are set.

### Xsession Script

There is also an `Xsession` script located at `<etc>/gdm/Xsession` which is called between the `PreSession` and the `PostSession` scripts. This script does not supports per-display like the other scripts. This script is used for actually starting the user session. This script is run as the user, and it will run whatever session was specified by the Desktop session file the user selected to start.

### Configuration du démon

The GDM daemon is configured using the `<etc>/gdm/custom.conf` file. Default values are stored in GConf in the `gdm.schemas` file. It is recommended that end-users modify the `/etc/gdm/custom.conf` file because the schemas file may be overwritten when the user updates their system to have a newer version of GDM.

Note that older versions of GDM supported additional configuration options which are no longer supported in the latest versions of GDM.

The `<etc>/gdm/custom.conf` file is in the `keyfile` format. Keywords in brackets define group sections, strings before an equal sign (=) are keys and the data after equal sign represents their value. Empty lines or lines starting with the hash mark (#) are ignored.

The `/etc/gdm/custom.conf` supports the "[daemon]", "[security]", and "[xdmcp]" group sections. Within each group, there are particular key/value pairs that can be specified to modify how GDM behaves. For example, to enable timed login and specify the timed login user to be a user named "you", you would modify the file so it contains the following lines:

    [daemon]
    TimedLoginEnable=true
    TimedLogin=you

A full list of supported configuration keys follow:

#### [chooser]

Multicast

      Multicast=false

  If true and IPv6 is enabled, the chooser will send a multicast query to the local network and collect responses from the hosts who have joined multicast group.

MulticastAddr

      MulticastAddr=ff02::1

  This is the Link-local Multicast address.

#### [daemon]

Group

      Group=gdm

  The group name under which the greeter and other GUI programs are run. Refer to the `User` configuration key and to the "Security->GDM User And Group" section of this document for more information.

TimedLoginEnable

      TimedLoginEnable=false

  If the user given in `TimedLogin` should be logged in after a number of seconds (set with `TimedLoginDelay`) of inactivity on the login screen. This is useful for public access terminals or perhaps even home use. If the user uses the keyboard or browses the menus, the timeout will be reset to `TimedLoginDelay` or 30 seconds, whichever is higher. If the user does not enter a username but just hits the ENTER key while the login program is requesting the username, then GDM will assume the user wants to login immediately as the timed user. Note that no password will be asked for this user so you should be careful, although if using PAM it can be configured to require password entry before allowing login. Refer to the "Security->PAM" section of the manual for more information, or for help if this feature does not seem to work.

TimedLogin

      TimedLogin=

  This is the user that should be logged in after a specified number of seconds of inactivity.

TimedLoginDelay

      TimedLoginDelay=30

  Delay in seconds before the `TimedLogin` user will be logged in.

AutomaticLoginEnable

      AutomaticLoginEnable=false

  If true, the user given in `AutomaticLogin` should be logged in immediately. This feature is like timed login with a delay of 0.

AutomaticLogin

      AutomaticLogin=

  This is the user that should be logged in immediately if `AutomaticLoginEnable` is true.

User

      User=gdm

  The username under which the greeter and other GUI programs are run. Refer to the `Group` configuration key and to the "Security->GDM User And Group" section of this document for more information.

#### Options de sécurité

##### [security]

DisallowTCP

      DisallowTCP=true

  If true, then always append `-nolisten tcp` to the command line when starting attached Xservers, thus disallowing TCP connection. This is a more secure configuration if you are not using remote connections.

#### Prise en charge de XDMCP

##### [xdmcp]

DisplaysPerHost

      DisplaysPerHost=1

  To prevent attackers from filling up the pending queue, GDM will only allow one connection for each remote computer. If you want to provide display services to computers with more than one screen, you should increase this value.

  Il faut relever que le nombre autorisé d'affichages liés est illimité. Seules les connexions distantes par XDMCP sont limitées par cette option de configuration.

Enable

      Enable=false

  La définition de cette option à « true » (vrai) active la prise en charge de XDMCP pour permettre à des terminaux X ou des affichages distants d'être gérés par GDM.

  `gdm` écoute les requêtes sur le port UDP 177. Consultez l'option Port pour plus d'informations.

  Si GDM est compilé pour le prendre en charge, l'accès à partir d'affichages distants peut être contrôlé par la bibliothèque TCP Wrappers. Le nom de service est `gdm`.

  You should add

      gdm:.my.domain

  to your `<etc>/hosts.allow`, depending on your TCP Wrappers configuration. See the hosts.allow man page for details.

  Il faut relever que XDMCP n'est pas un protocole particulièrement sécurisé, et qu'il est conseillé de bloquer le port UDP 177 sur votre pare-feu si vous n'en avez pas vraiment besoin.

HonorIndirect

      HonorIndirect=true

  Enables XDMCP INDIRECT choosing (i.e. remote execution of `gdmchooser`) for X-terminals which do not supply their own display browser.

MaxPending

      MaxPending=4

  Pour éviter les attaques par déni de service, GDM dispose d'une file d'attente de connexions limitée. Seuls MaxPending affichages peuvent démarrer simultanément.

  Please note that this parameter does not limit the number of remote displays which can be managed. It only limits the number of displays initiating a connection simultaneously.

MaxSessions

      MaxSessions=16

  Détermine le nombre maximal de connexions d'affichages distants gérées simultanément. Cela correspond donc au nombre total d'affichages distants utilisables par l'hôte.

MaxWait

      MaxWait=30

  Lorsque GDM est prêt à gérer un affichage, un paquet ACCEPT lui est envoyé avec un identifiant de session unique qui sera utilisé dans les échanges XDMCP subséquents.

  GDM place ensuite l'identifiant de session dans la file d'attente, en attendant que l'affichage réponde par une requête MANAGE.

  Si aucune réponse n'arrive dans l'intervalle en secondes défini par MaxWait, GDM considère l'affichage comme mort et l'efface de la file d'attente, libérant la place pour d'autres affichages.

MaxWaitIndirect

      MaxWaitIndirect=30

  Le paramètre MaxWaitIndirect détermine le nombre maximal de secondes entre le moment où un utilisateur choisit un hôte et la requête indirecte correspondant à la connexion de l'utilisateur à l'hôte. Si ce délai est dépassé, l'information à propos de l'hôte choisi est oubliée et la place est libérée pour une autre demande d'affichage indirect. Il se peut que cette information soit oubliée plus rapidement s'il y a davantage d'hôtes essayant d'envoyer des requêtes indirectes que le nombre défini dans `MaxPendingIndirect`.

PingIntervalSeconds

      PingIntervalSeconds=15

  Interval in which to ping the Xserver in seconds. If the Xserver does not return before the next time we ping it, the connection is stopped and the session ended. This is a combination of the XDM PingInterval and PingTimeout, but in seconds.

  Signalons que dans le passé, GDM avait une clé de configuration `PingInterval` qui était aussi définie en minutes. Dans bien des cas, il est souhaitable de définir une valeur en-dessous de la minute, car dans la plupart des utilisations de XDMCP (comme dans des salles de terminaux), des délais de réponse supérieurs à une quinzaine de secondes signifie vraiment que le terminal a été éteint ou redémarré, et il est préférable de terminer la session.

Port

      Port=177

  The UDP port number `gdm` should listen to for XDMCP requests. Do not change this unless you know what you are doing.

Willing

      Willing=<etc>/gdm/Xwilling

  When the machine sends a WILLING packet back after a QUERY it sends a string that gives the current status of this server. The default message is the system ID, but it is possible to create a script that displays customized message. If this script does not exist or this key is empty the default message is sent. If this script succeeds and produces some output, the first line of it's output is sent (and only the first line). It runs at most once every 3 seconds to prevent possible denial of service by flooding the machine with QUERY packets.

### Simple Greeter Configuration

The GDM default greeter is called the simple Greeter and is configured via GConf. Default values are stored in GConf in the `gdm-simple-greeter.schemas` file. These defaults can be overridden if the "gdm" user has a writable $HOME directory to store GConf settings. These values can be edited using the `gconftool-2` or `gconf-editor` programs. The following configuration options are supported:

#### Greeter Configuration Keys

/apps/gdm/simple-greeter/banner_message_enable

      false (boolean)

  Controls whether the banner message text is displayed.

/apps/gdm/simple-greeter/banner_message_text

      NULL (string)

  Specifies the text banner message to show on the greeter window.

/apps/gdm/simple-greeter/debug

      false (boolean)

  If true, then debugging mode is enabled for the greeter.

/apps/gdm/simple-greeter/disable_restart_buttons

      false (boolean)

  Controls whether to show the restart buttons in the login window.

/apps/gdm/simple-greeter/disable_user_list

      false (boolean)

  If true, then the face browser with known users is not shown in the login window.

/apps/gdm/simple-greeter/logo_icon_name

      computer (string)

  Set to the themed icon name to use for the greeter logo.

/apps/gdm/simple-greeter/recent-languages

      [] (string list)

  Set to a list of languages to be shown by default in the login window. Default value is "[]". With the default setting only the system default language is shown and the option "Other..." which pops-up a dialog box showing a full list of available languages which the user can select.

  Users are not intended to change this setting by hand. Instead GDM keeps track of any languages selected in this configuration key, and will show them in the language combo box along with the "Other..." choice. This way, commonly selected languages are easier to select.

/apps/gdm/simple-greeter/recent-layouts

      [] (string list)

  Set to a list of keyboard layouts to be shown by default in the login panel. Default value is "[]". With the default setting only the system default keyboard layout is shown and the option "Other..." which pops-up a dialog box showing a full list of available keyboard layouts which the user can select.

  Users are not intended to change this setting by hand. Instead GDM keeps track of any keyboard layouts selected in this configuration key, and will show them in the keyboard layout combo box along with the "Other..." choice. This way, commonly selected keyboard layouts are easier to select.

/apps/gdm/simple-greeter/wm_use_compiz

      false (boolean)

  Controls whether compiz is used as the window manager instead of metacity.

### Configuration de l'accessibilité

If the user associated with running the GDM GUI programs has accessibility features enabled via GConf configuration, then the GDM GUI programs will recognize these.

#### Greeter Configuration Keys

/desktop/gnome/interface/accessibility

      false (boolean)

  Controls whether the Accessibility infrastructure will be started with the GDM GUI. This is needed for any accessibility technology programs to work.

/desktop/gnome/applications/at/screen_magnifier_enabled

      false (boolean)

  If set, then the GNOME magnifier will be started with the GDM GUI programs.

/desktop/gnome/applications/at/screen_keyboard_enabled

      false (boolean)

  If set, then the GNOME on-screen keyboard will be started with the GDM GUI programs.

/desktop/gnome/applications/at/screen_reader_enabled

      false (boolean)

  If set, then the GNOME screen reader will be started with the GDM GUI programs.

### General Session Settings

The GDM Greeter uses some of the same framework that your desktop session will use. And so, it is influenced by a number of the same GConf settings. For each of these settings the Greeter will use the default value unless it is specifically overridden by a) GDM's installed mandatory policy b) system mandatory policy. GDM installs its own mandatory policy to lock down some settings for security.

### GNOME Settings Daemon

GDM enables the following gnome-settings-daemon plugins: a11y-keyboard, background, sound, xsettings.

These are responsible for things like the background image, font and theme settings, sound events, etc.

Plugins can also be disabled using GConf. For example, if you want to disable the sound plugin then unset the following key: `/apps/gdm/simple-greeter/settings-manager-plugins/sound/active`.

### GDM Session Configuration

GDM sessions are specified using the FreeDesktop.org Desktop Entry Specification, which can be referenced at the following URL: http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec.

These files are installed, by default, to `<etc>/X11/sessions/`. For backwards compatibility any desktop files in the `<etc>/Sessions`, `<share>/xsessions`, and `<share/gdm/BuiltInSessions` directories are also recognized by GDM.

A session can be disabled by editing the desktop file and adding a line that says `Hidden=true`.

### GDM User Session and Language Configuration

The user's default session and language choices are stored in the `~/.dmrc` file. When a user logs in for the first time, this file is created with the user's initial choices. The user can change these default values by simply changing to a different value when logging in. GDM will remember this change for subsequent logins.

The `~/.dmrc` file is in the standard `INI` format. It has one section called `[Desktop]` which has two keys: `Session` and `Language`.

The `Session` key specifies the basename of the session `.desktop` file that the user wishes to normally use without the `.desktop` extension. The `Language` key specifies the language that the user wishes to use by default. If either of these keys is missing, the system default is used. The file would normally look as follows:

    [Desktop]
    Session=gnome
    Language=fr_FR.UTF-8

## Commandes GDM

### Commandes GDM pour l'administrateur (root)

The GDM package provides the following commands in `sbindir` intended to be run by the root user:

#### Options en ligne de commande de `gdm` et `gdm-binary`

The `gdm` command is really just a script which runs the `gdm-binary`, passing along any options. Before launching `gdm-binary`, the gdm wrapper script will source the `<etc>/profile` file to set the standard system environment variables. In order to better support internationalization, it will also set the LC_MESSAGES environment variable to LANG if neither LC_MESSAGES or LC_ALL are set. The `gdm-binary` is the actual GDM daemon.

##### Options en ligne de commande de `gdm` et `gdm-binary`

-?, --help

  Donne un bref aperçu des options en ligne de commande.

--debug

  Print debug output to the syslog. This is typically `<var>/log/messages` or `<var>/adm/messages` depending on your Operating System.

--fatal-warnings

  Make all warnings cause GDM to exit.

--timed-exit

  Exit after 30 seconds. Useful for debugging.

--version

  Affiche la version du démon GDM.

#### Options en ligne de commande de `gdm-restart`

`gdm-restart` arrête et redémarre GDM en envoyant un signal HUP au démon GDM. Cette commande ferme immédiatement toutes les sessions et déconnecte les utilisateurs actuellement connectés avec GDM.

#### Options en ligne de commande de `gdm-safe-restart`

`gdm-safe-restart` arrête et redémarre GDM en envoyant un signal USR1 au démon GDM. GDM sera redémarré dès que tous les utilisateurs se seront déconnectés.

#### Options en ligne de commande de `gdm-stop`

`gdm-stop` arrête GDM en envoyant un signal TERM au démon GDM.

## Dépannage

This section discusses helpful tips for getting GDM working. In general, if you have a problem using GDM, you can submit a bug or send an email to the gdm-list mailing list. Information about how to do this is in the Introduction section of the document.

If GDM is failing to work properly, it is always a good idea to include debug information. To turn on debug, launch gdm with the --debug option. Then use GDM to the point where it fails, and debug output will be sent to your system log (`<var>/log/messages` or `<var>/adm/messages` depending on your Operating System). If you share this output with the GDM community via a bug report or email, please only include the GDM related debug information and not the entire file since it can be large. If you do not see any GDM syslog output, you may need to configure syslog (refer to the syslog man page).

### GDM ne démarre pas

Il existe de nombreux problèmes qui peuvent empêcher le démarrage de GDM, mais dans cette section, nous abordons quelques problèmes courants et la manière de suivre attentivement un problème lors du démarrage de GDM. Certains problèmes génèrent un message d'erreur ou une boîte de dialogue de GDM lorsqu'il essaie de démarrer, mais lorsque ce n'est pas le cas, il est souvent difficile de trouver les causes d'un problème.

First make sure that the Xserver is configured properly. The GDM configuration file contains a command in the [server-Standard] section that is used for starting the Xserver. Verify that this command works on your system. Running this command from the console should start the Xserver. If it fails, then the problem is likely with your Xserver configuration. Refer to your Xserver error log for an idea of what the problem may be. The problem may also be that your Xserver requires different command-line options. If so, then modify the Xserver command in the GDM configuration file so that it is correct for your system.

Vérifiez aussi que le répertoire `/tmp` dispose d'un propriétaire convenable avec des permissions adéquates, et que le système de fichier de la machine n'est pas saturé. Ces problèmes empêchent GDM de démarrer.

## Licence

Ce programme est un logiciel libre ; vous pouvez le redistribuer et/ou le modifier conformément aux dispositions de la Licence Publique Générale GNU, telle que publiée par la Free Software Foundation ; version 2 de la licence, ou encore (à votre choix) toute version ultérieure.

Ce programme est distribué dans l'espoir qu'il sera utile, mais SANS AUCUNE GARANTIE ; sans même la garantie implicite de COMMERCIALISATION ou D'ADAPTATION À UN OBJET PARTICULIER. Pour plus de détails, voir la Licence Publique Générale GNU.

Un exemplaire de la Licence Publique Générale GNU est inclus en annexe du Guide d'utilisation du bureau GNOME. Vous pouvez également en obtenir un exemplaire en visitant le site Web de la Free Software Foundation ou en écrivant à

     Free Software Foundation, Inc. 51 Franklin Street, Fifth FloorBoston, MA02110-1301USA