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

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

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

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 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 user's 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.

GDM uses PAM for login authentication, though if your machine does not support PAM you can build GDM to work with the password database and the crypt library function.

PAM stands for Pluggable Authentication Module, and is used by most programs that request authentication on your computer. It allows the administrator to configure different authentication behavior for different programs.

Some GDM features (like turning on automatic login) may require that you update your PAM configuration. PAM configuration has different, but similar, interfaces on different operating systems, so check your pam.d or pam.conf man page for details. Be sure that you read the PAM documentation (e.g. pam.d/pam.conf man page) and are comfortable with the security implications of any changes you intend to make to your configuration.

If there is no entry for GDM in your system's PAM configuration file, then features like automatic login may not work. Not having an entry will cause GDM to use default behavior, conservative settings are recommended and probably shipped with your distribution.

If you wish to make GDM work with other types of authentication mechanisms (such as a SmartCard), 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. This issue has been discussed on the

For security reasons a dedicated user and group id are required for proper operation! The need to be able to write Xauth files is why user "nobody" is not appropriate for gdm.

The GDM daemon normally runs as root, as does the slave. However GDM should also have a dedicated user id and a group id which it uses for its graphical interfaces such as gdmgreeter and gdmlogin. These are configured via the User and Group configuration options in the GDM configuration files. The user and group should be created before running "make install". By default GDM assumes the user and the group are called "gdm".

This userid is used to run the GDM GUI programs required for login. All functionality that requires root authority is done by the GDM daemon process. This design ensures that if the GUI programs are somehow exploited, only the dedicated user privileges are available.

It should however be noted that the GDM user and group have some privileges that make them somewhat dangerous. For one, they have access to the X server authorization directory. It must be able to read and write Xauth keys to <var>/lib/gdm. This directory should have root:gdm ownership and 1770 permissions. Running "make install" will set this directory to these values. The GDM daemon process will reset this directory to proper ownership/permissions if it is somehow not set properly.

The danger is that someone who gains the GDM user/group privileges can then connect to any session. So you should not, under any circumstances, make this some user/group which may be easy to get access to, such as the user nobody. Users who gain access to the "gdm" user could also modify the Xauth keys causing Denial-Of-Service attacks. Also if a person gains the ability to run programs as the user "gdm", it would be possible to snoop on running GDM processes, including usernames and passwords as they are being typed in.

Distributions and system administrators using GDM are expected to setup the dedicated user properly. It is recommended that this userid be configured to disallow login and to not have a default shell. Distributions and system administrators should set up the filesystem to ensure that the GDM user does not have read or write access to sensitive files.

The X server authorization directory (the ServAuthDir) is used for a host of random internal data in addition to the X server authorization files, and the naming is really a relic of history. GDM daemon enforces this directory to be owned by root.gdm with the permissions of 1770. This way, only root and the GDM group have write access to this directory, but the GDM group cannot remove the root owned files from this directory, such as the X server authorization files.

GDM by default doesn't trust the X server authorization directory and treats it in the same way as the temporary directory with respect to creating files. This way someone breaking the GDM user cannot mount attacks by creating links in this directory. Similarly the X server log directory is treated safely, but that directory should really be owned and writable only by root.

GDM only supports the MIT-MAGIC-COOKIE-1 X server 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 X server 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.

On the upside, GDM's random number generation is very conservative and GDM goes to extraordinary measures to truly get a 128 bit random number, using hardware random number generators (if available), plus the current time (in microsecond precision), a 20 byte array of pseudorandom numbers, process pid's, and other random information (possibly using /dev/audio or /dev/mem if hardware random generators are not available) to create a large buffer and then run MD5 digest on this. Obviously, all this work is wasted if you send this cookie over an open network or store it on an NFS directory (see UserAuthDir configuration key). So be careful about where you use remote X display.

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 you really need it. GDM guards against DoS (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 DoS via XDMCP then a webserver.

It is also wise to block all of the X Server ports. These are TCP ports 6000 + the display number of course) on your firewall. Note that GDM will use display numbers 20 and higher for flexible on-demand servers.

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

Note that NFS traffic really goes "over the wire" and thus can be snooped. When accessing the user's X authorization file (~/.Xauthority), GDM will try to open the file for reading as root. If it fails, GDM will conclude that it is on an NFS mount and it will automatically use UserAuthFBDir, which by default is set to /tmp. This behavior can be changed by setting the NeverPlaceCookiesOnNFS in the [security] section to false.

Even though your display is protected by cookies, XEvents and thus keystrokes typed when entering passwords will still go over the wire in clear text. It is trivial to capture these.

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.

The above sections "X Server Authentication Scheme" and "Firewall Security" also contain important information about using XDMCP securely. The next section also discusses how to set up XDMCP access control.

