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

For further information about GDM, see the the GDM project website. Please submit any bug reports or enhancement requests to the "gdm" category in bugzilla.gnome.org. You can also send a message to the

The key/value pairs defined in the GDM configuration files and the location of these files are considered "stable" interfaces and should only change in ways that are backwards compatible. Note that this includes functionality like the GDM scripts (Init, PreSession, PostSession, PostLogin, XKeepsCrashing, etc.); directory locations (ServAuthDir, PidFile, etc.), system applications (SoundProgram), etc. Some configuration values depend on OS interfaces may need to be modified to work on a given OS. Typical examples are HaltCommand, RebootCommand, SuspendCommand, StandardXServer, Xnest, SoundProgram, and the "command" value for each "server-foo".

Note: distributions often change the default values of keys to support their platform. Command-line interfaces for GDM programs installed to <bin> and <sbin> are considered stable. Refer to your distribution documentation to see if there are any distribution-specific changes to these GDM interfaces and what support exists for them.

If issues are discovered that break compatibility, please file a bug with an "urgent" priority.

The GDM daemon 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. The Init, PostLogin, PreSession, and PostSession scripts discussed below are discussed in this "Configuring GDM section".

The GDM daemon supports a UNIX domain socket protocol which can be used to control aspects of its behavior and to query information. This protocol is described in the "Controlling GDM" section of this document.

GDM can be asked to manage a display a number of ways. Local displays are always managed when GDM starts and will be restarted when a user's session is finished. Displays can be requested via XDMCP, flexible displays can be requested by running the gdmflexiserver command. Displays that are started on request are not restarted on session exit. GDM also provides the gdmdynamic command to allow easier management of displays on a multi-user server. These display types are discussed further in the next section.

When the GDM daemon is asked to manage a display, it will fork an X server process, then run the Init script as the root user, and start the login GUI dialog as a slave process on the display. GDM can be configured to use either gdmgreeter (the default) or gdmlogin as the GUI dialog program. The gdmlogin program supports accessibility while the gdmgreeter program supports greater themeability. The GUI dialog is run as the unpriviledged "gdm" user/group which is described in the "Security" section below. The GUI dialog communicates with the daemon via a sockets protocol and via standard input/output. The slave, for example passes the username and password information to the GDM daemon via standard input/output so the daemon can handle the actual authentication.

The login GUI dialog screen allows the user to select which session they wish to start and which language they wish to use. Sessions are defined by files that end in the .desktop extension and more information about these files can be found in the "Configuration" section. The user enters their name and password and if these successfully authenticate, GDM will start the requested session for the user. It is possible to configure GDM to avoid the authentication process by turning on the Automatic or Timed Login features in the GDM configuration. The login GUI can also be configured to provide additional features to the user, such as the Face Browser; the ability to halt, restart, or suspend the system; and/or edit the login configuration (after entering the root password).

GDM, by default, will use Pluggable Authentication Modules (PAM) for authentication, but can also support regular crypt and shadow passwords on legacy systems. After authenticating a user, the daemon runs the PostLogin script as root, and forks a slave process to start the requested session. This slave process runs the PreSession script as root, sets up the users environment, and starts the requested session. 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. On Solaris, GDM (since version 2.8.0.3) uses the SDTLOGIN interface after user authentication to tell the X server to be restarted as the user instead of as root for added security. When the users session exits, the GDM daemon will run the PostSession script as root.

GDM supports three different display types: static (local) displays, flexible (on-demand) displays, and XDMCP (remote) displays. The "X Server Definitions" and the "Local Static X Display Configuration" subsections of the "Configuration" section explains how these various types of displays are defined in the GDM configuration file.

Local static displays are always started by the daemon, and when they die or are killed, they are restarted. GDM can run as many of these as needed. GDM can also manage displays on which it does not manage a GUI login, thus GDM can be used for supporting X terminals.

Flexible, or on demand displays, are started via the socket protocol with the gdmflexiserver command. This feature is only available to users logged in on the console and will display a new login screen. If a flexible display has previously been started on the console, running gdmflexiserver again will display a menu allowing users to switch back to a previous session or start a new flexible session. The gdmflexiserver locks the current session before starting a new flexible display, so the user's password must be entered before returning to an existing session. The gdmflexiserver command can also be used to launch nested Xnest display. These are launched in a window in the user's current session. Nested displays can be started even if not logged into the console and are started by running the gdmflexiserver -n command. Flexible displays are not restarted when the user session ends. Flexible displays require virtual terminal (VT) support in the kernel, and will not be available if not supported (such as on Solaris). Nested displays require that the X server supports Xnest.

