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