Overview

2.1. 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://wiki.gnome.org/Projects/GDM.

For discussion or queries about GDM, refer to the

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.

2.2. Interface Stability

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 functionality has not 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 were not added back during the 2.22 rewrite.

2.3. 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 unprivileged "gdm" user/group. This user and group are described in the "Security" section of this document. The main functions of the greeter program are to provide a mechanism for selecting an account for log in and to drive the dialogue between the user and system when authenticating that account. 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 supplemental mechanisms such as a fingerprint or SmartCard readers. GDM can be configured to support these alternatives in parallel with greeter login extensions and the --enable-split-authentication ./configure option, or one at a time via system PAM configuration.

The smartcard extension can be enabled or disabled via the org.gnome.display-manager.extensions.smartcard.active gsettings key.

Likewise, the fingerprint extension can be enabled or disabled via the org.gnome.display-manager.extensions.fingerprint.active gsettings key.

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 single user systems or 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 "GDM User Session and Language 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.

2.4. 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 Oracle 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.

2.5. Accessibility

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.

2.6. The GDM Face Browser

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 org.gnome.login-screen disable-user-list GSettings 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.

2.7. XDMCP

The GDM daemon can be configured to listen for and manage X Display Manage Protocol (XDMCP) requests from remote displays. By default XDMCP support is turned off, but can be enabled if desired. If GDM is built with TCP Wrapper support, then the daemon will only grant access to hosts specified in the GDM service section in the TCP Wrappers configuration file.

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 on 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 can also be configured to honor INDIRECT queries and present a host chooser to the remote display. GDM will remember the user's choice and forward subsequent requests to the chosen manager. GDM also supports an extension to the protocol which will make it forget the redirection once the user's connection succeeds. This extension is only supported if both daemons are GDM. It is transparent and will be ignored by XDM or other daemons that implement XDMCP.

If XDMCP seems to not be working, make sure that all machines are specified in /etc/hosts.

Refer to the "Security" section for information about security concerns when using XDMCP.

2.8. Logging

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. Debug output can be enabled by setting the debug/Enable key to "true" in the <etc>/gdm/custom.conf file.

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 ~/$XDG_CACHE_HOME/gdm/session.log file which usually expands to ~/.cache/gdm/session.log. 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 ~/$XDG_CACHE_HOME/gdm/session.log.XXXXXXXX where the XXXXXXXX are some random characters.

2.9. 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.