The last display type is the XDMCP remote displays which are described in the next section. Remote hosts can connect to GDM and present the login screen if this is enabled. Some things are different for remote sessions. For example, the Actions menu which allows you to shut down, restart, suspend, or configure GDM are not shown.

Displays started via the gdmdynamic command are treated as local displays, so they are restarted automatically on when the session exits. This command is intended to more effectively manage the displays on a multi-user server (many displays connected to a single server).

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 defaults should work for most systems, however. Do not change them unless you know what you are doing.

GDM listens to UDP 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.

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

As explained in the "Security" section, XDMCP does not use any kind of encryption and as such is inherently insecure. As XDMCP uses UDP as a network transport layer, it is not possible to simply secure it through an SSH tunnel.

To remedy this problem, gdm can be configured at compilation-time with the option --enable-secureremote, in which case gdm proposes as a built-in session a session called "Secure Remote Connection". Starting such a session allows the user to enter the name or the address of the host on which to connect; provided the said host runs an SSH server, the user then gets connected to the server on which the default X session is started and displayed on the local host.

Using this session allows a much more secure network connection and only necessitates to have an SSH server running on the remote host.

The GTK+ Greeter is the default graphical user interface that is presented to the user. The greeter contains a menu at the top, an optional face browser, an optional logo and a text entry widget. This greeter has full accessibility support, and should be used by users with accessibility needs.

The text entry field is used for entering logins, passwords, passphrases etc. gdmlogin is controlled by the underlying daemon and is basically stateless. The daemon controls the greeter through a simple protocol where it can ask the greeter for a text string with echo turned on or off. Similarly, the daemon can change the label above the text entry widget to correspond to the value the authentication system wants the user to enter.

The menu bar in the top of the greeter enables the user to select the requested session type/desktop environment, select an appropriate locale/language, halt/restart/suspend the computer, configure GDM (given the user knows the root password), change the GTK+ theme, or start an XDMCP chooser.

The greeter can optionally display a logo in the login window. The image must be in a format readable to the gdk-pixbuf library (GIF, JPG, PNG, TIFF, XPM and possibly others), and it must be readable to the GDM user. See the Logo option in the reference section below for details.

The Themed Greeter is a greeter interface that takes up the whole screen and is very themable. Themes can be selected and new themes can be installed by the configuration application or by setting the GraphicalTheme configuration key. The Themed Greeter is much like the GTK+ Greeter in that it is controlled by the underlying daeon, is stateless, and is controlled by the daemon using the same simple protocol.

The look and feel of this greeter is really controlled by the theme and so the user interface elements that are present may be different. The only thing that must always be present is the text entry field as described above in the GTK+ Greeter. The theme can include buttons that allow the user to select an appropriate locale/language, halt/restart/suspend the computer, configure GDM (given the user knows the root password), or start an XDMCP chooser.

You can always get a menu of available actions by pressing the F10 key. This can be useful if the theme doesn't provide certain buttons when you wish to do some action allowed by the GDM configuration.

GDM supports a face browser which will display a list of users who can login and an icon for each user. This feature can be used with the GTK+ Greeter if the Browser configuration option is set to "true". This feature can be used with the Themed Greeter if using a GDM theme which includes a "userlist" item type is defined, such as "happygnome-list"

By default, the face browser is disabled since revealing usernames on the login screen is not appropriate on many systems for security reasons. Also GDM requires some setup to specify which users should be visible. Setup can be done on the "Users" tab in gdmsetup. This feature is most practical to use on a system with a smaller number of users.

The icons used by GDM can be installed globally by the sysadmin or can be located in the users' home directories. If installed globally they should be in the <share>/pixmaps/faces/ directory (though this can be configured with the GlobalFaceDir configuration option) and the filename should be the name of the user, optionally with a .png appended. Face icons placed in the global face directory must be readable to the GDM user. However, the daemon, proxies user pictures to the greeter and thus those do not have be be readable by the "gdm" user, but root.

Users may run the gdmphotosetup command to configure the image to use for their userid. This program properly scales the file down if it is larger than the MaxIconWidth or MaxIconHeight configuration options and places the icon in a file called ~/.face. Although gdmphotosetup scales user images automatically, this does not guarantee that user images are properly scaled since a user may create their ~/.face file by hand.

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. Lastly, it will try ~/.gnome2/photo and ~/.gnome/photo which are deprecated and supported for backwards compatibility.

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 the image specified in the DefaultFace configuration option, normally <share>/pixmaps/nobody.png.

Please note that loading and scaling face icons located in 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. Furthermore, GDM will give up loading face images after 5 seconds of activity and will only display the users whose pictures it has gotten so far. The Include configuration option can be used to specify a set of users who should appear on the face browser. As long as the users to include is of a reasonable size, there should not be a problem with GDM being unable to access the face images. To work around such problems, it is recommended to place face images in the directory specified by the GlobalFaceDir configuration option.

