GDM has a number of configuration interfaces. These include scripting integration points, daemon configuration, greeter configuration, general session settings, integration with gnome-settings-daemon configuration, and session configuration. These types of integration are described in detail below.
The GDM script integration points can be found in the <etc>/gdm/ directory:
Xsession Init/ PostLogin/ PreSession/ PostSession/
The Init, PostLogin, PreSession, and PostSession scripts all work as described below.
For each type of script, the default one which will be executed is called "Default" and is stored in a directory associated with the script type. So the default Init script is <etc>/gdm/Init/Default. A per-display script can be provided, and if it exists it will be run instead of the default script. Such scripts are stored in the same directory as the default script and have the same name as the Xserver DISPLAY value for that display. For example, if the <Init>/:0 script exists, it will be run for DISPLAY ":0".
All of these scripts are run with root privilege return 0 if run successfully, and a non-zero return code if there was any failure that should cause the login session to be aborted. Also note that GDM will block until the scripts finish, so if any of these scripts hang, this will cause the login process to also hang.
When the Xserver has been successfully started, GDM will run the Init script. This script is useful for starting programs that should be run while the login screen is showing, or for doing any special initialization required.
After the user has been successfully authenticated GDM will run the PostLogin script. This is done before any session setup has been done, including before the pam_open_session call. This script is useful for doing any session initialization that needs to happen before the session starts. For example, you might setup the user's $HOME directory if needed.
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.
After the user session has been initialized, GDM will run the PreSession script. This script is useful for doing any session initialization that needs to happen after the session has been initialized. It can be used for session management or accounting, for example.
When the user terminates his session, GDM will run the PostSession script. Note that the Xserver will have been stopped by the time this script is run, so it should not be accessed.
All of the above scripts will set the $RUNNING_UNDER_GDM environment variable to yes. If the scripts are also shared with other display managers, this allows you to identify when GDM is calling these scripts, so you can run specific code when GDM is used.
There is also an Xsession script located at <etc>/gdm/Xsession which is called between the PreSession and the PostSession scripts. This script does not supports per-display like the other scripts. This script is used for actually starting the user session. This script is run as the user, and it will run whatever session was specified by the Desktop session file the user selected to start.
Since many systems reset the language selections done by GDM, GDM will 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.
The Xsession script will set the $DESKTOP_SESSION environment variable to the basename of the session that the user selected, without the .desktop extension. You can use this to run any specific code for a given session. For backwards compatibility the $GDMSESSION environment variable is also set to the same value.
The GDM daemon is configured using the <etc>/gdm/custom.conf file. Default values are stored in GConf in the gdm.schemas file. It is recommended that end-users modify the /etc/gdm/custom.conf file because the GConf schemas file may be overwritten when the user updates their system to have a newer version of GDM.
Note that older versions of GDM supported additional configuration options which are no longer supported in the latest versions of GDM.
The <etc>/gdm/custom.conf file is in the standard INI format. Keywords in brackets define group sections, strings before an equal sign (=) are keys and the data after equal sign represents their value. Empty lines or lines starting with the hash mark (#) are ignored.
The /etc/gdm/custom.conf supports the "[daemon]", "[security]l", and "xdmcp" group sections. Within each group, there are particular key/value pairs that can be specified to modify how GDM behaves. For example, to enable timed login and specify the timed login user to be a user named "you", you would modify the file so it contains the following lines:
[daemon] TimedLoginEnable=true TimedLogin=you
A full list of supported configuration keys follow:
TODO - What about automatic login? Is this just now timedlogin with a 0 timeout value or something? Need to discuss this.
Group=gdm
The group name under which the greeter and other GUI programs are run. Refer to the User configuration key and to the "Security->GDM User And Group" section of this document for more information.
TimedLoginEnable=false
If the user given in TimedLogin should be logged in after a number of seconds (set with TimedLoginDelay) of inactivity on the login screen. This is useful for public access terminals or perhaps even home use. If the user uses the keyboard or browses the menus, the timeout will be reset to TimedLoginDelay or 30 seconds, whichever is higher. If the user does not enter a username but just hits the ENTER key while the login program is requesting the username, then GDM will assume the user wants to login immediately as the timed user. Note that no password will be asked for this user so you should be careful, although if using PAM it can be configured to require password entry before allowing login. Refer to the "Security->PAM" section of the manual for more information, or for help if this feature does not seem to work.
TimedLogin=
TODO - Is the root user still not available for this feature?
This is the user that should be logged in after a specified number of seconds of inactivity. This can never be "root" and gdm will refuse to log in root this way. The same features as for AutomaticLogin are supported. The same control chars and piping to a application are supported.
TimedLoginDelay=30
TODO - Is the 10 second delay still true?
Delay in seconds before the TimedLogin user will be logged in. It must be greater then or equal to 10.
User=gdm
The username under which the greeter and other GUI programs are run. Refer to the Group configuration key and to the "Security->GDM User And Group" section of this document for more information.
DisallowTCP=true
If true, then always append -nolisten tcp to the command line when starting attached Xservers, thus disallowing TCP connection. This is a more secure configuration if you are not using remote connections.
DisplaysPerHost=1
To prevent attackers from filling up the pending queue, GDM will only allow one connection for each remote computer. If you want to provide display services to computers with more than one screen, you should increase this value.
Note that the number of attached DISPLAYS allowed is not limited. Only remote connections via XDMCP are limited by this configuration option.
Enable=false
Setting this to true enables XDMCP support allowing remote displays/X terminals to be managed by GDM.
gdm listens for requests on UDP port 177. See the Port option for more information.
If GDM is compiled to support it, access from remote displays can be controlled using the TCP Wrappers library. The service name is gdm
You should add
gdm:.my.domain
Please note that XDMCP is not a particularly secure protocol and that it is a good idea to block UDP port 177 on your firewall unless you really need it.
EnableProxy=false
Setting this to true enables support for running XDMCP sessions on a local proxy Xserver. This may improve the performance of XDMCP sessions, especially on high latency networks, as many X protocol operations can be completed without going over the network.
Note, however, that this mode will significantly increase the burden on the machine hosting the XDMCP sessions
See the FlexiProxy and FlexiProxyDisconnect options for further details on how to configure support for this feature.
HonorIndirect=true
Enables XDMCP INDIRECT choosing (i.e. remote execution of gdmchooser) for X-terminals which do not supply their own display browser.
MaxPending=4
To avoid denial of service attacks, GDM has fixed size queue of pending connections. Only MaxPending displays can start at the same time.
Please note that this parameter does not limit the number of remote displays which can be managed. It only limits the number of displays initiating a connection simultaneously.
MaxPendingIndirect=4
GDM will only provide MaxPendingIndirect displays with host choosers simultaneously. If more queries from different hosts come in, the oldest ones will be forgotten.
MaxSessions=16
Determines the maximum number of remote display connections which will be managed simultaneously. I.e. the total number of remote displays that can use your host.
MaxWait=30
When GDM is ready to manage a display an ACCEPT packet is sent to it containing a unique session id which will be used in future XDMCP conversations.
GDM will then place the session id in the pending queue waiting for the display to respond with a MANAGE request.
If no response is received within MaxWait seconds, GDM will declare the display dead and erase it from the pending queue freeing up the slot for other displays.
MaxWaitIndirect=30
The MaxWaitIndirect parameter determines the maximum number of seconds between the time where a user chooses a host and the subsequent indirect query where the user is connected to the host. When the timeout is exceeded, the information about the chosen host is forgotten and the indirect slot freed up for other displays. The information may be forgotten earlier if there are more hosts trying to send indirect queries then MaxPendingIndirect.
Port=177
The UDP port number gdm should listen to for XDMCP requests. Do not change this unless you know what you are doing.
PingIntervalSeconds=15
Interval in which to ping the Xserver in seconds. If the Xserver does not return before the next time we ping it, the connection is stopped and the session ended. This is a combination of the XDM PingInterval and PingTimeout, but in seconds.
Note that GDM in the past used to have a PingInterval configuration key which was also in minutes. For most purposes you'd want this setting to be lower then one minute however since in most cases where XDMCP would be used (such as terminal labs), a lag of more than 15 or so seconds would really mean that the terminal was turned off or restarted and you would want to end the session.
FlexiProxyReconnect=
Setting this option enables experimental support for session migration with XDMCP sessions. This enables users to disconnect from their session and later reconnect to that same session, possibly from a different terminal.
In order to use this feature, you must have a nested Xserver available which supports disconnecting from its parent Xserver and reconnecting to another Xserver. Currently, the Distributed Multihead X (DMX) server supports this feature to some extent and other projects like NoMachine NX are busy implementing it.
This option should be set to the path of a command which will handle reconnecting the XDMCP proxy to another backend display. A sample implementation for use with DMX is supplied.
ProxyXServer=
The Xserver command line for a XDMCP proxy. Any nested X server like Xnest, Xephyr or Xdmx should work fairly well.
Willing=<etc>/gdm/Xwilling
When the machine sends a WILLING packet back after a QUERY it sends a string that gives the current status of this server. The default message is the system ID, but it is possible to create a script that displays customized message. If this script does not exist or this key is empty the default message is sent. If this script succeeds and produces some output, the first line of it's output is sent (and only the first line). It runs at most once every 3 seconds to prevent possible denial of service by flooding the machine with QUERY packets.
TODO - I only see the a11y keys being used in the chooser code, not the greeter code. Is this an error?
The GDM default greeter is called the simple Greeter and is configured via GConf. Default values are stored in GConf in the gdm-simple-greeter.schemas file. These defaults can be overridden if the "gdm" user has a writable $HOME directory to store GConf settings. These values can be edited using the gconftool-2 or gconf-editor programs. The following configuration options are supported:
false (boolean)
Controls whether the banner message text is displayed.
NULL (string)
Specifies the text banner message to show on the greeter window.
computer (string)
Set to the themed icon name to use for the greeter logo.
false (boolean)
Controls whether to show the restart buttons in the login window.
false (boolean)
Controls whether to show the accessibility buttons in the login window.
false (boolean)
Controls whether to show the accessibility buttons in the login window.
false (boolean)
Controls whether compiz is used as the window manager instead of metacity.
false (boolean)
Controls whether the on-screen keyboard accessibility application is started by default with the login greeter.
false (boolean)
Controls whether the screen reader accessibility application is started by default with the login greeter.
false (boolean)
Controls whether the screen magnifier accessibility application is started by default with the login greeter.
TODO - I think this section should be expanded upon. What specific keys are of interest, or would some users be likely to want to configure? Also, would be good to be more specific about how lock down management is handled.
The GDM Greeter uses some of the same framework that your desktop session will use. And so, it is influenced by a number of the same GConf settings. For each of these settings the Greeter will use the default value unless it is specifically overridden by a) GDM's installed mandatory policy b) system mandatory policy. GDM installs its own mandatory policy to lock down some settings for security.
TODO - I think this section should be expanded upon. What specific keys are of interest, or would some users be likely to want to configure? Also, would be good to give a more complete list of plugins that users might want to consider disabling. Also, shouldn't we list the sound/active key in the Greeter configuration setting? Oddly I do not find this key used in anything but the chooser in SVN.
GDM enables the following gnome-settings-daemon plugins: a11y-keyboard, background, sound, xsettings.
These are responsible for things like the background image, font and theme settings, sound events, etc.
Plugins can also be disabled using GConf. For example, if you want to disable the sound plugin then unset the following key: /apps/gdm/simple-greeter/settings-manager-plugins/sound/active.
GDM sessions are specified using the FreeDesktop.org Desktop Entry Specification, which can be referenced at the following URL: http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec.
These files are installed, by default, to <etc>/X11/sessions/. For backwards compatibility any desktop files in the <etc>/Sessions, <share>/xsessions, and <share/gdm/BuiltInSessions directories are also recognized by GDM.
TODO - I do not think the following disabling feature works in GDM anymore. Should it?
A session can be disabled by editing the desktop file and adding a line that says Hidden=true.
The user's default session and language choices are stored in the ~/.dmrc file. When a user logs in for the first time, this file is created with the user's initial choices. The user can change these default values by simply changing to a different value when logging in. GDM will notice this and prompt the user if they want to change their saved default value or not.
The ~/.dmrc file is in the standard INI format. It has one section called [Desktop] which has two keys: Session and Language.
The Session key specifies the basename of the session .desktop file that the user wishes to normally use without the .desktop extension. The Language key specifies the language that the user wishes to use by default. If either of these keys is missing, the system default is used. The file would normally look as follows:
[Desktop] Session=gnome Language=cs_CZ.UTF-8