Using and Managing GDM Jiri (George) Lebl Abstract 2.0 was around the corner (or it seemed more around the corner than it actually was), and we didn’t have a GDM does many things, however it contains almost working display manager. The problem with GDM2 no documentation. This talk (and paper) is an at- was that it was not finished and was basically not tempt to correct this situation. GDM was written working at all. Various distributions had their own as a simpler alternative to XDM and is in fact a very large patches which made it work in various complete rewrite and does not use any XDM code. ways, but mostly broke it in various different ways. It is simpler in places and more advanced in oth- So I started applying the distribution patches and ers, so it may not perhaps replace all the applica- later took over maintaining GDM2 and it became tions of XDM, but it aspires to be good enough to my pet project to add features and easter eggs to (of replace most, while having some other neat features course the panel still has the best easter eggs, and that XDM doesn’t have and overall being more user if you haven’t played ”gegls from outer space”, you friendly. This paper will guide users and sysadmins have not lived). Lately I have however concentrated through the design of GDM and the more advanced a lot more on school and actually finishing a degree setups, such as running multiple servers, customiz- and perhaps one day becoming a productive mem- ing the login, setting up XDMCP (with a complete ber of society. If you can be productive with a pure explanation of how XDMCP works), running X ter- mathematics degree is another question. minal labs with GDM, communicating with GDM us- ing the socket/pipe protocol. Also tips and solutions for problems in setups that users have encountered 2 GDM Design are interspersed throughout the discussion. Future planned enhancements are also given some attention. The basic design of GDM stresses security, modular- ity, robustness and user friendliness much more than XDM. GDM runs as a series of different processes, 1 Introduction with different privileges. The main GDM daemon process is the behind the scenes puppet master. It GDM, the GNOME Display Manager, is the login doesn’t by itself manage any sessions, however it has manager that is by now familiar to most GNOME information about all the other processes. This mas- users. It does a lot more than logging you in, it ter process is run as asynchronously and should never starts the X server, manages remote connections us- run operations which could cause it to hang even for ing XDMCP, allows users to shut down, reboot or a short while. It also handles communicating using suspend the machine and basically has to do all the the XDMCP protocol and using the local socket pro- behind the scenes stuff so that GNOME (or any other tocol, but it delegates all the the work of starting desktop) has an X server to start on. This is basi- and managing an X server and a session to a slave cally what the XDM software does, however GDM is process. A separate slave process is started for each a complete rewrite and shares no code with XDM. X server. This slave process can run synchronously, The KDE Display Manager on the other hand is ba- thus can hang when for example waiting on the X sically XDM retrofitted with a KDE style login box server, this makes the design a lot simpler, but is and setup program. also the source of many design headaches and thus GDM was originally written by Martin K. Pe- this may be changed later. After a session ends, the tersen, but he has since stopped maintaining it. He slave has two options. It either resets the X server and has for a while worked on GDM3, which was to be a puts up another login box, or it kills the X server and cleaner rewrite of GDM2, but this rewrite never hap- lets the master process run another slave for this dis- pened. GDM2 is really the second version of GDM play. The latter is now the default setup and should and this is the GDM currently in use and the one I be preferred because of security issues even though it am describing. Around the spring of 2001, GNOME 1 Using and Managing GDM is a little dirtier (there will be a short flicker between to exploit. Even if the user would somehow, perhaps sessions). The former is still left as a possibility since through some bug in GTK+, run perhaps a shell as some X servers are very buggy tend to lock the ma- the GDM user, he could not do much damage be- chine on such a complete restart. The slave sends all yond perhaps shutting down GDM or making GDM pids about its subprocesses to the master and so if the unusable, but he could do no worse to the system slave crashes, the master can clean up and try again. itself. Another example of why this is safer are for Of course crashing is considered very bad form, but example the Shutdown, Reboot Suspend and Con- GDM can handle crashes somewhat cleanly, and per- figure menus. Usually you would not want these on haps let the user log in. For a picture of how this all remote connections, however perhaps there might be looks see Figure 1. a bug (or an exploit) and the menu item would show up and a remote user might think he could shut down the server. But all the login dialog can do is relay this Master process information to the master process and then the mas- ter process sees if this display is even allowed to do a shutdown. GDM manages three different types of displays (X servers). The first type is the static X server slave slave which comes from the configuration file. Usually this is the X server set up for the :0 display slot, and it will always run. You can run several different X servers this way if you want. The second type of dis- X :0 X :1 play is the flexible (or flexi for short) X server. This X server is run on request by running the program gdmflexiserver or by clicking on the appropriate user login icon that is installed with GDM. The flexi server lets session a user log in once and then quits. This is for example useful if you are logged in as user A, and user B wants Figure 1: Structure of GDM Processes. to log in quickly but you don’t wish to log out. The X server takes care of the virtual terminal switching so it works quite transparently in fact. There is also a In the XDM design, the login dialog runs with flexi server as an Xnest, that is an X server in a win- the same privileges as XDM itself, that is root. So dow. This is requested by running gdmflexiserver a potential security hole in the GUI could compro- --xnest or again clicking on the appropriate icon. mise the system. GDM on the other hand sets up The last display type is an XDMCP connection. In an unprivileged user and the login dialog is run as this case there really isn’t any local X server run. The this user. It can only communicate with the slave X server runs on some remote machine and just re- that started it using it’s standard input and output. quests that it be managed for one session by the local The basic design is that the slave just gives it a series GDM. of questions and the login dialogs asks these ques- All the configuration for GDM is stored in a file tions of the user. When the user selects some action called gdm.conf and usually this is in the directory which is not an answer to a question, such as when /etc/X11/gdm. The directory depends on the local the user selects the configurator, the login dialog can installation of course. This is a plain text file with interrupt the question. However it is important to an ini style syntax. One of the many reasons that understand that the login dialog has very little infor- this is text only is that it is even possible to read mation about the user and has almost no privileges. from shell scripts. The standard distributed con- This can sometimes cause problems in the design, for figuration file has many comments which document example with the face browser. The problem here how to work with this file. The file isn’t reread as is that the pictures are only accessible to root since soon as it’s modified. You must tell GDM to restart they are in users directories. So the slave has to read for changes to take affect (see also Section 6). Al- in the .png file and send it over the standard input ternatively GDM can reread certain keys on the fly to the greeter. But despite these problems this is a without being restarted, but you must use the socket much safer and much more secure design than XDM. protocol to tell GDM about this. This is what is The login dialog is really in the position of the user, it used by the gdmsetup program to alert GDM to can only answer questions, so it would be very tough 2 Using and Managing GDM changes.