To control the users who get displayed in the face browser, there are a number of configuration options that can be used. If the IncludeAll option is set to true, then the password file will be scanned and all users will be displayed. If IncludeAll option is set to false, then the Include option should contain a list of users separated by commas. Only the users specified will be displayed. Any user listed in the Exclude option and users whose UID's is lower than MinimalUID will be filtered out regardless of the IncludeAll setting. IncludeAll is not is not recommended for systems where the passwords are loaded over a network (such as when NIS is used), since it can be very slow to load more than a small number of users over the network..

When the browser is turned on, valid usernames on the computer are inherently exposed to a potential intruder. This may be a bad idea if you do not know who can get to a login screen. This is especially true if you run XDMCP (turned off by default).

GDM itself will use syslog to log errors or 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 in the configuration file.

Output from the various X servers is stored in the GDM log directory, which is configurable, but is usually <var>/log/gdm/. The output from the session can be found in a file called <display>.log. Four older files are also stored with .1 through .4 appended. These will be rotated as new sessions on that display are started. You can use these logs to view what the X server said when it started up.

The output from the user session is redirected to ~/.xsession-errors before even the PreSession script is started. So it is not really necessary to redirect this again in the session setup script. As is usually done. If the user session lasted less then 10 seconds, GDM assumes that the session crashed and allows the user to view this file in a dialog before returning to the login screen. This way the user can view the session errors from the last session and correct the problem this way.

You can suppress the 10 second warning by returning code 66 from the Xsessionscript or from your session binary (the default Xsession script propagates those codes back). This is useful if you have some sort of special logins for which it is not an error to return less then 10 seconds later, or if you setup the session to already display some error message and the GDM message would be confusing and redundant.

The session output is piped through the GDM daemon and so the ~/.xsession-errors file is capped at about 200 kilobytes by GDM to prevent a possible denial of service attack on the session. An app could perhaps on reading some wrong data print out warnings or errors on the stderr or stdout. This could perhaps fill up the users home directory who would then have to log out and log back in to clear this. This could be especially nasty if quotas are set. GDM also correctly traps the XFSZ signal and stops writing the file, which would lead to killed sessions if the file was redirected in the old fashioned way from the script.

Note that some distributors seem to override the ~/.xsession-errors redirection and do it themselves in their own Xsession script (set by the BaseXsession configuration key) which means that GDM will not be able to trap the output and cap this file. You also lose output from the PreSession script which can make debugging things harder to figure out as perhaps useful output of what is wrong will not be printed out. See the description of the BaseXsession configuration key for more information, especially on how to handle multiple display managers using the same script.

Note that if the session is a failsafe session, or if GDM can't open this file for some reason, then a fallback file will be created in the /tmp directory named /tmp/xses-<user>.XXXXXX where the XXXXXX are some random characters.

If you run a system with quotas set, it would be good to delete the ~/.xsession-errors in the PostSession script. Such that this log file doesn't unnecessarily stay around.

In general GDM is very reluctant regarding reading/writing of user files (such as the ~/.dmrc, ~/.face, ~/.xsession-errors, and ~/.Xauthority files). For instance it refuses to access anything but regular files. Links, sockets and devices are ignored. The value of the RelaxPermissions parameter determines whether GDM should accept files writable by the user's group or others. These are ignored by default.

All operations on user files are done with the effective user id of the user. If the sanity check fails on the user's .Xauthority file, a fallback cookie is created in the directory specified by the UserAuthFBDir configuration setting (/tmp by default).

Finally, the sysadmin can specify the maximum file size GDM should accept, and, if the face browser is enabled, a tunable maximum icon size is also enforced. On large systems it is still advised to turn off the face browser for performance reasons. Looking up icons in home directories, scaling and rendering face icons can take a long time.

To speed performance it is possible to build GDM so that it will preload libraries when GDM first displays a greeter program. This has been shown to speed first time login since these libraries can be loaded into memory while the user types in their username and password.

To use this feature, configure GDM with the --with-prefetch option. This will cause GDM to install the gdmprefetch program to the libexecdir directory, install the gdmprefetchlist to the <etc>/gdm directory, and set the PreFetchProgram configuration variable so that the gdmprefetch program is called with the default gdmprefetchlist file. The default gdmprefetchlist file was optimized for a GNOME desktop running on Solaris, so may need fine-tuning on other systems. Alternative prefetchlist files can be contributed to the "gdm" category in bugzilla.gnome.org, so that they can be included in future GDM releases.