A bunch of questions and concerns from me inline.
Brian Cameron schrieb: > 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. 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.) 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. > 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? 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). > 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)? 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. How is (UI) language selected *before* the user has entered/selected a user name. Is there any memory of the language to use? > 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. > 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. (I'm concerned about performance/resource impact on (massively) multi-seat systems) > 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? > - The gdm-factory-slave and gdm-product-slave which runs a login > screen all the time on a VT. When users authenticate the session > is > started in a different VT. This model supports better user > switching. > > The gdm-factory-slave/gdm-product-slave are experimental and disabled > by default. It is necessary to recompile the code to enable them. > Therefore these binaries are not shipped with the Solaris packages. > Only the gdm-simple-slave greeter binary is shipped with Solaris. > > 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)? > - /usr/bin/gdmdynamic [--add=DISPLAY | --delete=DISPLAY | --list ] > This still allows specifying the X server to start when adding a display, doesn't it? > 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)? > To use gdmdynamic, it must be run as the same user which is running > the main GDM and ConsoleKit daemons, which is normally root. > Otherwise the request is ignored. > > Currently this program is added by a Solaris specific patch for > backwards compatibility. When the Sun Ray product fully integrates > with ConsoleKit, this will be removed. > > - /usr/lib/gdm-crash-logger > - /usr/share/gdm/gdb-cmd > > If any GDM process receives the following signals, then the > gdm-crash-logger program is run: SIGSEGV, SIGBUS, SIGILL, SIGABRT, > SIGTRAP, SIGFPE, or SIGPIPE. > > gdm-crash-logger runs the following command to get a stack trace, > then prints the stack trace to the syslog. > > gdb --batch --quiet --command=/usr/share/gdm/gdb-cmd --pid=PID > I don't see gdb in the Imported Interfaces table.... > 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. > - /usr/lib/gdm-simple-slave > > A slave daemon that runs the gdm-simple-greeter directly. > > - /usr/lib/gdm-session-worker > > A separate process which handles PAM/audit interactions. The > gdm-simple-slave interacts with it via the gdm-session D-Bus > interface. The gdm-simple-slave interacts directly with > gdm-session-worker, while gdm-factory-slave uses a relay connection. > > - /usr/lib/gdm-simple-greeter > > The default login GUI program. Used both by gdm-factory-slave and > gdm-simple-slave. > > - /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? > while gdm-host-chooser is an > application which can be launched with the user runs the Xserver > with > the -indirect flag. > > - /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? 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? > 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? > - gdm-simple-greeter.desktop > > This starts the GDM greeter itself. > > - gnome-power-manager.desktop > > The gnome-power-manager is launched with GDM so that GDM can report > on the battery state. > > - gnome-settings-daemon.desktop > > gnome-settings-daemon is always started with GDM. > > - metacity.desktop > > The metacity window manager is always started with the GDM greeter. > > 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. 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? > - 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?! > - 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?! > Note that many of these desktop files use the FreeDesktop Autostart > Specification and the FreeDesktop Startup Notification Specification > to > ensure that they autorestart if necessary. > > 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. 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? > - /apps/gdm/simple-greeter/recent-languages > > String value. This is set to a list of languages to be shown by > default in the login window. Default value is "[]". With the > default setting only the system default language is shown and the > option "Other..." which pops-up a dialog box showing a full list > of available languages which the user can select. > > Users are not intended to change this setting by hand. Instead GDM > keeps track of any languages selected in this configuration key, and > will show them in the language combo box along with the "Other..." > choice. This way, commonly selected languages are easier to select. > > - /apps/gdm/simple-greeter/recent-layouts > > String value. This is set to a list of keyboard layouts to be shown > by default in the login panel. Default value is "[]". With the > default setting only the system default keyboard layout is shown and > the option "Other..." which pops-up a dialog box showing a full list > of available keyboard layouts which the user can select. > > Users are not intended to change this setting by hand. Instead GDM > keeps track of any keyboard layouts selected in this configuration > key, and will show them in the keyboard layout combo box along with > the "Other..." choice. This way, commonly selected keyboard layouts > are easier to select. > > Note that this feature is only available if libxklavier is available > on the system. On Solaris, it is not, so the layout widget is > never shown. > > - /apps/gdm/simple-greeter/wm_use_compiz > > Boolean value. If true, compiz is used as the window manager > instead of metacity. Default is false. > > 4.1.5 Detail About GDM Script Interfaces > > GDM supports the following script interfaces > > - /etc/gdm/Init > - /etc/gdm/PostLogin > - /etc/gdm/PreSession > - /etc/gdm/PostSession > > The Init script is run when a display is managed and after the > Xserver has started, but before the greeter program is shown. > > The PostLogin script is run after a user has successfully > authenticated, but before any session setup has been done, including > before the pam_open_session call. > > The PreSession script is run after the user session has been > initialized, but before starting the user session. > > The PostSession script is run after the user session exits, when the > user terminates their session. > > The above four interfaces are directories which contain a Default > script. This Default script is run by default. The directories can > also contain a per-display script with a DISPLAY name, such as ":0". > If such a per-display script exists, then it is run instead of the > Default script. > > - /etc/gdm/Xwilling > > Refer to the "xdmcp/Willing" configuration setting in section 4.1.3. > By default, no such script is installed, but the script will work > as described in section 4.1.3 if present. > > 4.1.6 Detail About Other GDM Interfaces > > - /usr/share/xsessions > > All display managers which follow the FreeDesktop Desktop File > Specification use this directory and expect all available sessions > to have installed a desktop file in this directory. These desktop > files are in the format specifies by the FreeDesktop Desktop > Specification. The /usr/share/xsessions file location is not > a part of the specification, but is a de facto standard supported > by all popular FreeDesktop display managers such as GDM and KDM. > > For example, the gnome-session module installs a gnome.desktop file. > Such desktop files specify what program to run to start the session. > When using GDM, the specified program for the session is run by the > /etc/gdm/Xsession script. > > If only one desktop file is installed to this directory, then GDM > does not bother to show the user a dialog to select the session and > assumes to start the only available session. > > - $HOME/.dmrc > > This file contains the user's default language and session choices. > Unless the user picks a different language or session in the greeter > dialog, the choices from this file are used. If the file does not > exist, it is created on first-time login with the choices selected. > > This file is in standard INI format. For example, a file could > contain these lines: > > [Desktop] > Session=gnome > Language=cs_CZ.UTF-8 > > - /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). > 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?! > 4.1.7 Detail About Other GDM Environment Variable Usage > > When GDM runs various internal processes the GDM_CHOOSER_DBUS_ADDRESS > and GDM_GREETER_DBUS_ADDRESS environment variables are set so that > the D-Bus address of the chooser and greeter can be accessed. > > GDM GUI programs access the GNOME_ACCESSIBILITY environment variable. > If set, it will start the accessibility registry so that > accessibility > programs work. This environment variable gets set by gnome-session > if the "gdm" user has configured accessibility to be enabled. > > GDM GUI programs access the DESKTOP_AUTOSTART_ID. If set, it will > register itself with the session manager. This way the greeter will > auto restart if it crashes. This environment variable will normally > be set by the session manager because the gdm-simple-greeter.desktop > file (discussed in section 4.1.2) specifies > X-GNOME-Autostart-Notify=true. > > Also, common environment variables such as G_DEBUG and GTK_MODULES > also affect GDM in the expected manner. > > When starting a user session the following environment variables are > set: > > DESKTOP_SESSION - Set to the session name the user has chosen, > such as "gnome" when logging into the GNOME > desktop. > GDMSESSION - Set to the same value as DESKTOP_SESSION. > LANG - Set to the language choice selected when the > user logged in. > GDM_LANG - Set to the same value as LANG. > GDM_KEYBOARD_LAYOUT - Set to the keyboard layout choice selected when > the user logged in. > > DISPLAY - Set to the DISPLAY value. > HOME - Set to the user's $HOME directory. > LOGNAME - Set to the username logging in. > PATH - Set to "/usr/bin". However, if the > /etc/default/login file specifies a value for > PATH it is always used; except for the root > user, which uses the SUPATH value. > SHELL - Set to the user's shell. > USER - Set to the username logging in. > USERNAME - Set to the username logging in. > XAUTHORITY - Set to the location of the Xauth file. > XDG_SESSION_COOKIE - Provided by ConsoleKit and passed along to the > user session. > > When running scripts (such as Init, PostSession, PreSession, > PostSession), the following are set so that the scripts can access > user information. Note that in the case of the Init script, > username is not set so getpwname will not return valid values. > > HOME - If getpwname returns a valid $HOME directory, it > is set to that value, otherwise set to "/". > PWD - If getpwname returns a valid $HOME directory, it > is set to that value, otherwise set to "/". > SHELL - If getwpname returns a valid shell, it is set to > that value, otherwise set to "/bin/sh". > > DISPLAY - Set to the DISPLAY value. > LOGNAME - Set to username of user logging in. > REMOTE_HOST - Set to the hostname if non-local (e.g. XDMCP). > RUNNING_UNDER_GDM - Set to "true" > USER - Set to username of user logging in. > USERNAME - Set to username of user logging in. > XAUTHORITY - Set to the location of the Xauth file. > > When starting the Xserver, the following environment values are set: > > DISPLAY - Set to the DISPLAY value. > HOME - If getpwname returns a valid $HOME directory, it > is set to that value, otherwise set to "/". > SHELL - If getwpname returns a valid shell, it is set to > that value, otherwise set to "/bin/sh". > XAUTHORITY - Set to location of the Xauth file. > > 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? Is the PAM service name used still the same (i.e. 'gdm'). > 4.2. Interfaces: > > Exported Interfaces Stability Comments > --------------------------------------- ----------- > ------------- > /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? > 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? - J?rg -- Joerg Barfurth Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