To workaround the inherent insecurity of XDMCP, gdm proposes a default built-in session that uses SSH to encrypt the remote connection. See the section "Securing remote connection through SSH" above.

XDMCP access control is done using TCP wrappers. It is possible to compile GDM without TCP wrappers however, so you should test your configuration and verify that they work.

You should use the daemon name gdm in the <etc>/hosts.allow and <etc>/hosts.deny files. For example to deny computers from .evil.domain from logging in, then add

gdm: .evil.domain

to <etc>/hosts.deny. You may also need to add

gdm: .your.domain

to your <etc>/hosts.allow if you normally disallow all services from all hosts. See the hosts.allow(5) man page for details.

The Local tab is used for controlling the appearance of GDM for local/static displays (non-XDMCP remote connections). The choices available in this tab depend on the setting of the "Style" combobox. This combobox is used to determine whether the "Plain" or "Themed" greeter GUI is used. The differences between these greeter programs are explained in the "Overview" section of this document.

If the "Style" choice is "Plain", then GDM will use the gdmlogin program as the GUI (daemon/Greeter). When this choice is selected, gdmsetup allows the user to select whether the background is an image or solid color (greeter/BackgroundType). If image is selected, there is a file selection button to pick the image file (greeter/BackgroundImage) and a checkbox to scale the image to fit the screen (greeter/BackgroundImageScaleToFit). If solid color is selected, there is a button available to allow the color selection (greeter/BackgroundColor). Also, the user may select the logo image that appears in gdmlogin (greeter/Logo).

If the "Style" choice is "Plain with face browser", then the gdmlogin program is used as the GUI (daemon/Greeter) and the face browser is turned on (greeter/Browser). The Face Browser is explained in the Overview section. Otherwise, the choices are the same as when the "Style" choice is "Plain". Additional setup in the Users tab may be necessary to choose which users appear in the Face Browser.

If the "Style" choice is "Themed", then the gdmgreeter program is used as the GUI (daemon/Greeter). When this choice is selected, gdmsetup allows the user to select the theme to be used (greeter/GraphicalTheme). Note that the checkbox to the left of the theme's name must be checked for a theme to be selected. Clicking on the theme, but not selecting the checkbox will highlight the theme and the "Remove" button can be used to delete the theme. Information about the theme's author and copyright are shown for the highlighted theme. The "Add" button can be used to add new themes to the system. To turn on the Face Browser, a theme which includes a Face Browser must be selected, such as happygnome-list. The "Background color" displayed when GDM starts (and if the theme has transparent elements) can also be selected (greeter/GraphicalThemedColor). The "Theme" combo box may be set to "Random from selected" if you want a random theme to be used for each login (greeter/GraphicalThemeRand and greeter/GraphicalThemes). To use random themes, select each theme that you wish to be used. By default this combobox is set to "Selected only", so that only a single theme can be selected and be used.

Regardless of the "Style" choice, the user may also select whether the Actions menu is visible (greeter/SystemMenu), whether the Actions menu includes the choice to start gdmsetup (greeter/ConfigAvailable), and whether the Action menu includes the choice to start gdmchooser to run a remote XDMCP login session (greeter/ChooserButton). Note that the root password must be entered to start gdmsetup from the login screen if it is enabled. Also the Welcome message displayed for local sessions may be selected (greeter/DefaultWelcome and greeter/Welcome). The Welcome message can contain the character sequences described in the "Text Node" section of the "Themed Greeter" section of this manual.

The Remote tab controls the appearance of the GDM for users logging in via XDMCP. By default XDMCP is disabled, and users should be comfortable with the XDMCP-related sections of the Security section of this document before enabling it. This tab includes a "Style" combobox which can be used to turn on XDMCP and control the appearance of GDM for remote users (gui/RemoteGreeter and xdmcp/Enable). This combobox may be set to "Remote login disabled" or "Same as Local". If the Local tab is set to "Plain" or "Plain with Face Browser", then the user may also select "Themed". If the Local tab is set to "Themed", then the user may also select "Plain" or "Plain with face browser". It is recommended that the "Plain" GUI be used for remote connections since it is more lightweight and tends to have better performance across a network.

If Remote login is enabled, then the user can specify the remote Welcome Message to be displayed (greeter/DefaultRemoteWelcome and greeter/RemoteWelcome). This welcome message is separate from the Local welcome message and can have a different value. The Welcome message can contain the character sequences described in the "Text Node" section of the "Themed Greeter" section of this manual.

If the "Style" choice is "Same as Local" and the local selection is "Plain" or "Plain with face browser", then the user may select whether background images should be displayed for remote logins (greeter/BackgroundRemoteOnlyColor).

