Overview

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 / X Consortium code.

Note that GDM is highly configurable, and many configuration settings can affect security. Issues to be aware of are highlighted in this document and in the GDM Configuration files.

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

mail list to discuss any issues or concerns with the GDM program.

Interface Stability

The key/value pairs defined in the GDM configuration files and the location of these files are considered "stable" interfaces 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, 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, CustomCommands, SuspendCommand, StandardXServer, Xnest, SoundProgram, and the "command" value for each server-foo.

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.

As of the GDM 2.15 development series, some one-dash arguments are no longer supported. This includes the "-xdmaddress", "-clientaddress", and "-connectionType" arguments used by gdmchooser. These arguments have been changed to now use two dashes.

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

The GDM Daemon

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. Attached displays are always managed when GDM starts and will be restarted when a user's session is finished. Remote displays can be requested via XDMCP, flexible displays via the gdmflexiserver command, and dynamic displays via the gdmdynamic command. Displays that are started on request are not restarted on session exit.

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 user's 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 user's session exits, the GDM daemon will run the PostSession script as root.

Note that, by default, GDM uses the "gdm" service name for normal login and the "gdm-autologin" service name for automatic login. The PamStack configuration option can be used to specify a different service name. For example, if "foo" is specified, then GDM will use the "foo" service name for normal login and "foo-autologin" for automatic login.

For those looking at the code, the gdm_verify_user function in daemon/verify-pam.c is used for normal login and the gdm_verify_setup_user function is used for automatic login.

Different Display Types

GDM supports three different display types: attached displays, flexible displays, and XDMCP remote displays. The "X Server Definitions" subsection of the "Configuration" section explains how the X server is configured for different displays.

Attached (also known as local or 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. The "Attached DISPLAY Configuration" subsection of the "Configuration" section describes how attached displays are defined.

Flexible (also known as on-demand) displays are only available to users logged on the console. Starting a flexible display will lock the current user session and will show a new login screen over the current running session. If at least one flexible display is already running, and the user requests another, then a dialog will display showing existing flexible displays. The user can choose to switch back to a previous display or start a new flexible display. If the user switches back to a previous display, they will need to enter the password in the lock screen program to return to their session. The GDM configuration file specifies the maximum number of flexible displays allowed on the system.

Flexible displays may be started by running the gdmflexiserver command, or via calling the GDM socket protocol directly. Some lock screen programs provide a button to start a new flexible session. This allows a user to start a new session even if the screen was left locked. The GNOME Fast User Switch applet also uses the socket protocol to provide an applet interface on the GNOME panel for managing user displays quickly. 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).

The FlexibleXServers, FirstVT=7, VTAllocation, and FlexiReapDelayMinutes configuration settings are used to configure how flexible displays operate.

Nested displays are available to users even if not logged in on the console. Nested displays launch a login screen in a window in the user's current session. This can be useful if the user has more than one account on a machine and wishes to login to the other account without disrupting their current session. Nested displays may be started by running the gdmflexiserver -n command or via calling the GDM socket protocol directly. Nested displays require that the X server supports a nested X server command like Xnest or Xephyr. The Xnest configuration option is used to configure how nested displays are started.

The gdmdynamic is similar to gdmflexiserver in the sense that it allows the user to manage displays dynamically. However displays started with gdmdynamic are treated as attached displays, so they are restarted automatically when the session exits. This command is intended to be used in multi-user server environments (many displays connected to a single server). In other words, this command allows the displays to be managed without hardcoding the display information in the "Attached DISPLAY Configuration" section of the configuration file. This is useful to support the ability of adding new displays to the server without needing to restart GDM, for example.

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.

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

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.

Securing Remote Connection Through SSH

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

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

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 daemon, 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.

The GDM Face Browser

GDM supports a face browser which will display a list of users who can login and an icon for each user. Starting with version 2.18.1 the Browser configuration option must be set to "true" for this function to be available. In previous versions it was only required when using the GTK+ Greeter. When using the Themed Greeter, the Face Browser is only available if the GDM theme includes a "userlist" item type.

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

Logging

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 application could perhaps on reading some wrong data print out warnings or errors on the stderr or stdout. This could perhaps fill up the user's home directory making it necessary to log out and back into their session 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.

Accessing Files

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.

GDM Performance

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.