Given that you usually have to authenticate to the X Server by way of a "magic cookie" stored in the .xauthority file in the user's home directory: How does GDM (like most login processes, running as root, I would assume) connect to the X Server in order to draw the login display? Does it use any .xauthority files stored in the root user's home directory or does it bypass authentication altogether?


On my system ps finds this:

/usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth /var/lib/xdm/authdir/authfiles/A:0-wEJjac

The display manager starts X with the auth file to use as parameter. It can use that file directly.

Edit 1:

It's KDM in my case, not GDM.

  • Is that going to be used by gdm or the X server that gdm is connecting to? I don't have immediate ssh access to a machine sitting at the gdm login prompt so I can't do any ps or lsof commands.
    – Bratchley
    May 27 '13 at 23:21
  • @JoelDavis By my understanding both use the same file. May 27 '13 at 23:25
  • What distro is that on BTW?
    – Bratchley
    May 27 '13 at 23:29
  • @JoelDavis openSUSE 12.3 May 27 '13 at 23:30
  • OK I finally got home to my Fedora machine and finding similar auth files underneath /run/gdm as well as seeing some of the other answers. So I'm guessing you're right: gdm generates the cookie and starts Xorg, pointing at the cookie it just created for itself.
    – Bratchley
    May 28 '13 at 1:14

Test out your theory. Temporarily move these files from root's /root directory and see if these files either:

  1. Cause you issues so that you can no longer login
  2. Cause the files to get regenerated in /root

GDM Reference Manual

I'd take a look at the GNOME Display Manager Reference Manual. Looking at the documentation it would seem that root doesn't interact with X in any way. It forks another process with the user's effective userid which does this.

excerpt from GDM Reference Manual - GDM Daemon section

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 from remote displays and monitor the local display sessions.

The gdm slave process opens the display and starts gdmlogin, the graphical login program. gdmlogin runs as a dedicated user and communicates asynchronously with the slave process through a pipe.

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 databases

It seems like it's distro specific where the auth files get stored. For Red Hat distros they're under /var/run/gdm, for other OSes they're here, /var/lib/xdm.

Here's my Fedora directories:

$ pwd

$ tree 
├── auth-for-gdm-8DkDnQ
│   └── database
└── auth-for-saml-PSW952
    └── database

2 directories, 2 files

So I have 2 auth directories, one for user gdm and one for me, user saml.

$ strings auth-for-saml-PSW952/database
[root@grinchy gdm]# strings auth-for-gdm-8DkDnQ/database

Looking inside the database files there is info regarding MIT-MAGIC-COOKIES.

  • Yeah I'm seeing similar things on my side so it looks like it is gdm that generates the cookie if it doesn't exist (I'm assuming though xauth generate or something).
    – Bratchley
    May 28 '13 at 1:30
  • @JoelDavis - Yeah. xauth generate, xauth list, & xauth add. I found this Q that show how to add a user's MIT-MAGIC-COOKIE to gdm to change the gdm background/log: unix.stackexchange.com/a/8271/7453. BTW, another good question!
    – slm
    May 28 '13 at 1:38

The code in gdm daemon is responsible for the communication with X.

#define X_SERVER_ARG_FORMAT " -background none -noreset -verbose %s%s"
gdm_server_init_command (server);
g_shell_parse_argv (server->priv->command, &argc, &argv, NULL);
 /* server number is the FIRST argument, before any others */
argv[1] = g_strdup (server->priv->display_name);
if (server->priv->auth_file != NULL) {
    argv[len++] = g_strdup ("-auth");
    argv[len++] = g_strdup (server->priv->auth_file);

gdm-display-access-file.c handles cookies/Xauth files creation:

static FILE *
_create_xauth_file_for_user (const char *username,
    gdm_display_get_x11_display_number (display, &display_number, NULL);
    *number = g_strdup_printf ("%d", display_number);
    *number_length = strlen (*number);
    *name = g_strdup ("MIT-MAGIC-COOKIE-1");
    *name_length = strlen (*name);
    *cookie = gdm_generate_random_bytes (GDM_DISPLAY_ACCESS_COOKIE_SIZE,

These files are stored in newly created subdirectories under GDM_XAUTH_DIR (defaults to <var>/run/gdm) at start up. As Hauke pointed above, gdm starts the Xserver with the auth file used as a parameter:

systemctl status gdm.service
Main PID: 263 (gdm)
CGroup: /system.slice/gdm.service
       ├─263 /usr/bin/gdm
       └─287 /usr/bin/Xorg.bin :0 -background none -noreset -verbose 3 -logfile /dev/null -auth /var/run/gdm/auth-for-gdm-4X6qTS/database -seat seat0 -nolisten tcp vt1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.