If the "Style" choice is enabled and set to a different value than the Local tab, then the user has the same configuration choices as found on the Local tab except that the System Menu choices are not available since this is never available for remote logins for security purposes.

If Remote login is enabled, there is a "Configure XDMCP" button which displays a dialog allowing the user to set XDMCP configuration, including whether indirect requests are honored (xdmcp/HonorIndirect), UDP port (xdmcp/Port), maximum pending requests (xdmcp/MaxPending), maximum pending indirect requests (xmdcp/MaxPendingIndirect), maximum remote sessions (xdmcp/MaxSessions), maximum wait time (xdmcp/MaxWait), maximum indirect wait time (xdmcp/MaxWaitIndirect), displays per host (xdmcp/DisplaysPerHost), and ping interval (xdmcp/PingIntervalSeconds). The default settings are standard settings and should only be changed by someone who understands the ramifications of the change.

The Accessibility tab is used to turn on Accessibility features in GDM. "Enable accessible login" (daemon/AddGtkModules and daemon/GtkModulesList) turns on GDM's gesture listeners which are explained in the "Accessibility" section of this document. There is also a checkbox to allow users to change the theme when using the Plain greeter (gui/AllowGtkThemeChange). This feature allows GDM users to switch the theme to the HighContrast or LowContrast themes if needed. The user may also select whether GDM should play a sound when the login screen is ready, when login is successful and when login has failed. File chooser buttons are used to select the sound file to be played, and the "Play" button can be used to sample the sound.

The Security tab allows the user to turn on Automatic and Timed login, which user is logged in via an automatic or timed login, and the timed login delay (daemon/AutomaticLoginEnable, daemon/AutomaticLogin, daemon/TimedLoginEnable, daemon/TimedLogin, and daemon/TimedLoginDelay). If automatic login is turned on, then the specified user will immediately log in on reboot without GDM asking for username/password. If the user logs out of their session, GDM will start and ask for username and password to log back in. If TimedLogin is turned on, then GDM will log in to the specified user after a specified number of seconds. The user may enable Timed Login for remote (XDMCP) connections by checking the "Allow remote timed logins" checkbox.

On this tab, the user may select whether the system administrator user can log in, and whether the system administrator user can log in via remote (XDMCP) connections (security/AllowRoot and security/AllowRemoteRoot). The user may turn on GDM debug (debug/Enable) which causes debug messages to be sent to the system log. Debug should only be used when diagnosing a problem and not be left on when not needed. The "Deny TCP connections to Xserver" choice will disable X forwarding if selected (security/DisallowTCP). A login retry delay (security/RetryDelay) can be set to cause GDM to wait a number of seconds after a failed login.

The "Configure X Server" button can be used to specify how GDM manages each display. The "Servers" combobox shows what server definitions are available (Standard, Terminal, and Chooser by default). Refer to the "X Server Definitions" section of the "Configuration" section for more information about how to create new Server Definitions.

For any server type, the user may modify the "Server Name" (server/name), the "Command" (server/command) to be used to launch the Xserver, whether the server type will "Launch" (server/chooser) the greeter or chooser GUI after starting the Xserver, whether GDM handles this type (normally only set to false when logging into a Terminal session type), and whether the session type supports "Flexible" (server/flexible) sessions.

The "Servers To Start" section shows what server type is displayed for each display on the machine. Users may click on the "Add/Modify" button to add a new display to the list or to modify a selected display. This simply corresponds each physical display with the Server Definition to be used for managing that display. The "Remove" button may be used to remove a display from the list.

The Users tab controls which users appear in the Face Browser. If the "Include all users from /etc/password" checkbox is selected, then all users (with a userid above greeter/MinimalUID and not in the Exclude list) are displayed. If this checkbox is not selected, then users must be added to the "Include" list. Users in the "Exclude" list are never displayed. The "Add" and "Remove" buttons are used to add a new user to the list or remove a selected user from the list. The "Apply User Changes" button must be pressed after the "Include" and "Exclude" lists have been modified. The left and right arrow buttons between the "Include" and "Exclude" lists can be used to move a selected user from one list to the other.

In this section we will explain the Init, PostLogin, PreSession and PostSession directories as they are very similar.

