I have a unique set of requirements for my laptop which have turned the login process into a really unsatisfactory mess. But I have reconfigured a lot of programs and gotten it into reasonably good shape.
Various secrets must not be accessible to a thief who steals
the laptop when it is powered off or suspended (S3 state). This is implemented
by mounting an encrypted filesystem called the cryptographic vault
using the password given at login,
unmounting it and activating a screen lock when suspending, and remounting it
using the password given to the screen locker.
See my
writeup about the cryptographic vault.
I use Kerberos for initial and transitive authentication. Transitive authentication means that I authenticate once when I start my session, and I can get access to other services, specifically I can log in to other machines, without having to give my loginID and password again. The service provider or other machine can believe in the credential (basically, the Kerberos Ticket-Granting Ticket) stored when I started the session. See my essay about transitive authentication and authentication mechanisms in general.
The Kerberos database is encrypted with a master password hidden in the cryptographic vault. Mounting the cryptographic vault requires a password, but Kerberos can provide the ticket (encrypted with its hash of the password) only after the vault has been mounted and the master database key has been retrieved. This means that my login process is going to have chicken and egg issues: the vault must be mounted before I can be authenticated by Kerberos.
Similarly the network can be brought up only after the password of the Gnu Keyring has been given, enabling the WEP or WPA key to be retrieved.
Transitive authentication using SSH is also required, using a key agent. The program managing the cryptographic vault clears and reloads the SSH key agent when suspending; the private keys are in the vault even though encrypted.
PGP (GPG, Gnu Privacy Guard) is required for MIME-based cryptography. Its key agent is handled similar to SSH.
In an uncivilized location there may be no wireless service at all, and the login process must still be feasible. Kerberos' KDC (key server) does not listen to localhost and dies if no other network interface is up when it starts.
I use the same strong password for all the secret stores. Giving the password multiple times is to be avoided. A truly paranoid sysop would use a separate password for each service or storage location, so that if one password were lost only one service could be stolen, but I am not willing to put that much work into security; I would also have trouble to remember up to five different passwords long and complex enough to be strong.
The console user must receive permission to use raw devices, specifically the X-Server's direct rendering interface, the CDROM and the sound devices. Hotplugged devices must also be made available to the user, specifically USB mass storage (flash drives) and memory cards in the card slot.
The console user must be able to shut down or reboot the machine, preferably using the GUI features of the desktop environment's session manager, as well as GUI features of the display manager's greeter.
The requirement to start the Kerberos KDC with no network has been met by creating a loopback net by cowboy programming. The Perl package Linux::TunTap.pm was used; my script reads anything sent to it and retransmits it on the same interface. The KDC accepts this as a real network, and ticket requests can be made to its address and they will be seen and honored.
Here are copies of my network scripts. The network startup script is specific to SuSE Linux (OpenSuSE v11.1, presently) and contains bash-isms, earning hisses and boos from the Debian police: Debian policy is that all admin scripts that they distribute should work with any POSIX-compliant shell.
In former incarnations the network was configured statically and the home WEP key was present in the configuration file. Thus the network could come up early, before it was needed by programs like Kerberos. But it was always traumatic to use the laptop on outside nets, e.g. at work, or with no net. Also, having a WPA key in an unencrypted file violates the rule that secrets must not be made available to thieves.
I have changed over to NetworkManager. This program is controlled by nm-applet in the user's session, which talks to gnome-keyring-manager which stores the WEP or WPA key(s) in its encrypted file. nm-applet is nice enough to start gnome-keyring-manager if not running, which then asks for a password to decrypt the keyring. But I really want to have gnome-keyring-manager start and accept the password during PAM authentication. pam_gnome_keyring.so is available for this purpose.
As an additional feature, gnome-keyring-manager can act as a SSH key agent (but not as a GPG agent) and can load keys using the login password.
However, my login experience is unsatisfactory because the keyring
manager started by PAM cannot be found and used in the session. This essay
describes my efforts to heal
the login experience.
PAM, Pluggable Authentication Modules
, is a framework whereby
a broad range of programs that initiate sessions can use common infrastructure
and policies to handle authentication, authorization, session setup and
teardown, and password changing. Among the programs that use PAM are:
greeterfor serial lines and virtual consoles.
ata specified future time.
PAM's documentation is not wonderful, and many calling programs abuse the API. In particular, display managers are erratic in which entry points they call, what user they execute as, and what they do with environment variables set by the PAM modules. (However, in the past few years apparently a lot of work has been done to clean up PAM bugs that were present formerly.) PAM bugs have been the main motivation in the past and present for me to switch window managers.
For reasons discussed in the next section I am using wdm (WINGs Display Manger), but it has PAM bugs which are preventing a clean login, so once again I am searching for a replacement.
The display manager's job, on a laptop or desktop machine, is to start
the X-Server (or whatever alternate graphics server, e.g. on Microsoft Windows)
and then to run a program called the greeter
which
obtains the user's identity and credential (normally, loginID and password)
and then starts a session for the user. When the user logs out this cycle
repeats. Modern display managers may have several useful additional
features:
On a shared execution server typically the X-Server will be on a remote machine, but the server's display manager can put the greeter's window there and will then start a session that executes on the server but displays on the remote host. This host could be a dedicated X-terminal or could have a general-purpose operating system (Windows or even Linux) on which an X-Server functions as a client application for use with remote sessions. The protocol for getting the greeter onto a remote server is called XDMCP.
In the antediluvian world of teletypes and serial lines the display
manager's function is closely analogous to getty
, for which
login
is the greeter.
Wikipedia has this article about X display managers. It lists these display managers (sorted into categories and annotated by jimc):
XDM, the standard
display manager for the X Window System. It lacks glitz (and the
modern features
listed above) and has
been superceded by several more advanced competitors. Quite a long
time ago, PAM bugs motivated me to switch to a different display
manager: GDM.
GDM, the Gnome Display Manager. Formerly this was the one I preferred, but as of approximately version 2.24.x it got a radical rewrite, some important features (like customization of the greeter screen) were not carried forward, and new PAM bugs were introduced. Thus I abandoned it in favor of the following display managers.
KDM, for KDE. Since I do not use this desktop environment I have resisted installing its infrastructure just to get its display manager. However at work (where KDE is installed routinely) this is the replacement I have picked.
WDM, the WINGs Display Manager. Its advantage is that it is very compact and simple, making it a front-runner for a handheld computer. I have been using WDM on hosts where I didn't want to install KDM. However it has PAM bugs, specifically it does not copy the PAM environment into the user's session, and so I need to replace it.
SLiM, Simple Login Manager. Omits XDMCP (remote logins). As of 2009-05-xx they are looking for a new maintainer. It is said to be very lightweight yet flexibly configurable. Version 1.3.1 is available from the OpenSuSE Build Service. This one bears investigation.
Orthos, by [exa] in CZ.
It is very new and not exactly widespread, but the author says it
is beta, but mostly stable
. The author is active and
aggressive (in symbol space); latest page date noticed is only
3 days old. This one looks interesting.
Qingy by Michele Noberasco. It is a replacement for getty and can start text sessions as well as X sessions. Super lightweight, uses DirectFB as the graphics engine. Active development, last release (as of 2009-08-01) was 2009-05-11.
entrance, uses Enlightenment libraries. Last news on the page is in 2005, and the recommended way to obtain is from CVS (including the Enlightenment libraries). Not promising.
xlogin, curses based; the screenshot looks like an xterm but I think it's an equivalent text widget. As of 2009-07-xx the code is at the beta level and access control is not finished. I can't find any dates or progress indications. Not promising.
Enter. The last news on the web page is 2007-08-xx and the last source release on Sourceforge is similarly dated. The news suggests that it's about 60% through a major revision. Not promising.
dtlogin, for Common Desktop Environment, a non-free (costs money) environment formerly used with Sun's Solaris but since replaced with Gnome.
scologin, for the SCO Open Desktop. This desktop environment is not exactly widely used and suffers from negative political implications involving lawsuits by the parent company alleging intellectual property infringement against its alleged ownership of the UNIX/Linux kernel.
A major activity for this document will be testing display managers. I will confine my attention to the first two groups.
| Item | XDM | GDM | KDM | WDM | SLiM | Qingy |
|---|---|---|---|---|---|---|
| Pick session | NO | Yes | Yes | Yes | Yes | Yes |
| Shut down | NO | Yes | Yes | Yes | ? | NO |
| Custom look | Yes | Broken | Yes | Images | Yes | Yes |
| Bugs | Good | PAM probs | Good | PAM probs | Key focus | Seg fault |
| Environment | Yes | Can't tell | Yes | NO | Yes | Yes |
| Overall rating | Useable | Forget this | Useable oinkware | PAM bugs | Touchy | Touchy |
All the display managers have a configuration file or other means in which the location of the session scripts can be configured. For all of them I use /etc/X11/xdm.
All of the display managers run every one of the PAM phases as root.
XDM out of the box is its usual klunky self. Except for lacking support for picking the session and for machine control (shutdown), it is perfectly useable.
GDM failed to start Gnome Keyring Daemon, no indication why. The XDG_SESSION_COOKIE established by pam_ck_connector and dumped when PAM finished is not the one in the environment, and two sessions are shown by ck-list-sessions. A number of daemons were started as root which ought to run as the user.
To install KDM on a non-KDE machine required 72.4Mb of additional infrastructure. KDM manages to limit itself to only one session. I have a working custom greeter layout. It is acceptable, particularly if KDE has to be installed anyway.
WDM has a nice, simple greeter with little extra software
infrastructure required. Its one killer feature
is that it
does not propagate the PAM environment to the user's session.
This can be kludged around as indicated previously, but I would
rather use a display manager that works, PAMwise.
Orthos: I did a fair amount of work to figure out how to use it and to get it configured. Though I thought the docs said it used PAM, apparently this was wishful thinking. I never was able to log in; I suspect this may be because my password is hashed with MD5 and Orthos knows only about crypt hashes. (PAM can handle all reasonable hash types.) So unfortunately Orthos is disqualified.
SLiM: From the
OpenSuSE Build Service
I downloaded the SLiM main package version 1.3.1 and slim-themes.
I adjusted the configuration in /etc/slim.conf
to imitate xdm's behavior as much as possible. The default theme
works and gets me logged on. The flower2
theme, on the other
hand, does not accept keystrokes in the text boxes. Once the session
starts (default theme), the background persists as a fullscreen window,
which can be iconified, but closing it may or may not put something
into an infinite loop. I think I'm going to move on to the next
display manager.
Qingy: From the OpenSuSE Build Service I downloaded the Qingy package, version 0.9.9. I also downloaded the theme pack, qingy_0.3_themepack_1.0.tar.bz2 from qingy.sourceforge.net. (7 Mbytes uncompressed.) To install this,
cd /usr/share/qingy/themes
tar xjf /tmp/qingy_0.3_themepack_1.0.tar.bz2
mv qingy_0.3_themepack_1.0/* .
rmdir qingy_0.3_themepack_1.0
However I think I like the default
theme best.
I found
this forum posting by Snowman for configuring it; search for
here's how qingy works
. Qingy wants to find in its
configuration file two directories, one for X session files and one
for text sessions. The filenames end up in the session list (do not
append .desktop extensions). Each one should be
a script, may have to be a one-liner (no #!/bin/sh), needs to be
mode 755 (at least for the text sessions). It specifies the name
and arguments of the session leader; does not have to be a full
path name if it can be found on the PATH.
Unfortunately the DirectFB module gets a segfault. Forum posts indicate that there is a baleful interaction between v0.9.9, certain versions of DirectFB, and certain kernels, but nobody can reproduce the failure consistently. So I think Qingy is going to have to be deferred. It really looked promising and I'm disappointed.
So my attention returns to XDM. Apparently previous PAM bugs, that originally led me to switch to other display managers, have been fixed. I saw a screenshot in which the person did some pretty extensive customization of XDM. This led me to try to drag this program from 25 years ago kicking and screaming into the 21st century. But unfortunately I lost the URL -- sorry, person, I can't give you credit.
My main issue with XDM, actually with all the display managers, is that with the default configuration the login box goes right in the center of the screen. This is logical: the main purpose of the greeter display is to get your loginID and credential. But the greeter background has to be a solid color, a content-free abstract design, or a tiling of small images: a single image generally also has the main interest in the center, and the login box spoils it. The solution is to move the login box to an edge or corner. The XDM defaults also make it huge, and I needed to shrink it. Finally, the color had to be coordinated with the background photo.
These items were configured in /etc/X11/xdm/Xresources (download the complete file here) which is loaded on the X-Server before Xsetup_0 and the greeter are executed. Here are the key points:
You will certainly want to customize the greeting (title) text. Other texts can be customized as well.
The default geometry is to center the greeter, but this can be overridden. I put mine in the lower left corner. A negative location means to put the positive edge (here, the bottom) of the box that many pixels from the positive edge of the screen.
The size of the login box is mainly controlled by the font
size, which is huge in the default configuration. This spec cuts
it almost in half. See the man page for fonts.conf (section 5) for
the font name syntax that goes with libXft -- much nicer than the
original X-Windows font specs. Serif
is the CSS generic font
name and should be mapped to some reasonable actually installed font.
If you have a decorative favorite, specify it here.
This font is specially for the title line.
These specifications are phrased generically and hence apply to the xmessage and xconsole windows as well.
The xconsole is pushed to the lower right corner.
This is how you set the size of the xconsole; setting it through Console.geometry was ineffective.
I don't use the chooser. If you do, this section could use some love.
The second issue is that I would like to be able to switch session types and to shut down the machine from the greeter screen, like you can in all the other modern display managers. To make this happen I wrote a Perl script called Bootbox (download here) that uses one xmessage that tells the script to reboot or shut down the machine, and another to let the user choose a session type. The latter deposits the result in /var/lib/xdm/dmrc (not $HOME/.xdmrc or some such) since when this script starts up we don't know who the next user is going to be.
All the display managers go through their assigned PAM script and then run a system-provided script which execs the user's session. Here are key details needed to turn the login process from a mess to a joy.
In the login process a recurring theme is seen. You need a particular daemon to run for the life of the session. It can be started various ways:
A PAM module may start it, so that the login password can be sent in to decrypt secrets. When the session ends the display manager is supposed to call the appropriate PAM entry point to clean it up, at which point the module will take care of killing the daemon.
When starting the user's session the display manager eventually runs a script, typically /etc/X11/xdm/Xsession, which takes care of user-level session setup. The system administrator may have to modify this file to start the desired daemon. Most daemons have a launcher program which can take a command on its command line; this is the session leader or another daemon launcher (with its own commmand recursively). The daemon has a socket or other means by which programs can get service from it, whose name is passed to the sub-process in an environment variable. If you are allowed to use the bash shell, this motif can be useful, illustrated for dbus but repeated for all relevant daemons:
cmd=(exec)
if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] ; then
cmd+=( /usr/bin/dbus-launch --exit-with-session )
fi
# and add the other daemons
# Now add your favorite session leader
cmd+=( /usr/bin/startxfce4 )
exec "${cmd[@]}"
The session leader for a particular desktop environment may start the daemon, and will kill it when the session ends, assuming that the session leader does not get killed prematurely. In this case the daemon will write its socket name, normally on standard output, and the caller will capture the information and set it into the environment of the other child processes.
The user may need to start daemons in his session-specific startup script (~/.xsession or ~/.xinitrc), handling it similarly to Xsession.
Since the design of the login process is subject to change without notice, at each stage in starting daemons the designer should check if a previous step has already started it. One of my major problems has been that earlier and better daemon instances (e.g. started by PAM knowing the login password) are superceded by two or three more instances that are useless.
Similarly, be careful that the daemons get killed. The shared execution servers at work seem to accumulate stray dbus, gpg-agent and ssh-agent daemons.
In one of the PAM phases (typically authentication though authorization or session setup seems more useful) the module pam_ck_connector.so has to be executed to register the session that will start up. This operation must be done as root. The identity of the session is returned and is passed onward as the environment variable XDG_SESSION_COOKIE. Then the session leader, or one of the setup scripts, running as the user, must do the equivalent of /usr/bin/ck-launch-session, giving the session leader process on the command line. This simply confirms that the session is starting, executes the leader, and when it finishes, de-registers the session. To check what sessions have been registered you can use ck-list-sessions.
PolicyKit (as set up by the distro) has policies that restrict access
to physical hardware, including the network interface, to the
active
user(s), that is, those who are
logged in to the physical console, as opposed to users logged in remotely.
There is also a policy restricting shutdown and reboot to the active
user. HAL receives requests such as rebooting, and uses PolicyKit
to interpret the applicable policy. ConsoleKit is involved in identifying
which user is active
and in generating requests to HAL to grant
access to devices through POSIX ACLs or actual ownership changes.
Use getfacl /dev/whatever
to see the ACL, if there is one.
Thus successful session registration is important for my login requirements.
Look for a complaint like this in your ~/.xsession-errors file:
(nm-applet:3787): WARNING **: <WARN> applet_dbus_manager_start_service(): Could not acquire the NetworkManagerUserSettings service.
Message: 'Connection ":1.14" is not allowed to own the service "org.freedesktop.NetworkManagerUserSettings" due to security policies in the configuration file
(And nm-applet dies.) This is telling you that your process is not
allowed to own the service
"org.freedesktop.NetworkManagerUserSettings", i.e. to send user settings
to NetworkManager. The reason is that you are not an active
user,
i.e. logged in at the console, and the reason for that is that your
login scripts failed to successfully launch your session.
Every session needs a dbus so all the
components can chatter to each other. In a scripted session initiator
the right
way to start it is to run
/usr/bin/dbus-launch --exit-with-session
with the session leader
process on the command line. It starts the dbus daemon, executes the
session leader, and when it finishes, kills the daemon. The contact
socket for the daemon is passed onward in the environment variable
DBUS_SESSION_BUS_ADDRESS.
Kerberos transitive authentication, one of my login requirements, is not handled by a session daemon -- the Ticket-Granting Ticket is written in a file protected by UNIX file permissions -- but Kerberos authentication is one of the steps in setting up the session.
If you are going to be using PGP encryption you need gpg-agent running. It also can act as a SSH key agent if you tell it --enable-ssh-support. Put the session leader on the command line and the daemon will exit when the session finishes. The agent's contact socket is passed onward in the environment variable GPG_AGENT_INFO (which includes the agent's PID); the SSH agent socket is in SSH_AUTH_SOCK.
Getting gpg-agent into the session is one of my login requirements.
If you are going to do transitive authentication by SSH and if you use the authentic SSH key agent and not a Gnu substitute, you need to run ssh-agent. Put the session leader on the command line, and the agent will exit when the session finishes. The agent's contact socket is passed onward in the environment variable SSH_AUTH_SOCK. For killing the daemon its PID is also available as SSH_AGENT_PID.
SSH transitive authentication is one of my login requirements. But in practice I use the SSH agent facility of the Gnome Keyring Daemon.
This daemon does crypto operations and manages an encrypted file containing the relevant secret and/or public keys. It can serve as a SSH agent, can hold WEP/WPA keys for NetworkManager to use, and can handle X.509 (RSA) certificates and secret keys (but doesn't do PGP/GPG keys).
The Gnome Keyring Daemon serves two of my login requirements: SSH transitive authentication, and protecting the WEP/WPA keys of the wireless networks I use.
Here are links to the Gnome documentation about Gnome Keyring Daemon:
According to the documentation, there is a plugin for Firefox enabling the browser to use X.509 certificates in the keyring. This capability is important to me and I should get it working.
Here is the Gnome documentation about Seahorse-Agent. It appears to be a successor to the Gnome Keyring Daemon. But it has two problems for my use-case: it isn't in my distro (I have seahorse (the GUI) and seahorse-daemon, but no agent), and the docs do not describe any way to start it in PAM so as to use the login password to decrypt the secrets.
/usr/lib/hal/scripts/linux/hal-system-power-shutdown-linux or
/usr/lib/hal/scripts/linux/hal-system-power-reboot-linux
are execed by HAL when the user sends an appropriate dbus signal
and if policy allows the user to do these actions.
I have had my X-Server freeze up if killed in the middle of reinitializing
the graphics chip (ATI Radeon Mobility X1400, radeon
driver).
I have hacked the scripts to wait for the user's session to shut down
and for the greeter to reappear, before starting the shutdown.
If the machine shuts down, the effects of these scripts are seen to
happen; in other words, these scripts are the ones actually used.
ConsoleKit also has /usr/lib/ConsoleKit/scripts/ck-system-stop
and /usr/lib/ConsoleKit/scripts/ck-system-restart which exec
shutdown -h
(or -r). These must be a fallback if HAL is not
available.
ConsoleKit has a policy in
/usr/share/PolicyKit/policy/ConsoleKit.policy
which forbids shutdown to inactive users (those logged in at other than
the console or another defined seat), and allows shutdown to active
users if auth_admin
.
One prerequisite is that the session from which the shutdown request is issued must be an active session when HAL makes the decision whether to allow and execute the shutdown script. I suspect, but cannot prove, that xfce (at least) sends the dbus request to shut down, and then quickly exits. That invalidates the session, and the in resulting race condition the shutdown request sometimes loses.
See my script ck-launch-wrapper for a solution.
Formerly the sound devices, /dev/snd/*, on my laptop were not being made accessible to the console user, whereas the CDROM gets a POSIX ACL giving the console user permission for it. But on two desktop systems the sound devices also get the ACLs.
/usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
declares that the ALSA sound devices can be managed by HAL and
are in the sound
category.
(Uniform on working vs non-working hosts.)
/usr/share/PolicyKit/policy/org.freedesktop.hal.device-access.policy
declares that active users may access sound
category devices
(the sound card) and inactive users
(logged in to other than the console) may not.
With the new login scripts the sound devices are getting their proper POSIX ACLs. My guess is that once the various tangles in session registration were cleared up, the sound devices were properly made available.
As with the sound devices, the device files for direct rendering (/dev/nvidia* or /dev/dri/*) were not being made available to the console user. The reason is different, though: the proprietary fglrx (ATI/AMD) and nVidia graphics drivers are allowed to be used with the Linux kernel but are not allowed to create sysfs data about their graphics devices, because of peculiar legal issues with the Gnu Public License. Thus udev, HAL and ConsoleKit have no idea that they exist. So I added a script /etc/ConsoleKit/run-session.d/nvidia-ati.ck which sets the owner of /dev/nvidia* or /dev/dri/* to the console user by cowboy programming.
When an xorg driver such as radeonhd is used, this script is not necessary because ConsoleKit knows about the device and provides an ACL, but it doesn't break things if used.
This thoroughly hacked version of /etc/pam.d/xdm (or gdm) (download here), in conjunction with some Xsession hacks and additional nonstandard kludges, accomplishes all the login requirements. The account and password phases are written out below but the configuration file actually includes the standard common code scripts.
/etc/security/pam_env.conf if any. On my system
this file contains only comments. (Standard)
This is mostly standard stuff.
When the session is started and when it is closed, the listed modules are called at separate entry points.
/etc/security/limits.conf if any. (Standard)
you have [new] mailmessage. On a X-Windows login this generally just annoys the user, so I comment it out.
Most of this is standard stuff, but note these points:
nullokoption allows users to change an empty password, else empty passwords are treated as locked accounts.
use_first_pass: the module looks for the old password in storage, and if it is present and is incorrect for this authentication mechanism, the current module fails. Some modules will ask for the password if it is missing (and some will also fail).
try_first_passmakes the module ask for another old password if the stored one is incorrect. The default behavior is some combination of these. Check the module documentation.
use_authtokmeans to use the new password acquired by a previous module. If there is none the current module asks for it. This is generally what you want, but omit
use_authtokif each authentication mechanism has a different password.
The various PAM modules which start daemons set environment variables with the daemons' contact sockets etc. Some display managers, specifically wdm, fail to pass this environment to the user's session. If pam_dumpenv has been used to dump the environment to a file, the following addition to /etc/X11/xdm/Xsession can be used to reacquire it. It reports on stderr the disposition of each variable, and this report should end up in ~/.xsession-errors.
lsfile=/dev/shm/laptop_setup.$USER
if [ -r $lsfile ] ; then
echo "Setting environment from $lsfile" 1>&2
sed -e 's/=/ /' $lsfile | while read key val junk ; do
cmd="echo \$$key"
oval="`eval $cmd`"
if [ -z "$oval" ] ; then
echo "export ${key}='$val'"
echo " ${key}='$val' (was unset)" 1>&2
elif [ "$oval" = "$val" ] ; then
echo " ${key}='$oval' (unchanged)" 1>&2
else
echo " ${key}='$oval' (file wants '$val')" 1>&2
fi
done > $lsfile.xdm
. $lsfile.xdm
rm $lsfile.xdm
fi
Here are copies of all my hacked X session startup scripts, in order of being executed.
Xsetup_0: Runs as root before the greeter
starts. Because of the line DisplayManager._0.setup:
/etc/X11/xdm/Xsetup_0
in /etc/X11/xdm/xdm-config, this script
runs rather than Xsetup for display :0, the console. It is hacked
to start the Bootbox and xconsole.
Xstartup: Runs as root after the greeter has committed to start the user's session (but before it has actually started the session). Mostly this is the SuSE-provided script but there is an addition to kill the Bootbox and xconsole.
Xsession: Runs as the user and starts the session. It is based on the SuSE original but has been hacked extensively as discussed in this document.
wm.xsession: This file, written by jimc, is responsible for initializing the keyboard and starting the various service daemons.
wm2.xsession: This file, also written by jimc, loads private keys into the ssh agent, and then execs the window manager or other session leader.
Xreset: Runs as root after the session ends. This is actually the unhacked SuSE original file.
A Desktop Environment
is a coordinated suite of programs that
support use of X-Windows programs. The environment can vary in complexity
from a simple window manager with useful accompanying configuration files,
up to XFCE, Gnome or KDE which fill up 0.5Gb of your RAM.
/usr/share/xsessions contains desktop files for the installed desktop environments: KDE, XFCE, Gnome, etc. The display manager generally reads these files to discover their names and session leader programs. For completeness I have listed and briefly evaluated the desktop environments installed on my machine. However, my conclusion is foregone: I currently use XFCE and I'm not going to change. But it's useful to be familiar with the possibilities.
Except as noted, all the desktop environments ended up with one each of all the required service daemons, with the appropriate environment variables so applications can find them. If the network was brought up, both SSH and Kerberos could be used for transitive authentication on other machines. In the cases where the network was not brought up, SSH and Kerberos were tested successfully connecting to localhost. (Credentials were available.) Permission was checked for /dev/sr0, /dev/dri/card0, /dev/snd/controlC0 and the user got it (except as noted).
Nm-applet is autostarted and brings up the network. There is 1 session, is local, is not active. (ck-launch-session is not used.) Lacks permission for /dev/snd/controlC0.
Nm-applet was not autostarted but it brings up the
net if started by hand.
There are 2 sessions, both local, 1st is active, 2nd isn't.
(ck-launch-session is used.)
The fvwm2 configuration has been locally hacked but SuSE
provides a flashy default.
At startup the local hack gives you a taskbar with four workspace
groups and two menus for programs. Left-middle-right click
in the background for window manager action menus.
FVWM is configured with smart placement
, i.e. the
windows appear without overlapping existing windows (if
possible). It is also configured for focus-follows-mouse.
Nm-applet was autostarted and brought up the net. Could not test kerberos and ssh due to daemon problems. There is 1 session, local but not active. (ck-launch-session is not used.) Lacks permission for /dev/snd/controlC0. At startup you're presented with a taskbar with four workspace groups. The problem here is how to get the main menu, and from there, how to start an xterm. I think I have failed to install some required packages. Limited testing was done by flipping to a text console and starting an xterm from there.
Not installed on the test machine.
Nm-applet was not autostarted but it brings up the
net if started by hand.
There are 2 sessions, both local, 1st is not active, 2nd is.
(ck-launch-session is used.)
At startup you're presented with a taskbar with four workspace
groups; the main menu is
available from the logo there, or right click in the
background.
IceWM has smart placement
, i.e. the windows appear
without overlapping existing windows (if possible).
The default is click-to-focus (annoying), but this can be
configured for focus-follows-mouse.
Network is not up: nm-applet was not autostarted and
I didn'to test starting it by hand.
There are 2 sessions, both local, 1st is not active, 2nd is.
(ck-launch-session is used.)
At startup you're presented with a
gray screen. Right click in the background for a menu of
window manager actions -- the key one is New Window
,
which means to launch xterm.
MWM has cascade placement
, i.e. the windows appear in
a nonadaptively computed location on the diagonal of the
screen. You always have to move the window. This is annoying.
MWM also has click-to-focus, also annoying.
Network is not up: nm-applet was not autostarted and
didn't test starting it by hand.
There are 2 sessions, both local, 1st is not active, 2nd is.
(ck-launch-session is used.)
At startup you're presented with a
gray screen. Left click in the background for a menu of
window manager actions -- the key one is xterm
.
TWM does not have smart placement
, i.e. for each window
you need to individually pick its location. This is annoying.
Network is not up: nm-applet was not autostarted and didn't test starting it by hand. There are 2 sessions, both local, 1st is active, 2nd isn't. (ck-launch-session is used.) When it starts up you get a taskbar at the bottom. It would help to find/read the documentation, but it looks like this WM may be functional.
Network is not up: nm-applet was not autostarted and didn't test starting it by hand. Session is registered and active but is not local. All you get is one xterm and no window manager. The purpose of the failsafe session is to straighten out messes in your normal desktop environment or customized startup script.
This is a special case among session types: it does not start any service daemons, but rather runs the user's .xsession or .xinitrc file (or /etc/X11/xdm/sys.xsession if neither exists). Then the user can start whatever service daemons or session leader he pleases, without having to fight with the system's idea of what a desktop environment should be doing to the user.
I believe I may not have session registration set up perfectly for the unfamiliar session managers. Similarly, I have a feeling that the lacking permission for /dev/snd/controlC0 may not be the responsibility of the session manager but rather of session registration.
There are an awful lot of interacting items needed to get a user logged on. After a fair amount of research I have my login procedure pretty much working the way I want.