Joerg: As you probably know, the Desktop team has worked hard over the years to make sure that GDM works well on Sun Ray. Our plan is to ensure that the new GDM rewrite also works well on Sun Ray. That said, there will probably be a few pains in making the transition. However, in the long run, I think this is a good thing. Since Sun Ray supports various Linux distros, it is important to work with the upstream GDM community and resolve issues in a way that will work across all distributions that SRSS supports.
>> By default GDM now displays all users on the system in a face browser >> so the user can select the username from a list and then enter the >> password. The most frequent users are displayed first and the list >> of frequent users is obtained using the ConsoleKit /usr/bin/ck-history >> interface. > > Displaying all users should not be enabled by default, especially if a > name service other than files is active, which may generate a far too > long list of 'faces' to be useful. As has already been discussed, GDM does things to limit the number of users shown in the Face Browser so that only users defined on the local system with a valid shell defined in /etc/passwd are shown. If a user actually logs in with a non-system account (e.g. via NIS), then that user will be shown in the face browser on subsequent logins. Agreed, the Face Browser is probably not suitable for some Sun Ray deployments where the list of users would be expected to be too large to be useful. If we decide to enable the Face Browser by default in Solaris, then the Sun Ray install script would likely need to change this setting when the SRSS software is installed. Currently, SRSS changes a number of default GDM settings, so this should not be a problem. > This would be less of an issue, if the face browser were restricted to > only users reported by ck-history --frequent, maybe with a limit on > number of users shown. Is there such a mode? (It might even make face > browser useful for cases like Sun Ray or large network environments.) It already works with ck-history --frequent as you suggest. Currently there isn't a way to limit the number of users which are shown, but one could be added if this were seen as valuable. > Face browsers usually look for a user-provided face image in the user's > home. As mentioned by others there are credentials issues with this and > this also would have undesirable effects with large user lists and > networked home directories. Correct, there are opportunities to make the Face Browser work better in such environments if we think it would be a useful feature. Note that the old GDM also had a Face Browser, which worked much less well than the one in the new GDM. While the new Face Browser may not be perfect yet, it is considerably better than the old Face Browser. The old GDM Face Browser, for example, would always try to show all users on NIS - so the new Face Browser is an improvement. >> The face browser includes an "Other" choice which allows >> the user to avoid using the face browser and enter the PAM prompts >> directly (e.g. username and password) if they wish. This "Other" >> choice is needed, for example, to login as a system user, since system >> users are not displayed in the face browser. The face browser feature >> can be disabled via configuration so that users simply enter responses >> to PAM prompts. For example, many Sun Ray users would likely want to >> disable the Face Browser. > > Does this mean that PAM is not even started before a user is selected, > if the face browser is enabled? Correct. > That makes face browser incompatible with PAM modules that preset a user > name known from elsewhere, without prompting interactively (such modules > are for example used by various Sun Ray features). Yes and no. This is an area where we need to do some additional work. The way the GDM rewrite works is that the PAM dialog is not started when the dialog GUI is first drawn. The login GUI has a "Log In" button which you must press to start the PAM process. When the Face Browser is used you can just select the user and click "Log In" to start the PAM process, and the user is pre-filled so that only the password is requested. One advantage of this approach is that it should be trivial to make the new GDM work with the NSCM process. It is possible to launch the GUI, have the user select the session/language, and then when the user clicks the "Log In" button, the PAM interaction is started and the session should just startup if PAM requests no input. One way to make GDM avoid painting the dialog currently is to set the GDM configuration so AutomaticLoginEnable is set to true and AutomaticLogin is set to a valid username. If you turn this on, then GDM does not paint the dialog and will start the PAM stack with the pre-filled username. However, if your PAM stack overrides the username, then I'd think that this would cause GDM to log in as the user defined in your PAM stack rather than the user defined in the GDM AutomaticLogin value. It is a bit ugly that you need to define AutomaticLogin to a valid user that is ignored. We could perhaps enhance GDM to allow you to specify a special key that indicates "the PAM stack will fill this in" if that is desirable. Another approach would be to add back a feature that the old GDM supported. You could set AutomaticLogin to "!scriptname" and that would then run a script that would return the username to use. It is passed the DISPLAY and $USER environment variables so that the script can pick the username based on those settings. This feature was lost in the rewrite, but it would be trivial to add back if you think it would be better to use this interface. One advantage of using the "!scriptname" feature is that if the script returns an invalid username, then AutomaticLogin is not used for that login session. So, if you want to support the ability to use AutomaticLogin sometimes, but not others, then this script approach could facilitate that. You could just write a script that passes back the username when you want to AutomaticLogin, and an invalid username when you don't. Otherwise, in the GDM 2.30 timeframe, there is a plan to rewrite the GUI so that the PAM interaction is handled via plugins. The current code for accepting username/password will be moved into a plugin. So, when that is done, you could reconfigure GDM to not use the default plugin and instead use your own plugin. In talking with Ray Strode, who is working on this new feature, it will be possible to make such plugins start the PAM conversation immediately without needing to press the "Log In" button. So, this could be another approach if the AutomaticLogin configuration option can not be made to work for some reason. That said, I think getting this to work with AutomaticLogin, if possible, would be the better approach. >> Once the user has entered their username, or selected it via the >> face browser, the panel shows interfaces for selecting the session to >> log into and the language to use. > > How does the greeter behave, if the PAM stack requires no further user > interaction (i.e. does not call the PAM conversation function again)? As I say above, if you use the AutomaticLogin feature in GDM, then the GUI isn't painted. If you can not use AutomaticLogin, then it will likely be necessary to wait until GDM 2.30 when it supports the PAM module plugin feature. > There are some scenarios, for example with Kiosk Mode (LSARC/2006/171) > or Sun Ray where this may occur. Essentially this is about using PAM for > setting an 'autologin' style authentication policy. Can you use GDM's AutomaticLogin? It avoids displaying the GUI, so it would be best if you could use that. > How is (UI) language selected *before* the user has entered/selected a > user name. Is there any memory of the language to use? GDM uses the $HOME/.dmrc file to use the last selected session and language. We are talking about moving the $HOME/.dmrc file to /var/cache to avoid issues with kerberos and the issues you mention below. >> If there is only one session type >> installed on the system, the session selection interface is not >> displayed and GDM assumes the user will log the user into that one >> available session. The user's default choices for session and language >> are automatically selected, so the user only needs to select them on >> first-time login or if they wish to use a non-default value. If a >> non-default value is selected, GDM automatically makes it the new >> default value for that usre in subsequent logins. > > How and where are these values stored? Does the GUI show what the > default choices are or does it only say somwthing like "same as last time"? > If they are supposed to be taken from $HOME/.dmrc: As explained by > someone else, the user's home directory may not be available (e.g. due > to lack of credentials) and should not be accessed even if available (to > prevent security downgrade) at the time when the information is needed > to initialize the GUI choices. Yes, the GUI knows about the choices and there are plans to move the .dmrc file to /var/cache so the GUI can access the values without worry about being able to access the user's $HOME directory. >> The new GDM also makes use of the GNOME infrastructure by using >> gnome-session, the gnome-settings-daemon, and the metacity window >> manager to run the graphical login program. The old GDM did not use >> these, and instead used its own light window manager for example. > > What is the lifecycle of these programs, particularly when using the > 'gdm-simple-slave', where IIUC the login session is on the same display > that is subsequently used for the user session? Will a fresh > gnome-session with all the bells and whistles be started whenever a new > login begins and torn down after login and before the sessions starts. Correct. GDM starts up gnome-session, gnome-settings-daemon and metacity. Then after authentication they are torn down, and the user session is started. GDM does provide some configuration defaults for gnome-settings-daemon so that it only loads modules which are needed by GDM to help save resources. > (I'm concerned about performance/resource impact on (massively) > multi-seat systems) The new process will likely be a bit more resource intensive than the old GDM. Fortunately, people don't spend most of their time using the GDM program, so I wouldn't think it would affect the overall performance so greatly. >> There are some regressions when using the new GDM. Refer to section >> 4.1.15 for more information. >> >> Note that GDM now provides two types of slaves: >> >> - The gdm-simple-slave which works similar to the old GDM where it >> manages a single active session at a time. > > See above: does this mean that the login session and the user session > run sequentially on the same display? Yes. The login session is torn down and the user session started. Actually the old GDM also did this. The old GDM had its own "light" window manager, for example, which was handled in much the same way as metacity is handled in the new GDM. However, the new GDM does use more of the GNOME infrastructure for its session. Some features could be turned off. For example, by default, the new GDM adds the power manager applet to the GDM panel so that laptop users can see how their battery is doing from the login screen. This wouldn't be useful in a Sun Ray environment and could be turned off to further save resources. >> 4.1.1 Detail About GDM Program Interfaces >> >> - /usr/sbin/gdm-binary [--debug] [--fatal-warnings] [--timed-exit] >> [--version] >> >> The main GDM process. It supports arguments for debugging and for >> printing the version number. One difference with the previous version >> of GDM is that the main process no longer runs as a daemon. >> The gdm-binary program spawns slave processes as needed for each >> display that needs to be managed. > > Does "no longer runs as a daemon" mean that the main process exits after > having spawned all slave processes for static displays (i.e. that the > console-kit-daemon takes the role of the old gdm main daemon after > startup of static displays)? No, it just means that the main GDM process does not daemonize itself. It still runs all the time. For example, if you look at the /lib/svc/method/svc-gdm script, the old GDM started by running /usr/sbin/gdm. The new GDM starts by running "/usr/sbin/gdm &". That's the main difference. >> - /usr/bin/gdmdynamic [--add=DISPLAY | --delete=DISPLAY | --list ] > > This still allows specifying the X server to start when adding a > display, doesn't it? Correct. >> This program calls ck-seat-tool to start or stop a session on a given >> display and calls ck-list-sessions to return a listing of displays >> previously started via ck-seat-tool. This interface will be used by >> Sun Ray for starting and stopping sessions on Sun Ray devices, but >> could also be used for dynamically managing other kinds of displays. > > How are ConsoleKit seat-ids for dynamic sessions assigned/selected by > this tool (and/or ck-seat-tool)? Probably a better question for the ConsoleKit case, and Halton would be better at answering it. Could you pose this question in that case (LSARC 2009/432)? I am sure Halton will respond. >> The /usr/share/gdm/gdb-cmd command script runs the following: >> >> bt >> thread apply all bt full >> q >> >> If the call to gdm-crash-logger fails to return with a valid return >> code, then GDM uses fallback code that calls backtrace (3C) >> and prints the output to the syslog. > > ... and find it surprising that the log output I get (and I have to > assume that the gdb variant somehow delivers richer information) depends > on whether a certain, otherwise unrelated debugger package is installed > on the system. No, we should probably fix the code so it uses the Sun Studio debugger instead. That is just how the code works today. There are just other more serious things to work in GDM right now (like all the other issues you have identified). The gdb interfaces do provide a readable stacktrace, so there is not a real need to change it now, unless ARC insists. >> - /usr/lib/gdm-host-chooser >> - /usr/lib/gdm-simple-chooser >> >> The XDMCP chooser GUI program. gdm-simple-chooser is intended to >> be launched from the login GUI > > 4.1.15 says: > >> - GDM no longer provides the ability to start the chooser program from >> the login greeter GUI program. > > So which is it? GDM no longer provides the ability to start the chooser program from the login greeter GUI program. There is a /usr/lib/gdm-simple-chooser, but it isn't yet integrated into the login GUI. >> - /usr/lib/gdm-user-switch-applet >> >> The Fast-User-Switch-Applet. When VT is enabled, this applet allows >> users to quickly switch to a login screen on a separate VT. The >> username value will be pre-filled if the user has selected a user in >> the applet, so the user only needs to enter the password. Therefore, >> this feature may not be useful with some PAM stacks. > > Does gdm-user-switch-applet use the same PAM stack as regular gdm login? Yes, though it only works on VT sessions on the console. > PAM clients that supply a user to pam_start(3PAM) are quite common. Are > you thinking of specific PAM stacks that would fail in this scenario? The User Switch Applet is only designed to work in environments where VT is available. On Sun Ray environments, it should be disabled. >> 4.1.2 GDM autostart mechanism >> >> The /usr/share/gdm/autostart/LoginWindow directory contains desktop >> files which follow the FreeDesktop Desktop File Specification. Any >> programs which have a desktop file installed will be automatically run >> in the login session. So if the user desires any additional programs >> to start with the login GUI, it is possible to add a desktop file to >> this directory to do this. >> >> This directory contains the following desktop files, so these programs >> are always launched in the GDM greeter GUI session: > > Will all of these be first launched and then terminated, even if > 'automatic login' is configured or no user interaction is ever requested > by the PAM stack? They are only run if the GUI is started. When AutomaticLogin is used, no GUI is started. Some of the desktop files only launch programs if particular GConf keys are set (e.g. the a11y related ones). >> The autostart directory also contains the following accessibility >> related desktop files so that these programs are autolaunched if the >> user has set the appropriate GConf keys for the "gdm" user. > > So these options (and the greeter ones further below) will apply to all > logins on all seats! Are there any controls (e.g in the panel widgets) > by which the current user can control these settings, thus affecting > subsequent logins? For the greeter settings the answer is definitely yes > from the specification below. Right. This is a bug in GDM. There are plans to separate the GDM GConf settings so that each display has its own configuration settings. However, I do not think this will be fixed in the 2.28 timeframe unless this becomes a TCR. If it does become a TCR, I think it will cause GDM to slip this release, so would it be acceptable to live with this bug for a short while? If so, I am sure we can fix it early in the 2.30 release cycle. > For any such settings: How does this affect concurrent logins in a > multi-seat environment? Will concurrently running sessions change > behavior on the fly when notified? Yes. Until the above bug is fixed, it would probably be best to disable the accessibility autostart files in multi-user environments. >> - at-spi-registryd-wrapper.desktop >> >> If the /desktop/gnome/interface/accessibility GConf key is set for the >> "gdm" user, then this ensures the at-spi-registryd process is >> started. >> >> - gnome-mag.desktop >> >> If the /desktop/gnome/applications/at/screen_magnifier_enabled GConf >> key is set for the "gdm" user, then gnome-mag will be autolaunched. >> >> - gok.desktop >> >> If the /desktop/gnome/applications/at/screen_keyboard_enabled GConf >> key is set for the "gdm" user, then gnome-mag will be autolaunched. > > Should probably be gok, not gnome-mag?! Right. Good catch. Updated in the onepager. >> - orca-screen-reader.desktop >> >> If the /desktop/gnome/applications/at/screen_reader_enabled GConf key >> is set for the "gdm" user, then gnome-mag will be autolaunched. > > Should probably be orca, not gnome-mag?! Thanks, also fixed. >> In addition, GDM integrates with libwrap so the sysadmin can control >> which hosts may connect via XDMCP. >> 4.1.4 Detail About GDM Greeter Configuration >> >> The GDM greeter supports configuration via GConf settings stored in >> the gdm user's $HOME directory. Default values are stored in the >> gdm-simple-greeter.schemas GConf file. The sysadmin is expected to >> change the GConf settings in the gdm users $HOME directory. This >> can be done via the /usr/bin/gconftool-2 or /usr/bin/gconf-editor >> tools. > > See the questions in 4.1.3. These seem even more urgent here, as the > 'recent-*' settings are specified to be updated by the greeter. Right, the recent-* settings are the only settings that the GDM GUI actually writes to. > Also as those are supposed to be cumulative: will 'survival' of > additions be a matter of races and seeming randomness in case of > concurrent multi-seat logins? And shouldn't these really be per-seat, > when considering globally distributed scenarios like Sun Ray? Yes, there are plans to make the GDM GUI GConf settings per-seat to resolve this issue. There may be a bit of weirdness caused by race-conditions, though I do not think it would be a huge problem. At worst, it might cause some language choices to not be recognized as recently selected. It shouldn't be an issue for session selection since we only deliver two session files, so users won't change them much and are unlikely to run into race conditions. >> - /var/lib/gdm >> /var/lib/gdm/.gconf.path >> /var/lib/gdm/.gconf.mandatory/%gconf-tree.xml >> >> /var/lib/gdm is the default $HOME directory for the GDM user. This >> directory contains standard GConf files where the user can store >> modified configuration options. Though users would likely use >> the /usr/bin/gconftool-2 or /usr/bin/gconf-editor programs to modify >> the settings instead of modifying the files directly. >> >> The /var/lib/gdm/.gconf.path file is a standard interface that is >> loaded by the /etc/gconf/2/path file after loading the system GConf >> mandatory settings. This file simply specifies that the >> /var/lib/gdm/.gconf.mandatory override any normal system settings. > > So this means that *mandatory* system settings set by an administrator > will apply to login sessions (and not be overrideable). IOW an admin > can't set up mandatory settings for user sessions any more without > imposing the same settings on login sessions (or performing tricky > /etc/gconf/2/path surgery). Yes, normal mandatory settings will apply to the GDM login GUI unless the GDM user's mandatory settings override them for a specific key. The only keys that are specified in the GDM user's mandatory settings are settings that are specific to the login GUI. For example, to lockdown features in the login GUI that are desired in a normal environment, but not desired in the login GUI. >> The /var/lib/gdm/.gconf.mandatory/%gconf-tree.xml file specifies >> configuration settings that are specific to GDM. For example, these >> settings are used to lockdown the session used while the GDM GUI is >> showing. For example, keybindings are disabled so the user can not >> use normal keybindings to launch applications. > > But system mandatory settings made by an admin may (inadvertently) break > this lockdown?! No, the GDM user's lockdown settings override the system mandatory settings. Is there a specific key you are concerned about? I have attached the GDM mandatory settings in the attached "%gconf-tree.xml" file. You can review them. I think you will agree that they are all reasonable settings for the login GUI. >> 4.1.15 Regressions >> >> The new GDM does not support the degree of configurability that was >> supported by the older GDM. Many features were removed since they >> were seen as being unnecessary. > > In the light of this and various other incompatibilities with older > configuration and runtime interfaces: > > Is there an interface by which PAM modules and/or scripts (e.g. > Init/PostLogin/PreSession/PostSession/user session) can recognize that > they are being run under the new GDM rather than old GDM? Running "gdmflexiserver --command VERSION" will report the version number of GNOME using either the old or new GDM. > Is the PAM service name used still the same (i.e. 'gdm'). It is "gdm" for normal login and "gdm-autologin" for Automatic Login. Same as the old GDM. >> /usr/bin/gdmdynamic Volatile See 4.1.1. > > In light of the intent to keep this only for Sun Ray use and to remove > to when Sun Ray no longer needs it, should this not be classified > 'Obsolete Volatile' to clearly discourage new uses? Good point. Updated in the onepager. >> Obsolete Interfaces Stability Comments >> ---------------------------- ----------------- ----------------------- >> >> Note section 4.1.15 which discusses regressions associated with these >> obsolete interfaces. Also note that GDM interfaces were defined as >> Volatile in "LSARC 2008/207 GNOME 2.22". > > Are these interfaces removed or are they really just marked Obsolete? In > the latter case what do they do now? All of the interfaces marked as Obsolete in this case are removed except for /usr/bin/gdmdynamic. My fingers hurt. Brian
