GDM was written with simplicity and security in mind. The overall
design concept is this:
Upon startup the gdm daemon parses its config file
gdm.conf.  For each of the local displays
gdm forks an Xserver and a slave process.  The
main gdm process will then listen to XDMCP
requests, if so configured, from remote displays and monitor the local
display sessions.  The main daemon process will also allow starting of
on new local Xservers on demand using the
gdmflexiserver command.
The gdm slave process opens the display and starts
gdmlogin, the graphical login application.
gdmlogin runs as a dedicated user and communicates
asynchronously with the slave process through a pipe.  Alternatively
gdmgreeter command can be used which is the same
as gdmlogin but allows greater themability.
gdmgreeter is referred to as the Themed
Greeter, while gdmlogin is refereed to as the
GTK+ Greeter.
GDM relies heavily on the presence of PAM, Pluggable Authentication
Modules, but supports regular crypt() and shadow passwords on legacy
systems.
Remote displays can connect to the XDMCP port on the GDM host.
gdm will grant access to hosts specified in the
GDM service section in your TCP Wrappers configuration file. GDM does
not support remote display access control on systems without TCP
Wrappers.  XDMCP support can be turned off completely, however.
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.  Don't change them unless you know what
you are doing.
In general GDM is very reluctant regarding reading/writing of user
files.  For instance it refuses to touch 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
/tmp.
Note that normally it is assumed that the home directory is only
readable by the user.  However NFS traffic really goes "over the wire"
and thus can be snooped.  For setups with NFS directories you should
really use the UserAuthDir and set it to some
local directory such as /tmp.  GDM will try to
open the normal authorization file for reading as root, and if it
fails, then it will conclude that it is on an NFS mount and it will
automatically use UserAuthFBDir, which is usually
/tmp.  This can be changed by setting
NeverPlaceCookiesOnNFS in the
[security] section to false.
GDM implements only the MIT-MAGIC-COOKIE-1 authorization scheme, see
the XDMCP section for more information about this, especially relating
to using X over the network.
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
homedirs, scaling and rendering face icons can take quite a long time.
YMMV.
GDM also has a unix domain socket which can be used to control
certain aspects of behavior, or to query information about running
servers or logged in users.  This is the
/tmp/.gdm_socket and the protocol is described
in the sources in the daemon/gdm.h header file.
The gdmflexiserver command uses this for example
to launch on demand X servers for the user.