When the X server has been successfully started, GDM will try to run the script called Init/<displayname>. I.e. Init/:0 for the first local display. If this file is not found, GDM will attempt to to run Init/<hostname>. I.e. Init/somehost. If this still is not found, GDM will try Init/XDMCP for all XDMCP logins or Init/Flexi for all on demand flexible displays. If none of the above were found, GDM will run Init/Default. The script will be run as root and GDM blocks until it terminates. Use the Init/* script for applications that are supposed to run alongside with the GDM login window. xconsole for instance. Commands to set the background etc. go in this file too.

It is up to the sysadmin to decide whether clients started by the Init script should be killed before starting the user session. This is controlled with the KillInitClients configuration option.

When the user has been successfully authenticated GDM tries the scripts in the PostLogin directory in the same manner as for the Init directory. This is done before any session setup is done, and so this would be the script where you might setup the home directory if you need to (though you should use the pam_mount module if you can for this). You have the $USER and $DISPLAY environment variables set for this script, and again it is run as root. The script should return 0 on success as otherwise the user won't be logged in. This is not true for failsafe session however.

After the user session has been setup from the GDM side of things, GDM will run the scripts in the PreSession directory, again in the same manner as the Init directory. Use this script for local session management or accounting stuff. The $USER environment variable contains the login of the authenticated user and $DISPLAY is set to the current display. The script should return 0 on success. Any other value will cause GDM to terminate the current login process. This is not true for failsafe sessions however. Also $X_SERVERS environmental variable is set and this points to a fake generated X servers file for use with the sessreg accounting application.

After this the base Xsession script is run with the selected session executable as the first argument. This is run as the user, and really this is the user session. The available session executables are taken from the Exec= line in the .desktop files in the path specified by SessionDesktopDir. Usually this path is <etc>/X11/sessions/:<etc>/dm/Sessions:/usr/share/xsessions/. The first found file is used. The user either picks from these sessions or GDM will look inside the file ~/.dmrc for the stored preference.

This script should really load the user's profile and generally do all the voodoo that is needed to launch a session. Since many systems reset the language selections done by GDM, GDM will also set the $GDM_LANG variable to the selected language. You can use this to reset the language environmental variables after you run the user's profile. If the user elected to use the system language, then $GDM_LANG is not set.

When the user terminates his session, the PostSession script will be run. Again operation is similar to Init, PostLogin and PreSession. Again the script will be run with root privileges, the slave daemon will block and the $USER environment variable will contain the name of the user who just logged out and $DISPLAY will be set to the display the user used, however note that the X server for this display may already be dead and so you shouldn't try to access it. Also $X_SERVERS environmental variable is set and this points to a fake generated X servers file for use with the sessreg accounting application.

Note that the PostSession script will be run even when the display fails to respond due to an I/O error or similar. Thus, there is no guarantee that X applications will work during script execution.

Except for the Xsession script all of these scripts will also have the environment variable $RUNNING_UNDER_GDM set to yes, so that you could perhaps use similar scripts for different display managers. The Xsession will always have the $GDMSESSION set to the basename of the session that the user chose to run without the .desktop extension. In addition $DESKTOP_SESSION is also set to the same value and in fact this will also be set by KDM in future versions.

Neither of the Init, PostLogin, PreSession or PostSession scripts are necessary and can be left out. The Xsession script is however required as well as at least one session .desktop file.

GDM uses two configuration files: <share>/gdm/defaults.conf and <etc>/gdm/custom.conf. The <share>/gdm/defaults.conf file contains the default configuration choices for GDM, and should not be modified by the user. The <etc>/gdm/custom.conf file is where users may specify their custom configuration choices. Configuration options specified in the <etc>/gdm/custom.conf file override the values in the <share>/gdm/defaults.conf file. If a configuration option is not defined in either file, GDM will default to the value described in the comments in the <share>/gdm/defaults.conf file.

Running the gdmsetup command will cause the <etc>/gdm/custom.conf to be modified with the user's configuration choices.

Previous to GDM 2.13.0.4 only the <etc>/gdm/gdm.conf existed. If upgrading to the new version of GDM, install will check to see if your <etc>/gdm/gdm.conf file is different than your <etc>/gdm/factory-gdm.conf file. If so, your <etc>/gdm/gdm.conf file will be automatically copied to <etc>/gdm/custom.conf to preserve any configuration changes.

The location of the configuration files may be controlled via the --with-defaults-conf and --with-custom-conf configuration options. The GDM daemon --config option may instead be used to specify the configuration file location. The GDM daemon must be restarted to change the configuration file being used.

Both configuration files are divided into sections each containing variables that define the behavior for a specific part of the GDM suite. Refer to the comments in the <share>/gdm/defaults.conf file for additional information about each configuration setting.

The <share>/gdm/defaults.conf and <etc>/gdm/custom.conf files follow the standard .ini style configuration file syntax. Keywords in brackets define sections, strings before an equal sign (=) are variables and the data after equal sign represents their value. Empty lines or lines starting with the hash mark (#) are ignored. The graphical configurator will try to preserve both comments (lines with a hash mark) and the overall structure of the file so you can intermix using the GUI or hand editing the configuration file.