From bc99092@sac.sfbay.sun.com Tue Aug 11 14:21:39 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BLLbR9025368 for ; Tue, 11 Aug 2009 14:21:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7BLLOqY020563; Wed, 12 Aug 2009 05:21:36 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO800D1BDZYCP00@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 15:21:34 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO800CDEDZXUF00@brm-avmta-1.central.sun.com>; Tue, 11 Aug 2009 15:21:33 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7BLLWDI023085; Tue, 11 Aug 2009 14:21:32 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BLLVYx025362; Tue, 11 Aug 2009 14:21:31 -0700 (PDT) Received: (from bc99092@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n7BLLVai025358; Tue, 11 Aug 2009 14:21:31 -0700 (PDT) Date: Tue, 11 Aug 2009 14:21:31 -0700 (PDT) From: Brian Cameron Subject: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] To: LSARC-ext@sun.com Cc: desktop-discuss@opensolaris.org Message-id: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 59047 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: GNOME Display Manager (GDM) Rewrite 1.2. Name of Document Author/Supplier: Author: Brian Cameron 1.3 Date of This Document: 11 August, 2009 4. Technical Description 1. Introduction 1.1. Project/Component Working Name: GNOME Display Manager (GDM) Rewrite 1.2. Name of Document Author/Supplier: Brian Cameron 1.3. Date of This Document: 08/11/2009 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Robert O'Dea 1.4.4. The name of your business unit: Software - OPG 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy@sun.com 1.5.2. Responsible Engineer: brian.cameron@sun.com 1.5.3 Marketing Manager: dan.robert@sun.com 1.5.4. Interest List: desktop-discuss@opensolaris.org 2. Project Summary 2.1. Project Description: Starting with GDM version 2.21, the code has been rewritten to make better use of GObject object-oriented techniques, and D-Bus for IPC (inter-process communication). It also makes use of ConsoleKit to keep track of information about each managed session, and ConsoleKit provides better support of switching between graphical VT sessions. ConsoleKit will be integrated into Solaris with the new GDM rewrite. The Desktop team intends to integrate GDM 2.28 into Solaris. Today, Solaris does not support graphical VT sessions. However, the virtual console team is currently targeting build 124 to add this feature. Refer to PSARC 2006/591 Virtual Console. VT support is not needed to use GDM, but GDM will support it as soon as it is available. 4. Technical Description: 4.1. Details: The GDM rewrite provides a login experience that is similar to the gdmlogin GUI provided by the older GDM. The usability has been much improved with a more usable face browser and a panel which displays a number of new options. GDM uses the GTK+ widget set and supports accessibility. The GDM greeter GUI runs as a special user which can be configured. By default the "gdm" user and "gdm" group are used. This user has no special permissions except the ability to read the Xauth keys associated with displays that GDM sets up. This ensures that if a user somehow were to compromise the GDM GUI programs, they would not get higher privilege such as root permissions. The following text refers to the "gdm" user and "gdm" group, but note that these can be configured to be a different user and/or group if desired. The GDM login program now has a GUI panel. This provides widgets which show the user battery status and provides a new interface for manually starting and stopping accessibility programs on-demand. The panel also can provide an interface for selecting the keyboard layout to use; however, this keyboard layout switching feature is not available on Solaris since it depends on libxklavier which is not available on Solaris. If configured, GDM can will display "Shutdown" and "Restart" buttons for shutting down and restarting the machine. Refer to section 4.1.9 for more information. 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. 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. 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. 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. 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. 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. - 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. - /usr/bin/gdmdynamic [--add=DISPLAY | --delete=DISPLAY | --list ] 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. 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/bin/gdmflexiserver [--version] [--debug] This program is provided for backwards compatibility. It can be used with no arguments to start a flexible display on a new VT. Aside from the --version and --debug arguments, it no longer supports other arguments that were previously supported by GDM, such as the --command argument. D-Bus interfaces replace the functionalities that were previously provided by --command. - /usr/sbin/gdm-stop Script for stopping GDM. - /usr/bin/gdm-screenshot [--debug] A utility for taking a picture of the GDM login GUI screen. - /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 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. - /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 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. This, and other files associated with this applet will only be delivered after VT integrates into Solaris. Such other files include: - /usr/share/gnome-2.0/ui/GNOME_FastUserSwitchApplet.xml - /usr/lib/bonobo/servers/GNOME_FastUserSwitchApplet.server - /usr/lib/gdm-xdmcp-chooser-slave The slave to be used when a user is running the XDMCP chooser. 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: - 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. - 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. - 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. 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. 4.1.3 Detail About GDM Server Configuration The GDM rewrite uses different configuration mechanisms than the old GDM. The GDM daemon stores default values via GConf in the gdm.schemas GConf file. If these values need to be configured for a given machine, the system administrator is expected to modify the /etc/gdm/custom.conf file. This file is in the same format as the old GDM, though it supports fewer configuration options. The following options are supported: chooser/Multicast - Set to "true" or "false". If true, then the chooser will send a multicast query to the local network and collect responses from the hosts who have joined multicast group. The value is "true" by default. chooser/MulticastAddr - The Link-local Multicast address. The value is "ff02::1" by default. daemon/User - The user who runs GDM GUI applications daemon/Group - The group who runs GDM GUI applications daemon/AutomaticLoginEnable - Set to "true" or "false". If true, then Automatic login is enabled. The value is "false" by default. daemon/AutomaticLogin - Set to automatic login user. daemon/TimedLoginEnable - Set to "true" or "false". If true, then Timed login is enabled. The value is "false" by default. daemon/TimedLogin - Set to timed login user. daemon/TimedLoginDelay - Timed login delay in seconds. The value s 30 seconds by default. security/DisallowTCP - Set to "true" or "false". If true, then always append "-nolisten tcp" to the Xserver command line. The value is "true" by default in the upstream community. However, on Solaris, we set the value to "false" so that the Xserver "options/tcp_listen" SMF property controls whether "-nolisten tcp" is added to the command line or not. xdmcp/DisplaysPerHost - Maximum number of remote connections from a single host Default value is 1. xdmcp/Enable - Set to "true" or "false". If true, then XDMCP is enabled. The value is "false" by default. xdmcp/HonorIndirect - Set to "true" or "false". If true, then XDMCP INDIRECT choosing is enabled. The value is "true" by default. xdmcp/MaxPending - This integer value controls how many displays can start at the same time. The value is 4 by default. xdmcp/MaxSessions - The maximum number of remote displays connections which will be managed simultaneously. The value is 16 by default. xdmcp/MaxWait - When GDM is ready to manage a display, an ACCEPT packet is sent to it containing a unique session id. GDM will then place the session id in the pending queue waiting for the display to respond with a MANAGE request. If no response is received within xdmcp/MaxWait seconds, GDM will abort the connection. The value is 30 seconds by default. xdmcp/MaxWaitIndirect - Determines the maximum number of seconds between the time where a user chooses a host and the subsequent indirect query where the user is connected to the host. If exceeded, the connection is aborted. The value is 30 seconds by default. xdmcp/PingIntervalSeconds - Interval in which to ping the Xserver in seconds. If the Xserver does not return before the next ping, the connection is stopped. the value is 15 seconds by default. xdmcp/Port - XDMCP port to use. The value is 177 by default. xdmcp/Willing - When the machine sends a WILLING packet back after a QUERY it sends a string that gives the current status of this server. The default message is the system ID, but it is possible to create a script that displays customized messages. If this script does not exist or if the value is empty, then the default message is sent. If the script succeeds and produces some output, the first line of its output is sent. It runs at most once every 3 seconds to prevent possible denial of service by flooding the machine with QUERY packets. The value is "/etc/gdm/Xwilling" by default. 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. - /apps/gdm/simple-greeter/banner_message_enable Boolean value. Controls whether the banner message text is displayed. Default value is false. - /apps/gdm/simple-greeter/banner_message_text String value. Specifies the text banner message to show on the greeter window. Default value is NULL. - /apps/gdm/simple-greeter/debug Boolean value. If true, then debugging mode is enabled for the greeter. - /apps/gdm/simple-greeter/disable_restart_buttons Boolean value. Controls whether to show the restart and shutdown buttons in the login window. Even if true, GDM checks to see if the "gdm" user (or the user specified in the daemon/User configuration option) has RBAC privileges for solaris.system.shutdown. If not, the buttons are not displayed regardless of this configuration setting. Default value is false. - /apps/gdm/simple-greeter/disable_user_list Boolean value. If true, then the face browser with known users is not shown. In this case, normal PAM prompting is used. - /apps/gdm/simple-greeter/logo_icon_name String value. Specifies the themed icon name to use for the greeter logo. - /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. 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. - /var/run/gdm This directory is used for storing Xauth keys for all active sessions. It has the following permissions: drwxrwxr-t 4 root gdm 273 Jan 30 18:39 gdm This directory contains a subdirectory for each Xauth key. For user "foo", the directory would be auth-for-foo-XXXXX where mkdtemp(3C) is used to build a unique filename, replacing the "XXXXX" string with a unique string. The Xauth key is stored in a file in this directory called "database" which only has read-write permissions for the user. Note that GDM packages do not install any files to /var/run. Files in this directory are created when GDM starts. 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.8 Detail About Xserver interfaces GDM starts the Xserver via the /usr/X11/bin/Xserver script. It then waits until it receives the USR1 signal, which the Xserver will send when the Xserver is initialized and ready to use. On Solaris the private to Solaris SDTLOGIN interface (/var/dt/sdtlogin) is used to drop the Xserver to user permissions after authentication for added security. 4.1.9 ConsoleKit Integration GDM uses ConsoleKit to keep track of information about each running session. This information is also useful to other programs, such as the Fast-User Switch applet, so ConsoleKit provides a standard interface for getting this information via D-Bus. GDM provides Shutdown and Reboot buttons for shutting down and restarting the system. These buttons are only available if enabled in the configuration, and if the "gdm" user has permissions for the solaris.system.shutdown RBAC key. GDM does not do the actual shutdown/restart operation, but sends a message to ConsoleKit which does the work. Note that ConsoleKit also will only allow these operations if the requesting user (the "gdm" user in the situation where the user presses the button on the GDM login GUI) has RBAC permissions for the solaris.system.shutdown RBAC key. GDM calls /usr/lib/ck-get-x11-display-device to find out the associated TTY value of the Xserver on a given display after starting the Xserver. GDM calls /usr/bin/ck-history when using the face browser to show the most frequently logged in users first, making it easier for such users to log in quickly. The gdmdynamic program calls ck-seat-tool to actually start a dynamic display. 4.1.10 logindevperm Integration On Solaris, the logindevperm(4) interfaces are called after the user authenticates to ensure that the user has appropriate permissions after login. This is only done for users who are logging into the console. GDM checks to see if the associated device is "/dev/console" or a VT device (/dev/vt/*) and only calls logindevperm if one of these devices is being used. 4.1.11 SMF Integration GDM includes SMF integration files to start and stop GDM as a service, much like the previous version of GDM. It also makes use of ctrun(1) to ensure that any processes that crash in the user session do not cause the GDM service to restart. 4.1.12 /etc/default/login integration GDM supports the CONSOLE, PASSREQ, PATH, and SUPATH configuration options. When CONSOLE is set to "/dev/console", then root is only allowed to log in via the console, the settings for PATH or SUPATH are used as the default PATH for normal users (PATH) or the root user (SUPATH). When PASSREQ is "YES" then the PAM_DISALLOW_NULL_AUTHTOK flag is used when calling pam_authenticate and pam_acct_mgmt. 4.1.13 GDM Xsession Script The GDM Xsession script sources /etc/profile, /etc/xprofile, and $HOME/.profile before starting the user session. If the file does not exist on the system, it is not sourced. Any scripts in /etc/X11/xinit/xinitrc.d are sourced before starting the user session. This allows for distro specific startup configuration. The GDM Xsession script also calls xrdb to merge resources. On Solaris it will call "xrdb -merge $HOME/.Xresources" if such a file exists on the system. The Xsession script uses /usr/bin/zenity to display any error dialogs to the user. 4.1.14 Handling Of Dueling Login Applications ASARC 1994/437 discussed the issue of multiple login applications competing for the console. Dtlogin currently provides a poor "solution" whereby the user is requested to ignore the text based login prompt that was just displayed and to wait a few seconds for the dtlogin screen to appear. ASARC 1995/390 provided advisory information to the effect that the next version of this project would not be approved if it had not eliminated this problem. GDM plans to resolve this problem by making use of VT when it is available. This will provide users with a reasonable mechanism to "drop to console" on demand. 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. Regressions worthy of note include the following: - GDM configuration interfaces have changed. Therefore users may need to reconfigure GDM if they desire the GUI to behave in a non-default manner. - GDM no longer supports managing Xnest/Xephyr login windows, so this feature and the "Login in a window" menu option is no longer available. - GDM no longer supports gdmgreeter style themes. The new GDM has more limited branding options, like changing the background image that is used. - GDM no longer provides the ability to start the chooser program from the login greeter GUI program. - GDM no longer provides a "Failsafe Session". Since the new GDM assumes that console users have access to VT, the VT mechanism should be used for failsafe purposes. - GDM no longer provides the "gdmsetup" program, so there is no longer a GUI interface for configuring GDM. In some ways this is a good thing since the old gdmsetup could only be run with root privileges. The gdmsetup program has long needed to be rewritten to be more sensible about requiring privilege to run, such as using RBAC on Solaris or PolicyKit on Linux to allow any authorized user to configure the login screen. Note that Canonical is currently in the process of writing a new "gdmsetup" program and it should be available in the near future. It currently uses PolicyKit, so some work will be needed to make it work with RBAC on Solaris instead. However, it is expected that this feature will be reintroduced in the following GNOME release cycle. - GDM no longer provides gesture listeners, so that accessibility programs can not be launched on-demand. Instead such programs can be configured to be always on or always off. GDM does also provide a dialog where users can turn on/off accessibility programs. However, this is obviously only useful to users who can navigate the GUI. 4.2. Interfaces: Exported Interfaces Stability Comments --------------------------------------- ----------- ------------- SUNWgnome-display-mgr Uncommitted Package name. SUNWgnome-display-mgr-root Uncommitted Package name. /var/svc/manifest/application/graphical-login/gdm.xml Uncommitted SMF integration file. /lib/svc/method/svc-gdm Volatile SMF integration startup, stop, and restart, script. /usr/bin/gdm-screenshot Volatile See 4.1.1. /usr/bin/gdmdynamic Volatile See 4.1.1. /usr/bin/gdmflexiserver Volatile See 4.1.1. /usr/sbin/gdm-binary Volatile See 4.1.1. /usr/sbin/gdm-stop Volatile See 4.1.1. /usr/lib/gdm-crash-logger Volatile See 4.1.1. /usr/lib/gdm-host-chooser Volatile See 4.1.1. /usr/lib/gdm-session-worker Volatile See 4.1.1. /usr/lib/gdm-simple-chooser Volatile See 4.1.1. /usr/lib/gdm-simple-greeter Volatile See 4.1.1. /usr/lib/gdm-simple-slave Volatile See 4.1.1. /usr/lib/gdm-user-switch-applet Volatile See 4.1.1. Only delivered after VT integrates. /usr/lib/gdm-xdmcp-chooser-slave Volatile See 4.1.1. /usr/share/gdm/gdb-cmd See 4.1.1. /usr/share/gdm/autostart/LoginWindow Uncommitted See 4.1.2. /etc/gdm/custom.conf Uncommitted See 4.1.3. /etc/gdm/gdm.schemas Uncommitted GConf configuration for server. See 4.1.3. /etc/gconf/schemas/gdm-simple-greeter.schemas Uncommitted GConf configuration for greeter. See 4.1.4. /etc/gdm/Init/Default Uncommitted See 4.1.5. /etc/gdm/PostLogin/Default Uncommitted See 4.1.5. /etc/gdm/PreSession/Default Uncommitted See 4.1.5. /etc/gdm/PostSession/Default Uncommitted See 4.1.5. /etc/gdm/Xwilling Uncommitted See 4.1.5. No file is shipped by default. /etc/gdm/Xsession Uncommitted See 4.1.13. /etc/X11/xinit/xinitrc.d Uncommitted See 4.1.13. /usr/share/xsessions Uncommitted See 4.1.6 /var/lib/gdm Uncommitted $HOME directory for "gdm" user. See 4.1.6. /var/lib/gdm/.gconf.mandatory/%gconf-tree.xml Uncommitted See 4.1.6 /var/lib/gdm/.gconf.path Uncommitted See 4.1.6 $HOME/.dmrc Uncommitted See 4.1.6. /usr/share/gdm/gdm-greeter-login-window.glade Volatile Glade file /usr/share/gnome-2.0/ui/GNOME_FastUserSwitchApplet.xml Volatile UI XML file. Only delivered after VT integrates. /usr/share/gnome/help/gdm Volatile Help files /usr/share/icons/hicolor/ Volatile Icons for GDM /usr/share/pixmaps/faces/ Volatile Face images for face browser /usr/lib/bonobo/servers/GNOME_FastUserSwitchApplet.server Volatile Bonobo applet integration. Only delivered after VT integrates. /etc/dbus-1/system.d/gdm.conf Volatile D-Bus integration. /var/log/gdm Volatile Contains log files for all running Xservers. /var/run/gdm Volatile Contains Xauth cookies for all running sessions. See 4.1.6. DESKTOP_SESSION Uncommitted See 4.1.7. GDMSESSION Uncommitted See 4.1.7. GDM_LANG Uncommitted See 4.1.7. GDM_KEYBOARD_LAYOUT Uncommitted See 4.1.7. 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". /usr/bin/gdmXnest Obsolete Volatile GDM no longer supports managing Xnest style logins. /usr/bin/gdmXnestchooser Obsolate Volatile "" /usr/bin/gdmphotosetup Obsolate Volatile User photos are now selected via the "About Me" capplet /usr/bin/gdmthemetester Obsolate Volatile gdmgreeter style themes no longer supported. /usr/sbin/gdmsetup Obsolate Volatile GDM no longer supports configuration GUI. /usr/lib/gdmchooser Obsolate Volatile Replaced with new chooser. /usr/lib/gdmgreeter Obsolete Volatile Replaced with new greeter. /usr/lib/gdmlogin Obsolete Volatile Replaced with new greeter. /usr/lib/gtk-2.0/modules/libdwellmouselistener.so Obsolete Volatile No longer supports a11y gestures. /usr/lib/gtk-2.0/modules/libkeymouselistener.so Obsolete Volatile No longer supports a11y gestures. /usr/share/gdm/BuiltInSessions/default.desktop Obsolete Volatile This provided a session option for users to login via an .Xinitrc script. A user who wanted this could easily define their own to do the same thing. Removed from upstream because few people use it. /usr/share/gdm/applications/gdmflexiserver-xnest.desktop Obsolete Volatile See gdmXnest above. /usr/share/gdm/applications/gdmphotosetup.desktop Obsolete Volatile See gdmphotsetup above. /usr/share/gdm/applications/gdmsetup.desktop Obsolete Volatile See gdmsetup above. /usr/share/gdm/defaults.conf Obsolete Volatile Defaults now stored in GConf. /usr/share/gdm/factory-defaults.conf Obsolete Volatile Ditto /usr/share/gdm/gdmchooser.glade Obsolete Volatile No longer needed. /usr/share/gdm/gdmphotosetup.glade Obsolete Volatile No longer needed. /usr/share/gdm/gdmsetup.glade Obsolete Volatile No longer needed. /usr/share/gdm/themes Obsolete Volatile No longer support gdmgreeter style themes. /usr/share/gdm/gdmprefetchlist Obsolete Volatile No longer supported. /usr/share/gdm/locale.alias Obsolete Volatile No longer needed. /etc/X11/gdm/modules/AccessDwellMouseEvents Obsolete Volatile No longer supports a11y gestures. /etc/X11/gdm/modules/AccessKeyMouseEvents Obsolete Volatile Ditto. /etc/X11/gdm/modules/factory-AccessDwellMouseEvents Obsolete Volatile Ditto. /etc/X11/gdm/modules/factory-AccessKeyMouseEvents Obsolete Volatile Ditto. GDM Configuration options Obsolete Volatile Refer [1]. Imported Interfaces Stability Comments ---------------------------- --------------- ----------------------- /var/dt/sdtlogin/$DISPLAY Contracted ASARC 1995/390 chkauthattr Stable PSARC 1997/332 X11 Standard PSARC 1998/299 XDMCP Standard X.org X Display Manager Control Protocol /usr/X11/bin/Xserver Standard PSARC 1998/299 /usr/lib/gnome-settings-daemon External LSARC 2001/352 /usr/bin/metacity External LSARC 2001/420 /usr/lib/at-spi-registryd Evolving LSARC 2001/650 /usr/bin/gok External LSARC 2002/292 /usr/bin/magnifier (GNOME-mag) External PSARC 2002/525 /usr/bin/zenity Volatile LSARC 2004/456 /var/svc/profile/upgrade Contracted PSARC 2002/547 Solaris Auditing Contracted PSARC 2003/397 /etc/logindevperm Contracted PSARC 2003/612 Tamarack (HAL) Volatile PSARC 2005/399 /usr/bin/orca Committed LSARC 2005/504 GNOME Base Libraries Committed LSARC 2006/202 D-Bus & dbus-glib Volatile LSARC 2006/368 Virtual Console Committed PSARC 2006/591 GNOME Power Manager Volatile LSARC 2007/702 libwrap Committed PSARC 2000/488, PSARC 2008/164 GDM System user homedir Uncommitted PSARC 2008/662 ConsoleKit Volatile ????? ????/??? /usr/lib/ck-get-x11-display-device Volatile ????? ????/??? See 4.1.13. XDG_SESSION_COOKIE Volatile ????? ????/??? solaris.system.shutdown key ? ????? ????/??? User environment variables Standard e.g. HOME, SHELL, etc. See 4.1.7. /etc/default/login ? See 4.1.12 /etc/profile ? See 4.1.13. /etc/xprofile ? See 4.1.13. $HOME/.profile ? See 4.1.13. 4.3. Doc Impact: Man pages are needed. 4.4. Packaging & Delivery: SUNWgnome-display-mgr, SUNWgnome-display-mgr-root - packages for GDM 4.5. Dependencies: PSARC 2006/591 Virtual Console PSARC 2008/033 Removal of Xsun PSARC 2008/662 GDM System user homedir LSARC ????/??? ConsoleKit Since VT support requires driver support, user switching features will not work on systems where the graphics driver does not support VT. 4.6. L10N Impact: The Desktop team and the G11N team are working together to evaluate and provide I18N/L10N support. 4.7. Security Impact: GDM makes use of PAM to ensure that username and password information is handled in a secure manner. GDM GUI programs are run as the "gdm" user to ensure that if they are exploited in any way, the user does not gain privilege. The "gdm" user is configured to have minimal privileges necessary for the login GUI programs to run. The "gdm" user does have the authority to read Xauth keys for all running Xservers, so if this user were exploited there would be some risk since it would be possible to snoop or affect programs running on any Xserver on the system. Xserver Xauth keys are only accessible by the user who owns them, the root user and the gdm user to ensure that they are kept as secure as possible. The /var/lib/gdm and /var/log/gdm directories are owned by root:gdm and do not have world read/execute/write permissions so that normal users cannot access or tamper with files in these directories. GDM scripts and configuration files in the /etc and /usr/share directories can only be modified by a user with root privilege. GDM D-Bus IPC communication is only allowed by processes started by the GDM daemon, so normal users can not interact with GDM via D-Bus. GDM makes use of logindevperm to manage device permissions for users logging into the console or via Virtual Terminals. GDM sets default XDMCP configuration in a manner that helps to avoid denial-of-service type attacks. The security/DisallowTCP configuration is set to "false" by default in the GDM configuration. The Xserver "options/tcp_listen" SMF property controls whether "-nolisten tcp" is added to the command line or not. When starting the Xserver, it uses the /var/dt/sdtlogin/$DISPLAY interface to drop the Xserver to user permissions, so it is more secure. Refer to the following cases which relate to how Shutdown and Reboot are managed in the desktop. GDM makes use of RBAC so that the Shut Down and Reboot options are only available if the "gdm" user has solaris.system.shutdown authority. The following cases relate to how Shut Down and Reboot functions work with the Desktop stack. PSARC 2008/034 Defining Workstation Owner Infrastructure LSARC 2007/702 GNOME Power Manager PSARC 2008/021 HAL Power Management Support LSARC 2008/262 GNOME shutdown dialog 5. Reference Documents: [1] ./unsupported-defaults.conf File showing configuration options no longer supported. GDM Website: http://projects.gnome.org/gdm/ Current GDM 2.27.4 Documentation: http://library.gnome.org/admin/gdm/2.27/gdm.html GDM Wiki: http://live.gnome.org/GDM GDM Redesign Information: http://live.gnome.org/GDM/NewDesign FreeDesktop Desktop Base Directory Specification: http://www.freedesktop.org/wiki/Specifications/basedir-spec FreeDesktop Desktop Entry Specification: http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec FreeDesktop Startup Notification Specification: http://www.freedesktop.org/wiki/Specifications/startup-notification-spec FreeDesktop Autostart Specification: http://www.freedesktop.org/wiki/Specifications/autostart-spec 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: Desktop 6.5. ARC review type: OnePager 6.6. ARC Exposure: open From Alan.Coopersmith@sun.com Tue Aug 11 14:28:18 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BLSH3N025586 for ; Tue, 11 Aug 2009 14:28:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7BLSBxL023882 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 12 Aug 2009 05:28:16 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO800E01EB32R00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 15:28:15 -0600 (MDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO800CR9EB2UL00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 15:28:14 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BLSE8Q027435 for ; Tue, 11 Aug 2009 14:28:14 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO800900E5B8V00@fe-sfbay-09.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 14:28:14 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO800LL3EB1YOB0@fe-sfbay-09.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 14:28:14 -0700 (PDT) Date: Tue, 11 Aug 2009 14:28:13 -0700 From: Alan Coopersmith Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> Sender: Alan.Coopersmith@sun.com To: Brian Cameron Cc: LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A81E26D.8020303@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 373 I don't see a mention in this case of GDM replacing dtlogin as the default login screen, and EOL'ing dtlogin - is that going to be handled by this case or are you going to bring LSARC 2005/417 back again to do that at the same time as this case integrates? -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Brian.Cameron@sun.com Tue Aug 11 14:41:33 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BLfXAm026011 for ; Tue, 11 Aug 2009 14:41:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BLfWFX020434 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 11 Aug 2009 14:41:32 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO800F0DEX5JD00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 15:41:29 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO800CMHEX4UL10@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 15:41:28 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7BLfSCh027539 for ; Tue, 11 Aug 2009 21:41:28 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO800000EHSRD00@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 15:41:28 -0600 (MDT) Received: from [129.153.250.100] ([unknown] [129.153.250.100]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO800G0TEWZXEC0@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 15:41:26 -0600 (MDT) Date: Tue, 11 Aug 2009 16:41:41 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A81E26D.8020303@sun.com> Sender: Brian.Cameron@sun.com To: Alan Coopersmith Cc: LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A81E595.7060602@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A81E26D.8020303@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 477 Alan: > I don't see a mention in this case of GDM replacing dtlogin as the > default login screen, and EOL'ing dtlogin - is that going to be > handled by this case or are you going to bring LSARC 2005/417 back > again to do that at the same time as this case integrates? I would prefer to handle the EOL'ing of dtlogin as a separate case. The added complexities of EOL'ing dtlogin caused the LSARC 2005/417 to derail, and I would prefer for that to not happen again. Brian From Glenn.Faden@sun.com Tue Aug 11 14:54:43 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BLsgO1026837 for ; Tue, 11 Aug 2009 14:54:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7BLseAv000378 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 11 Aug 2009 22:54:42 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO800G09FJ4SZ00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 15:54:40 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO800C6DFJ3UK20@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 15:54:39 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BLsdZe021047 for ; Tue, 11 Aug 2009 14:54:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO800100FHU3N00@fe-sfbay-10.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 14:54:39 -0700 (PDT) Received: from rampartgf.local ([unknown] [129.150.241.213]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO800DOZFJ23VA0@fe-sfbay-10.sun.com>; Tue, 11 Aug 2009 14:54:38 -0700 (PDT) Date: Tue, 11 Aug 2009 14:54:35 -0700 From: Glenn Faden Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> Sender: Glenn.Faden@sun.com To: Brian Cameron Cc: LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A81E89B.1060707@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) Status: RO Content-Length: 2251 Brian Cameron wrote: > > If configured, GDM can will display "Shutdown" and "Restart" buttons > for shutting down and restarting the machine. Refer to section 4.1.9 > for more information. > This should not be configured by default if the user is not authenticated. > 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. 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. > It is a security vulnerability to display the list of valid usernames to unauthenticated individuals, so we shouldn't deliver the system with this configured by default. > 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. 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. > Hopefully we can use this feature when TX is enabled to specify single or multilevel sessions. --Glenn From Alan.Coopersmith@sun.com Tue Aug 11 15:01:34 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BM1YH2027144 for ; Tue, 11 Aug 2009 15:01:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BM1TBq012995 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 11 Aug 2009 16:01:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO800J0JFULP400@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 11 Aug 2009 15:01:33 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO8009OVFUKYM90@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 11 Aug 2009 15:01:33 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7BM1WG2001367 for ; Tue, 11 Aug 2009 15:01:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO800000FT3PF00@fe-sfbay-09.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 11 Aug 2009 15:01:32 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO80061JFUK4S60@fe-sfbay-09.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 11 Aug 2009 15:01:32 -0700 (PDT) Date: Tue, 11 Aug 2009 15:01:32 -0700 From: Alan Coopersmith Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A81E595.7060602@sun.com> Sender: Alan.Coopersmith@sun.com To: Brian Cameron Cc: LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A81EA3C.9020100@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A81E26D.8020303@sun.com> <4A81E595.7060602@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1020 Brian Cameron wrote: > > Alan: > >> I don't see a mention in this case of GDM replacing dtlogin as the >> default login screen, and EOL'ing dtlogin - is that going to be >> handled by this case or are you going to bring LSARC 2005/417 back >> again to do that at the same time as this case integrates? > > I would prefer to handle the EOL'ing of dtlogin as a separate case. > The added complexities of EOL'ing dtlogin caused the LSARC 2005/417 > to derail, and I would prefer for that to not happen again. Given that it's already defacto happened in OpenSolaris, and will be the case in all available Nevada builds shortly, I'd expect to see that case soon - even if it's derailed, at this point the only options are approve (possibly with TCR's) or deny so that it can be appealed and overruled. Delaying it or pretending it's not happening is simply ignoring reality and serves no one's interest. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Brian.Cameron@sun.com Tue Aug 11 15:07:02 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7BM72Wh027317 for ; Tue, 11 Aug 2009 15:07:02 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7BM703q016105 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 11 Aug 2009 16:07:02 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO800K0ZG3P2S00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 15:07:01 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO8009SHG3OZ0A0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 15:07:00 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7BM70WD006975 for ; Tue, 11 Aug 2009 22:07:00 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KO800L00FYKWH00@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 11 Aug 2009 16:07:00 -0600 (MDT) Received: from [129.153.250.100] ([unknown] [129.153.250.100]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KO800C0WG3F6B40@mail-amer.sun.com>; Tue, 11 Aug 2009 16:06:52 -0600 (MDT) Date: Tue, 11 Aug 2009 17:07:13 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A81E89B.1060707@sun.com> Sender: Brian.Cameron@sun.com To: Glenn Faden Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A81EB91.7060209@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A81E89B.1060707@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 3424 Glenn: >> If configured, GDM can will display "Shutdown" and "Restart" buttons >> for shutting down and restarting the machine. Refer to section 4.1.9 >> for more information. > This should not be configured by default if the user is not authenticated. The "gdm" is not configured to have the solaris.system.shutdown authorization by default, so these buttons do not show up by default. >> 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. 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. > It is a security vulnerability to display the list of valid usernames to > unauthenticated individuals, so we shouldn't deliver the system with > this configured by default. We can easily configure GDM to work either way. If it is a requirement to turn this off, then this is no problem. However, all other GNOME distributions turn it on by default, so I wonder if we really want to be different in this area. With the face browser turned on, GDM behaves more like the Windows login program where the user just clicks on the user they wish to login. So, from a desktop usability perspective, the face browser is a good feature to have on. If we choose to leave the face browser enabled by default, there is no reason that users who wish to turn off the feature for security reasons can't do so. I'll leave this up to ARC to decide, I just wanted to share some of the thoughts behind the decision by the upstream GDM community to turn it on by default. >> 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. 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. > Hopefully we can use this feature when TX is enabled to specify single > or multilevel sessions. The way that the .desktop files in /usr/share/xsessions work has not changed from the old GDM to the new GDM. The behavior of how /usr/share/xsessions works is a cross-desktop standard that also works with KDE, for example. So, if TX provides multiple .desktop files, they should work the same as with the old GDM. As an aside, I corrected the spelling of "usre" to "user" in the onepager in the case materials, now that I noticed that error in your quote. Brian From Darren.Moffat@sun.com Wed Aug 12 01:46:37 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7C8kb7U021581 for ; Wed, 12 Aug 2009 01:46:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7C8kZ61024770 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 12 Aug 2009 02:46:36 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO900M099PNR300@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 12 Aug 2009 02:46:35 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO900MEN9PLGF00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Wed, 12 Aug 2009 02:46:33 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7C8kWYT007001 for ; Wed, 12 Aug 2009 08:46:32 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KO9002008X5YL00@fe-emea-09.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 12 Aug 2009 09:46:20 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KO900ADM9OYFJ80@fe-emea-09.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Wed, 12 Aug 2009 09:46:10 +0100 (BST) Date: Wed, 12 Aug 2009 09:46:01 +0100 From: Darren J Moffat Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A81E595.7060602@sun.com> Sender: Darren.Moffat@sun.com To: Brian Cameron Cc: Alan Coopersmith , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A828149.80408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A81E26D.8020303@sun.com> <4A81E595.7060602@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 670 Brian Cameron wrote: > > Alan: > >> I don't see a mention in this case of GDM replacing dtlogin as the >> default login screen, and EOL'ing dtlogin - is that going to be >> handled by this case or are you going to bring LSARC 2005/417 back >> again to do that at the same time as this case integrates? > > I would prefer to handle the EOL'ing of dtlogin as a separate case. > The added complexities of EOL'ing dtlogin caused the LSARC 2005/417 > to derail, and I would prefer for that to not happen again. Isn't dtlogin effectively EOL due to the imminent demise of SXCE anyway ? dtlogin has never been shipped on OpenSolaris binary releases. -- Darren J Moffat From Darren.Moffat@Sun.COM Wed Aug 12 01:49:58 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7C8nvxe021597 for ; Wed, 12 Aug 2009 01:49:57 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7C8nsuq005459 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 12 Aug 2009 16:49:56 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KO900A0H9V6KW00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 12 Aug 2009 01:49:54 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KO9006FL9V5EO10@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 12 Aug 2009 01:49:53 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7C8nqAg007488 for ; Wed, 12 Aug 2009 08:49:52 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KO900B009R7FT00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 12 Aug 2009 09:49:36 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KO900AJP9UFFJ80@fe-emea-09.sun.com>; Wed, 12 Aug 2009 09:49:27 +0100 (BST) Date: Wed, 12 Aug 2009 09:49:18 +0100 From: Darren J Moffat Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> Sender: Darren.Moffat@Sun.COM To: Brian Cameron Cc: LSARC-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A82820E.3020700@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 1596 1. Lack of Failsafe session. I see this as a major issue. I use the failsafe session more when I'm not on the console than when I am. In particular I often use failsafe when connecting using VNC or a lot when using Sun Ray. A common use case for me is when connecting to the same server that already has another Sun Ray, VNC or console session - because I still don't trust GNOME not to screwup my config with multiple active session against he same home dir. 2. Default using face browser What is the definition of a system account ? The reason I ask is because the GNOME users and groups tool gets this wrong on Solaris. It correctly hides by default all those accounts with a uid < 100 but it doesn't hide the other reserved system accounts: nobody:x:60001:60001:NFS Anonymous Access User:/: noaccess:x:60002:60002:No Access User:/: nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: What about when NIS or LDAP is in use ? Do we really want GDM attempting to display 38,000+ accounts ? Does the face browser need to read anything in the users home dir ? If so it must be disabled by default since it can cause a downgrade attack if the users home directory is supposed to be mounted with Kerberos by default (but can fall back to sys). We have gone to great lengths over the years to ensure that no login program ever touches the users home directory until after pam_authenticate() and pam_setcred() have returned PAM_SUCCESS. 3. Greeter themes What is the impact to the OpenSolaris branding given the new theme restrictions ? -- Darren J Moffat From Nicolas.Williams@sun.com Wed Aug 12 16:19:28 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7CNJSuQ028190 for ; Wed, 12 Aug 2009 16:19:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7CNJLaX020796 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 12 Aug 2009 16:19:28 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOA00L0FE4F6000@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 12 Aug 2009 17:19:27 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOA00K3UE3X3GB0@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 12 Aug 2009 17:19:09 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7CN8We9013272; Wed, 12 Aug 2009 18:08:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7CN8W9U013271; Wed, 12 Aug 2009 18:08:32 -0500 (CDT) Date: Wed, 12 Aug 2009 18:08:32 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> To: Brian Cameron Cc: LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090812230831.GR10982@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 668 On Tue, Aug 11, 2009 at 02:21:31PM -0700, Brian Cameron wrote: > - /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. I figure this is obvious, but the materials don't say so... On successful login the session should be started by the process that did the PAM and audit work, or by its progeny, after pam_open_session(3PAM) is called, and before pam_close_session(3PAM) is called. From Nicolas.Williams@sun.com Wed Aug 12 16:22:26 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7CNMQXu028298 for ; Wed, 12 Aug 2009 16:22:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7CNMOEw007621 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 12 Aug 2009 17:22:26 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOA00907E9CLO00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 12 Aug 2009 16:22:24 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOA00GO6E9BACC0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 12 Aug 2009 16:22:24 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7CNBisI013280; Wed, 12 Aug 2009 18:11:44 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7CNBihs013279; Wed, 12 Aug 2009 18:11:44 -0500 (CDT) Date: Wed, 12 Aug 2009 18:11:44 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> To: Brian Cameron Cc: LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090812231144.GS10982@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 153 Any way to make sure that A11Y is enabled by default, with toggle keys also enabled by default (but actual A11Y features disabled by default)? Nico -- From Darren.Moffat@sun.com Thu Aug 13 00:55:33 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7D7tX0p016664 for ; Thu, 13 Aug 2009 00:55:33 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7D7tX4c027808 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 13 Aug 2009 00:55:33 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB0020720LDR00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 13 Aug 2009 00:55:33 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00DP620J9LE0@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 13 Aug 2009 00:55:32 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7D7tVHw005614 for ; Thu, 13 Aug 2009 07:55:31 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00E001WIBT00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 13 Aug 2009 08:55:13 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB00001201A840@fe-emea-09.sun.com>; Thu, 13 Aug 2009 08:55:13 +0100 (BST) Date: Thu, 13 Aug 2009 08:55:04 +0100 From: Darren J Moffat Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090812230831.GR10982@Sun.COM> Sender: Darren.Moffat@sun.com To: Nicolas Williams Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A83C6D8.1070200@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <20090812230831.GR10982@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 843 Nicolas Williams wrote: > On Tue, Aug 11, 2009 at 02:21:31PM -0700, Brian Cameron wrote: >> - /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. > > I figure this is obvious, but the materials don't say so... > > On successful login the session should be started by the process that > did the PAM and audit work, or by its progeny, after > pam_open_session(3PAM) is called, and before pam_close_session(3PAM) is > called. /should/MUST/. If that doesn't happen then the user environment and credentials won't be properly setup. -- Darren J Moffat From Joerg.Barfurth@sun.com Thu Aug 13 02:40:56 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7D9ethp018627 for ; Thu, 13 Aug 2009 02:40:56 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7D9eeFI005105 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 13 Aug 2009 10:40:54 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB0010B6W4XP00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 13 Aug 2009 02:40:52 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00HQ86W3BYD0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 13 Aug 2009 02:40:51 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7D9eoOY023183 for ; Thu, 13 Aug 2009 09:40:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB006005Q0DX00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 13 Aug 2009 10:40:46 +0100 (BST) Received: from [10.16.66.63] ([unknown] [10.16.66.63]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB00JAE6VHOWE0@fe-emea-09.sun.com>; Thu, 13 Aug 2009 10:40:29 +0100 (BST) Date: Thu, 13 Aug 2009 11:40:29 +0200 From: Joerg Barfurth Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A82820E.3020700@Sun.COM> Sender: Joerg.Barfurth@sun.com To: Darren J Moffat Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A83DF8D.2050805@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 1446 Darren J Moffat schrieb: > 1. Lack of Failsafe session. > > I see this as a major issue. I use the failsafe session more when I'm > not on the console than when I am. In particular I often use failsafe > when connecting using VNC or a lot when using Sun Ray. A common use > case for me is when connecting to the same server that already has > another Sun Ray, VNC or console session - because I still don't trust > GNOME not to screwup my config with multiple active session against he > same home dir. > This really has two separate parts: - Ability to select a terminal-only session: This ought be possible by putting a suitable 'xterm.desktop' file into the /usr/share/xsessions directory. Maybe we should ship such a file, but it should be possible to disable it. Which leads to the question why this xsessions directory is in /usr rather than in /etc ... - Fallback in case of misconfiguration: iirc in case of certain misconfigurations (e.g. if the selected xsession .desktop file points to something non-existing), the session fell back to a failsafe session. Is that (still) the case? - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From Joerg.Barfurth@Sun.COM Thu Aug 13 03:46:09 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DAk9ua019569 for ; Thu, 13 Aug 2009 03:46:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DAk8oY008864 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 13 Aug 2009 03:46:08 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB004019WW1A00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 13 Aug 2009 04:46:08 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00B5H9WUT090@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 13 Aug 2009 04:46:07 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DAk5Ia003552 for ; Thu, 13 Aug 2009 10:46:05 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB000009F2TQ00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 13 Aug 2009 11:45:40 +0100 (BST) Received: from [10.16.66.63] ([unknown] [10.16.66.63]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB00HHV9VT6P70@fe-emea-09.sun.com>; Thu, 13 Aug 2009 11:45:30 +0100 (BST) Date: Thu, 13 Aug 2009 12:45:29 +0200 From: Joerg Barfurth Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> Sender: Joerg.Barfurth@Sun.COM To: Brian Cameron Cc: LSARC-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A83EEC9.5080800@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 27295 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@sun.com Desktop Technology Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From Brian.Cameron@sun.com Thu Aug 13 08:55:37 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DFtaDX002163 for ; Thu, 13 Aug 2009 08:55:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DFtYPR015954 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 13 Aug 2009 23:55:35 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00405O8K2Y00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 08:55:32 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00AAGO8K5UC0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 08:55:32 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DFtWuh007768 for ; Thu, 13 Aug 2009 15:55:32 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOB00100NLDLR00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 09:55:32 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOB009F6O8AKX40@mail-amer.sun.com>; Thu, 13 Aug 2009 09:55:25 -0600 (MDT) Date: Thu, 13 Aug 2009 10:55:44 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A82820E.3020700@Sun.COM> Sender: Brian.Cameron@sun.com To: Darren J Moffat Cc: Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A843780.809@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 5104 Darren: Thanks for your questions. > 1. Lack of Failsafe session. > > I see this as a major issue. I use the failsafe session more when I'm > not on the console than when I am. In particular I often use failsafe > when connecting using VNC or a lot when using Sun Ray. A common use case > for me is when connecting to the same server that already has another > Sun Ray, VNC or console session - because I still don't trust GNOME not > to screwup my config with multiple active session against he same home dir. After reviewing how the new GDM is installed on other distros, we noticed that they are shipping a /usr/share/xsessions/xterm.desktop which allows users to log into an xterm, rather than the full GNOME desktop. So, we have also added this to our GDM builds and I have updated the Exported Interface table to include this xterm.desktop file. I think this will meet your needs. > 2. Default using face browser > > What is the definition of a system account ? I appreciate your concern about how the Face Browser works, since it never worked very well with the old GDM, especially in environments where NIS/LDAP is used. However, the new face browser is much more intelligent. It uses the following logic to filter out system users: - Filters out all accounts under 100. - Filters out all accounts that do not have a valid shell - It only adds users that are in /etc/passwd and users that have logged in previously. So, no users will be shown who are NIS/LDAP users unless they have logged in previously. Note when the Face Browser is shown, you can click on the "Other" (meaning "Other User") button and enter the username and password. If you enter a username that is not a system user (UID<100), then that user will show-up in the face browser in subsequent logins. The list of recent users is managed by ConsoleKit and stored in the file /var/log/ConsoleKit/history, so there is a unique history per-machine. > The reason I ask is because the GNOME users and groups tool gets this > wrong on Solaris. It correctly hides by default all those accounts with > a uid < 100 but it doesn't hide the other reserved system accounts: > > nobody:x:60001:60001:NFS Anonymous Access User:/: > noaccess:x:60002:60002:No Access User:/: > nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: Since these users do not have valid shells specified, these would not be shown. > What about when NIS or LDAP is in use ? Do we really want GDM attempting > to display 38,000+ accounts ? As I explain above, this should not be an issue. > Does the face browser need to read anything in the users home dir ? If > so it must be disabled by default since it can cause a downgrade attack > if the users home directory is supposed to be mounted with Kerberos by > default (but can fall back to sys). We have gone to great lengths over > the years to ensure that no login program ever touches the users home > directory until after pam_authenticate() and pam_setcred() have returned > PAM_SUCCESS. Yes, the user's image file is loaded from the user's $HOME directory before authentication. As I explained before, we can disable the Face Browser if we want by default. All other distros turn on the Face Browser by default, and users disable it when needed. Note that if we choose to turn on the Face Browser by default, that the Sun Ray install process would turn it off. I think many of the cases where the Face Browser would not be desired would be in Sun Ray environments (e.g. Trusted Solaris). So, if we choose to turn on the Face Browser by default, many users who do not want it (e.g. Sun Ray users) would have it turned off by default. But, if it is a requirement that Solaris by default does not touch the user's $HOME directory before authentication, then the Face Browser would need to be turned off by default. Do we want to be different than other distros in this regard because of this kerberos requirement? > 3. Greeter themes > > What is the impact to the OpenSolaris branding given the new theme > restrictions ? The new GDM greeter only allows the specification of the background image to be used with the new GDM. Unless the "gdm" user is configured to use a different background image, it will use the same background that is shown by default for a user session. So, without any extra work, it will already use the same branded background we use for the user sessions. We can change that if we think a different branded background for the GDM screen improves the branding. It is also possible to brand the new GDM by using any of the configuration options specified in the ARC case, such as turning off the Face Browser if desired. Another impact is that we no longer need to deliver the old GDM branding files in the SUNWgnome-themes package (e.g. files installed to /usr/share/gdm/themes), since they won't be used any longer. The ARC case already highlights that /usr/share/gdm/themes is an Obsolete interface, but I could add a mention in the onepager that this has an impact on the SUNWgnome-themes package if you think that is interesting. Brian From Brian.Cameron@sun.com Thu Aug 13 08:59:44 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DFxhon002304 for ; Thu, 13 Aug 2009 08:59:43 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DFxY90017577 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 13 Aug 2009 23:59:42 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB0040LOFGKV00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 08:59:40 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00ABFOFF5RC0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 08:59:40 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DFxdqm009504 for ; Thu, 13 Aug 2009 15:59:39 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOB00I00O2WWE00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 09:59:39 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOB009LHOEVKX60@mail-amer.sun.com>; Thu, 13 Aug 2009 09:59:20 -0600 (MDT) Date: Thu, 13 Aug 2009 10:59:41 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A83C6D8.1070200@Sun.COM> Sender: Brian.Cameron@sun.com To: Darren J Moffat Cc: Nicolas Williams , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A84386D.6030109@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <20090812230831.GR10982@Sun.COM> <4A83C6D8.1070200@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1429 Darren/Nicolas: On 08/13/09 02:55, Darren J Moffat wrote: > Nicolas Williams wrote: >> On Tue, Aug 11, 2009 at 02:21:31PM -0700, Brian Cameron wrote: >>> - /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. >> >> I figure this is obvious, but the materials don't say so... >> >> On successful login the session should be started by the process that >> did the PAM and audit work, or by its progeny, after >> pam_open_session(3PAM) is called, and before pam_close_session(3PAM) is >> called. > > /should/MUST/. If that doesn't happen then the user environment and > credentials won't be properly setup. Yes, the gdm-session-worker process does start the user session by running the /etc/gdm/Xsession script after successful authentication. Note the /etc/gdm/Xsession script is what launches the user session (e.g. gnome-session for a GNOME user session). I updated the description of gdm-session-worker in section 4.1.1 of the onepager to make this more clear by adding this text: The gdm-session-worker process also launches the /etc/gdm/Xsession script after successful login, which starts the user session (e.g. gnome-session for a GNOME user session). Brian From casper@holland.sun.com Thu Aug 13 09:05:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DG5eGE002588 for ; Thu, 13 Aug 2009 09:05:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DG5b1x027519 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Thu, 13 Aug 2009 17:05:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00B4VOPFY400@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Thu, 13 Aug 2009 09:05:39 -0700 (PDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00524OPD3V80@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Thu, 13 Aug 2009 09:05:38 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DG5Y2r036417; Thu, 13 Aug 2009 17:05:34 +0100 (BST) Date: Thu, 13 Aug 2009 18:05:34 +0200 From: Casper.Dik@sun.com Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843780.809@sun.com> Sender: casper@holland.sun.com To: Brian Cameron Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <200908131605.n7DG5Y2r036417@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> Status: RO Content-Length: 825 >> nobody:x:60001:60001:NFS Anonymous Access User:/: >> noaccess:x:60002:60002:No Access User:/: >> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: > >Since these users do not have valid shells specified, these would not >be shown. These actually have a valid shell (the default shell, /bin/sh, is used when the password shell lists the empty string for the shell). Can gdm determine which users are locked? Does gdm read /etc/passwd directly (to find out the "local" accounts?) Or does gdm use getent()? (This lists all users in files, nis, nis+ and possibly LDAP) >> What about when NIS or LDAP is in use ? Do we really want GDM attempting >> to display 38,000+ accounts ? > >As I explain above, this should not be an issue. So no getent? How does gdm detect which users logged in before? Casper From Alan.Coopersmith@Sun.COM Thu Aug 13 09:11:42 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGBgcs002899 for ; Thu, 13 Aug 2009 09:11:42 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DGBgLC003669 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 09:11:42 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB0067NOZIHT00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:11:42 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00AEEOYW5YB0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:11:20 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DGBK5d011677 for ; Thu, 13 Aug 2009 09:11:20 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00G00OWZDD00@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:11:20 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB00IENOYSXE70@fe-sfbay-09.sun.com>; Thu, 13 Aug 2009 09:11:17 -0700 (PDT) Date: Thu, 13 Aug 2009 09:11:16 -0700 From: Alan Coopersmith Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843780.809@sun.com> Sender: Alan.Coopersmith@Sun.COM To: Brian Cameron Cc: Darren J Moffat , Brian Cameron , lsarc-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A843B24.3010804@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 939 Brian Cameron wrote: >> The reason I ask is because the GNOME users and groups tool gets this >> wrong on Solaris. It correctly hides by default all those accounts with >> a uid < 100 but it doesn't hide the other reserved system accounts: >> >> nobody:x:60001:60001:NFS Anonymous Access User:/: >> noaccess:x:60002:60002:No Access User:/: >> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: > > Since these users do not have valid shells specified, these would not > be shown. A blank entry in the shell field indicates the system default shell should be used - on Solaris & OpenSolaris, that's "/bin/sh", which is a valid shell. If you're skipping those because they're blank do you also skip non-system accounts using that shorthand? (How do you determine which shells are valid? getusershell(3c) ?) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Darren.Moffat@sun.com Thu Aug 13 09:14:32 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGEVTw002955 for ; Thu, 13 Aug 2009 09:14:31 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DGESQ9025704 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 00:14:30 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00613P44VT00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:14:28 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00AGHP435QC0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:14:28 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DGEQkA019329 for ; Thu, 13 Aug 2009 16:14:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00D00O959J00@fe-emea-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 17:14:10 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB00785P3L9Z90@fe-emea-09.sun.com>; Thu, 13 Aug 2009 17:14:10 +0100 (BST) Date: Thu, 13 Aug 2009 17:14:01 +0100 From: Darren J Moffat Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843780.809@sun.com> Sender: Darren.Moffat@sun.com To: Brian Cameron Cc: Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A843BC9.5070607@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 5190 Brian Cameron wrote: >> 1. Lack of Failsafe session. >> >> I see this as a major issue. I use the failsafe session more when I'm >> not on the console than when I am. In particular I often use failsafe >> when connecting using VNC or a lot when using Sun Ray. A common use case >> for me is when connecting to the same server that already has another >> Sun Ray, VNC or console session - because I still don't trust GNOME not >> to screwup my config with multiple active session against he same home >> dir. > > After reviewing how the new GDM is installed on other distros, we > noticed that they are shipping a /usr/share/xsessions/xterm.desktop > which allows users to log into an xterm, rather than the full GNOME > desktop. So, we have also added this to our GDM builds and I have > updated the Exported Interface table to include this xterm.desktop > file. I think this will meet your needs. Certainly sounds like it will, thanks. >> 2. Default using face browser >> >> What is the definition of a system account ? > > I appreciate your concern about how the Face Browser works, since it > never worked very well with the old GDM, especially in environments > where NIS/LDAP is used. > > However, the new face browser is much more intelligent. It uses the > following logic to filter out system users: > > - Filters out all accounts under 100. > - Filters out all accounts that do not have a valid shell What is the definition of a valid shell ? > - It only adds users that are in /etc/passwd and users that have logged > in previously. So, no users will be shown who are NIS/LDAP users > unless they have logged in previously. So it bypasses nsswitch to lookup users ? > Note when the Face Browser is shown, you can click on the "Other" > (meaning "Other User") button and enter the username and password. > If you enter a username that is not a system user (UID<100), then > that user will show-up in the face browser in subsequent logins. > The list of recent users is managed by ConsoleKit and stored in > the file /var/log/ConsoleKit/history, so there is a unique history > per-machine. That seems reasonable, and means that it could actually be useful on some Sun Ray deployments as well. How many faces does it attempt to show ? Is there a limit in the history file at which it chooses to show none ? >> The reason I ask is because the GNOME users and groups tool gets this >> wrong on Solaris. It correctly hides by default all those accounts with >> a uid < 100 but it doesn't hide the other reserved system accounts: >> >> nobody:x:60001:60001:NFS Anonymous Access User:/: >> noaccess:x:60002:60002:No Access User:/: >> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: > > Since these users do not have valid shells specified, these would not > be shown. Yes they do they have /bin/sh as their shell because that is what an empty field means for /etc/passwd. passwd(4): login-shell is the user's initial shell program. If this field is empty, the default shell is /usr/bin/sh. Lets not discuss here if that makes sense for those accounts or not though. >> Does the face browser need to read anything in the users home dir ? If >> so it must be disabled by default since it can cause a downgrade attack >> if the users home directory is supposed to be mounted with Kerberos by >> default (but can fall back to sys). We have gone to great lengths over >> the years to ensure that no login program ever touches the users home >> directory until after pam_authenticate() and pam_setcred() have returned >> PAM_SUCCESS. > > Yes, the user's image file is loaded from the user's $HOME directory > before authentication. Is there an ability to place these elsewhere ? > As I explained before, we can disable the Face Browser if we want by > default. All other distros turn on the Face Browser by default, and > users disable it when needed. Note that if we choose to turn on the > Face Browser by default, that the Sun Ray install process would turn > it off. I think many of the cases where the Face Browser would not be > desired would be in Sun Ray environments (e.g. Trusted Solaris). So, > if we choose to turn on the Face Browser by default, many users who do > not want it (e.g. Sun Ray users) would have it turned off by default. > > But, if it is a requirement that Solaris by default does not touch the > user's $HOME directory before authentication, then the Face Browser > would need to be turned off by default. Do we want to be different > than other distros in this regard because of this kerberos requirement? That is good question. The security part of me says off. The on Sun network part of me says off (NFS kerberos home dir/privacy/Huge Sun Ray deployment) The "keeping up with the jones" part of me says turn it on The MacOS X user in me says turn it on. So that's a 50/50 split vote from me :-) > Obsolete interface, but I could add a mention in the onepager that > this has an impact on the SUNWgnome-themes package if you think > that is interesting. Not necessary given you've mentioned it in the email thread. -- Darren J Moffat From Brian.Cameron@sun.com Thu Aug 13 09:17:11 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGHBPf002975 for ; Thu, 13 Aug 2009 09:17:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DGH1GO007938 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 13 Aug 2009 10:17:11 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB0071ZP8L8F00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 09:17:09 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00A4RP8J5WE0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 09:17:07 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DGH7u4018033 for ; Thu, 13 Aug 2009 16:17:07 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00J00P4R4T00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 10:17:07 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB008T0P8HT440@mail-amer.sun.com>; Thu, 13 Aug 2009 10:17:06 -0600 (MDT) Date: Thu, 13 Aug 2009 11:17:27 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A83DF8D.2050805@sun.com> Sender: Brian.Cameron@sun.com To: Joerg Barfurth Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A843C97.8030405@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A83DF8D.2050805@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1060 Joerg: > This really has two separate parts: > > - Ability to select a terminal-only session: This ought be possible by > putting a suitable 'xterm.desktop' file into the /usr/share/xsessions > directory. Maybe we should ship such a file, but it should be possible > to disable it. Which leads to the question why this xsessions directory > is in /usr rather than in /etc ... Yes, we agree that having this is desirable, and we notice that other distros using the new GDM provide this. So we already went ahead and added this xterm.desktop file to our builds, and I updated the ARC materials to say so. > - Fallback in case of misconfiguration: iirc in case of certain > misconfigurations (e.g. if the selected xsession .desktop file points to > something non-existing), the session fell back to a failsafe session. Is > that (still) the case? No, the new GDM does not provide this any longer. User are expected to use VT switching to access the system to fix such problems, or to login via other mechanisms (if on a remote system, for example). Brian From Frank.Ludolph@sun.com Thu Aug 13 09:26:34 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGQWGs003032 for ; Thu, 13 Aug 2009 09:26:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DGQI6W001846 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 00:26:31 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00F0JPO6B600@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:26:30 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB006LZPO5QB60@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:26:30 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DGQTDl013782 for ; Thu, 13 Aug 2009 09:26:29 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00900PI1I000@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:26:29 -0700 (PDT) Received: from [129.146.69.43] ([unknown] [129.146.69.43]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB00I9APO3XEE0@fe-sfbay-09.sun.com>; Thu, 13 Aug 2009 09:26:27 -0700 (PDT) Date: Thu, 13 Aug 2009 09:26:04 -0700 From: Frank Ludolph Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843780.809@sun.com> Sender: Frank.Ludolph@sun.com To: Brian Cameron Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A843E9C.6090205@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) Status: RO Content-Length: 1005 Brian Cameron wrote: > > Darren: > > Thanks for your questions. > >> 3. Greeter themes >> >> What is the impact to the OpenSolaris branding given the new theme >> restrictions ? > > The new GDM greeter only allows the specification of the background > image to be used with the new GDM. Unless the "gdm" user is configured > to use a different background image, it will use the same background > that is shown by default for a user session. So, without any extra > work, it will already use the same branded background we use for the > user sessions. We can change that if we think a different branded > background for the GDM screen improves the branding. We will likely *not* want to use the default user session screen on the GDM screen. Aesthetic placement and sizing of a logo on the user session screen, if one exists at all, may not match up well with the log-in dialog size and placement on the GDM screen. Please allow for the specification of an alternative GDM screen background. Frank From Brian.Cameron@sun.com Thu Aug 13 09:30:41 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGUet5003062 for ; Thu, 13 Aug 2009 09:30:40 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DGUbit013420 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 09:30:40 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00F19PV4SW00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:30:40 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB006BYPV3Q560@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:30:39 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DGUddV023797 for ; Thu, 13 Aug 2009 16:30:39 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00J00P4R4T00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:30:39 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB008GTPV2T4B0@mail-amer.sun.com>; Thu, 13 Aug 2009 10:30:39 -0600 (MDT) Date: Thu, 13 Aug 2009 11:31:00 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <200908131605.n7DG5Y2r036417@dm-holland-02.uk.sun.com> Sender: Brian.Cameron@sun.com To: Casper.Dik@sun.com Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A843FC4.3010102@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <200908131605.n7DG5Y2r036417@dm-holland-02.uk.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1852 Casper: >>> nobody:x:60001:60001:NFS Anonymous Access User:/: >>> noaccess:x:60002:60002:No Access User:/: >>> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: >> >> Since these users do not have valid shells specified, these would not >> be shown. > > These actually have a valid shell (the default shell, /bin/sh, is used when > the password shell lists the empty string for the shell). Looking more closely at the GDM code, I see that it has a hardcoded list of users to not show in the face browser. These include: "bin" "root" "daemon" "adm" "lp" "sync" "shutdown" "halt" "mail" "news" "uucp" "operator" "nobody" GDM_USERNAME (normally the "gdm" user) "postgres" "pvm" "rpm" "nfsnobody" "pcap" > Can gdm determine which users are locked? No. GDM currently excluses users under MinimalUID (100), users without valid shells, and users in the above list. It should not be hard to add extra logic to avoid adding other users if appropriate. For example, is there a way to check which users are locked? I am sure code could be added to exclude other types of appropriate users. > Does gdm read /etc/passwd directly (to find out the "local" accounts?) > > Or does gdm use getent()? (This lists all users in files, nis, nis+ and > possibly LDAP) It uses fgetpwent(), so it does not use nsswitch.conf. >>> What about when NIS or LDAP is in use ? Do we really want GDM attempting >>> to display 38,000+ accounts ? >> >> As I explain above, this should not be an issue. > > So no getent? > > How does gdm detect which users logged in before? ConsoleKit (LSARC 2009/432) keeps track of users that are logged in in the /var/log/ConsoleKit/history file which is owned by (root:root) and has 644 permissions. The ck-history program is used by GDM to figure out which users to display. Brian From Darren.Moffat@sun.com Thu Aug 13 09:36:54 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGasQn003100 for ; Thu, 13 Aug 2009 09:36:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DGaqSP022478 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 10:36:53 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00E1HQ5G2100@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:36:52 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB005U4Q5E3PA0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:36:51 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DGao2P027268 for ; Thu, 13 Aug 2009 16:36:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00500Q2ISL00@fe-emea-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 17:36:35 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB007O1Q4L9Z90@fe-emea-09.sun.com>; Thu, 13 Aug 2009 17:36:22 +0100 (BST) Date: Thu, 13 Aug 2009 17:36:13 +0100 From: Darren J Moffat Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843FC4.3010102@sun.com> Sender: Darren.Moffat@sun.com To: Brian Cameron Cc: Casper.Dik@sun.com, Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8440FD.4070409@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <200908131605.n7DG5Y2r036417@dm-holland-02.uk.sun.com> <4A843FC4.3010102@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 1469 Brian Cameron wrote: > > Casper: > >>>> nobody:x:60001:60001:NFS Anonymous Access User:/: >>>> noaccess:x:60002:60002:No Access User:/: >>>> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: >>> >>> Since these users do not have valid shells specified, these would not >>> be shown. >> >> These actually have a valid shell (the default shell, /bin/sh, is used >> when >> the password shell lists the empty string for the shell). > > Looking more closely at the GDM code, I see that it has a hardcoded list > of users to not show in the face browser. These include: > > "bin" > "root" > "daemon" > "adm" > "lp" > "sync" > "shutdown" > "halt" > "mail" > "news" > "uucp" > "operator" > "nobody" > GDM_USERNAME (normally the "gdm" user) > "postgres" > "pvm" > "rpm" > "nfsnobody" > "pcap" That list looks very "Linuxy" :-) It needs to have noaccess and nobody4 added to it for OpenSolaris. and still does the < 100 check ? >> Can gdm determine which users are locked? > > No. GDM currently excluses users under MinimalUID (100), users without > valid shells, and users in the above list. > > It should not be hard to add extra logic to avoid adding other users > if appropriate. For example, is there a way to check which users are > locked? I am sure code could be added to exclude other types of > appropriate users. *LK* in as the first four chars of the password field. This is defined in shadow(4). -- Darren J Moffat From Robert.Doolittle@sun.com Thu Aug 13 09:38:00 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGbxZM003185 for ; Thu, 13 Aug 2009 09:38:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DGbxHk020736 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 09:37:59 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00907Q7BSZ00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:37:59 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00A9FQ7B5MF0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:37:59 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DGbxFe015313 for ; Thu, 13 Aug 2009 09:37:59 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00900PI1HZ00@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:37:59 -0700 (PDT) Received: from [172.16.0.25] ([unknown] [66.90.29.102]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB0088XQ792G20@fe-sfbay-09.sun.com>; Thu, 13 Aug 2009 09:37:59 -0700 (PDT) Date: Thu, 13 Aug 2009 12:37:57 -0400 From: Bob Doolittle Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843780.809@sun.com> Sender: Robert.Doolittle@sun.com To: Brian Cameron Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A844165.70306@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 793 Brian Cameron wrote: >> What about when NIS or LDAP is in use ? Do we really want GDM attempting >> to display 38,000+ accounts ? > As I explain above, this should not be an issue. In a server-based (e.g. thin client) desktop environment, the number of users who have ever utilized a server could still wind up in the hundreds or thousands. That's a lot of faces. There should be some upper limit, beyond which the face browser isn't utilized since it becomes impractical. There's also a $HOME access delay per user, if pictures are stored in $HOME. That could become substantial at some point particularly in an NFS-mounted $HOME environment. It's always possible for sites to turn off the face browser, but of course better if it were more intelligent and adaptive as above. -Bob From Nicolas.Williams@sun.com Thu Aug 13 09:44:05 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGi4ws003230 for ; Thu, 13 Aug 2009 09:44:05 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DGhoqM012802; Fri, 14 Aug 2009 00:44:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00A01QHAI000@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Aug 2009 09:43:58 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00A0KQH9HH00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Aug 2009 09:43:57 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7DGXJf8013552; Thu, 13 Aug 2009 11:33:19 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7DGXJbg013551; Thu, 13 Aug 2009 11:33:19 -0500 (CDT) Date: Thu, 13 Aug 2009 11:33:19 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843BC9.5070607@Sun.COM> To: Darren J Moffat Cc: Brian Cameron , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090813163319.GW10982@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1446 On Thu, Aug 13, 2009 at 05:14:01PM +0100, Darren J Moffat wrote: > >But, if it is a requirement that Solaris by default does not touch the > >user's $HOME directory before authentication, then the Face Browser > >would need to be turned off by default. Do we want to be different > >than other distros in this regard because of this kerberos requirement? > > That is good question. > The security part of me says off. > The on Sun network part of me says off > (NFS kerberos home dir/privacy/Huge Sun Ray deployment) > The "keeping up with the jones" part of me says turn it on > The MacOS X user in me says turn it on. > > So that's a 50/50 split vote from me :-) The *feature* (face browser) should be on in personal system installs. That would mean: whenever you use the interactive installed. And it should be OFF if you use AI. I say this even though I very much dislike the face browser idea. As for $HOME: login daemons _must_ keep their grubby paws off $HOME before user login is complete. If images and what not are kept in $HOME, then either move them out or cache them elsewhere. That, incidentally also solves the "local user" problem: let the user specify which accounts are "local" or, rather, "should appear in the face browser". By keeping track of that separately you avoid having to play heuristic games with /etc/passwd, and you get a chance to save a copy of users' face images outside their $HOMEs. Nico -- From Antonello.Cruz@sun.com Thu Aug 13 09:47:29 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGlTCs003279 for ; Thu, 13 Aug 2009 09:47:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DGlTnL025476 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 09:47:29 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00E09QN5NA00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:47:29 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB005TRQN43ZC0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:47:28 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DGlSYo016508 for ; Thu, 13 Aug 2009 09:47:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOB00300QK02Z00@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 09:47:28 -0700 (PDT) Received: from [129.146.228.12] ([unknown] [129.146.228.12]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOB00C62QMSZR50@fe-sfbay-10.sun.com>; Thu, 13 Aug 2009 09:47:16 -0700 (PDT) Date: Thu, 13 Aug 2009 09:47:16 -0700 From: Antonello Cruz Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843780.809@sun.com> Sender: Antonello.Cruz@sun.com To: Brian Cameron Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A844394.3080108@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 695 Brian Cameron wrote: >> Does the face browser need to read anything in the users home dir ? If >> so it must be disabled by default since it can cause a downgrade attack >> if the users home directory is supposed to be mounted with Kerberos by >> default (but can fall back to sys). We have gone to great lengths over >> the years to ensure that no login program ever touches the users home >> directory until after pam_authenticate() and pam_setcred() have returned >> PAM_SUCCESS. > > Yes, the user's image file is loaded from the user's $HOME directory > before authentication. Can't we save the image file along with the user info somewhere in the /var/log/ConsoleKit/history ? Antonello From Brian.Cameron@sun.com Thu Aug 13 09:55:01 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGt0xT003741 for ; Thu, 13 Aug 2009 09:55:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DGsjuN028506 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 17:54:59 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00I0BQZLG900@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:54:57 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB006C5QZLQ770@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:54:57 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DGsv6S022069 for ; Thu, 13 Aug 2009 16:54:57 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00100QBUAT00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:54:57 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB001DDQZKQL70@mail-amer.sun.com>; Thu, 13 Aug 2009 10:54:57 -0600 (MDT) Date: Thu, 13 Aug 2009 11:55:18 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843BC9.5070607@Sun.COM> Sender: Brian.Cameron@sun.com To: Darren J Moffat Cc: Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A844576.7020906@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 5872 Darren: >>> 2. Default using face browser >>> >>> What is the definition of a system account ? >> >> I appreciate your concern about how the Face Browser works, since it >> never worked very well with the old GDM, especially in environments >> where NIS/LDAP is used. >> >> However, the new face browser is much more intelligent. It uses the >> following logic to filter out system users: >> >> - Filters out all accounts under 100. >> - Filters out all accounts that do not have a valid shell > > What is the definition of a valid shell ? GDM calls fgetpwent(), and checks the value of pwent->pw_shell. It then calls getusershell() and if the pwent->pw_shell is in the list returned by getusershell() it is considered a valid shell. However, if the shell is "/sbin/nologin" or "/bin/false", then it is considered an invalid shell, even if getusershell() returns these as valid shells. >> - It only adds users that are in /etc/passwd and users that have logged >> in previously. So, no users will be shown who are NIS/LDAP users >> unless they have logged in previously. > > So it bypasses nsswitch to lookup users ? Right, by using fgetpwent(). >> Note when the Face Browser is shown, you can click on the "Other" >> (meaning "Other User") button and enter the username and password. >> If you enter a username that is not a system user (UID<100), then >> that user will show-up in the face browser in subsequent logins. >> The list of recent users is managed by ConsoleKit and stored in >> the file /var/log/ConsoleKit/history, so there is a unique history >> per-machine. > > That seems reasonable, and means that it could actually be useful on > some Sun Ray deployments as well. Yes. Actually, as the GDM maintainer, I have heard from a number of thin-client/terminal-server sysadmins that they like to use this feature. I have heard that people like to use it with up to several hundred users. > How many faces does it attempt to show ? Is there a limit in the history > file at which it chooses to show none ? No, it will show all the users. Note that if the user starts typing while the Face Browser is expecting the user to click on a user, it will automatically scroll the list to users that start with the entry typed. So it is fairly easy to find a specific username even if the list is long. >>> The reason I ask is because the GNOME users and groups tool gets this >>> wrong on Solaris. It correctly hides by default all those accounts with >>> a uid < 100 but it doesn't hide the other reserved system accounts: >>> >>> nobody:x:60001:60001:NFS Anonymous Access User:/: >>> noaccess:x:60002:60002:No Access User:/: >>> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: The "nobody" user is filtered out by default, though the other users would not be. >> Since these users do not have valid shells specified, these would not >> be shown. > > Yes they do they have /bin/sh as their shell because that is what an > empty field means for /etc/passwd. > > passwd(4): > > login-shell is the user's initial shell program. If this > field is empty, the default shell is > /usr/bin/sh. > > Lets not discuss here if that makes sense for those accounts or not though. If there are other mechanisms that GDM should use to filter out users, please let me know and we can fix the code to do additional filtering. >>> Does the face browser need to read anything in the users home dir ? If >>> so it must be disabled by default since it can cause a downgrade attack >>> if the users home directory is supposed to be mounted with Kerberos by >>> default (but can fall back to sys). We have gone to great lengths over >>> the years to ensure that no login program ever touches the users home >>> directory until after pam_authenticate() and pam_setcred() have returned >>> PAM_SUCCESS. >> >> Yes, the user's image file is loaded from the user's $HOME directory >> before authentication. > > Is there an ability to place these elsewhere ? Not currently, but that could be an enhancement. >> As I explained before, we can disable the Face Browser if we want by >> default. All other distros turn on the Face Browser by default, and >> users disable it when needed. Note that if we choose to turn on the >> Face Browser by default, that the Sun Ray install process would turn >> it off. I think many of the cases where the Face Browser would not be >> desired would be in Sun Ray environments (e.g. Trusted Solaris). So, >> if we choose to turn on the Face Browser by default, many users who do >> not want it (e.g. Sun Ray users) would have it turned off by default. >> >> But, if it is a requirement that Solaris by default does not touch the >> user's $HOME directory before authentication, then the Face Browser >> would need to be turned off by default. Do we want to be different >> than other distros in this regard because of this kerberos requirement? > > That is good question. > The security part of me says off. > The on Sun network part of me says off > (NFS kerberos home dir/privacy/Huge Sun Ray deployment) > The "keeping up with the jones" part of me says turn it on > The MacOS X user in me says turn it on. > > So that's a 50/50 split vote from me :-) This is probably a good topic for the inception review. I'm sure we can decide what the best system default is. >> Obsolete interface, but I could add a mention in the onepager that >> this has an impact on the SUNWgnome-themes package if you think >> that is interesting. > > Not necessary given you've mentioned it in the email thread. I went ahead and added the following text to section "4.5 Dependencies" just so this is more clear in the onepager. Note that the GDM themes previously delivered to /usr/share/gdm/themes by the SUNWgnome-themes package will no longer be delivered once the new GDM is integrated, since they will no longer be used. Brian From nicolas.williams@sun.com Thu Aug 13 09:57:27 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DGvRcP003907 for ; Thu, 13 Aug 2009 09:57:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DGvPLi025500; Thu, 13 Aug 2009 09:57:26 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00I1FR3PQO00@brm-avmta-1.central.sun.com>; Thu, 13 Aug 2009 10:57:25 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB006LTR3OQ480@brm-avmta-1.central.sun.com>; Thu, 13 Aug 2009 10:57:24 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7DGkjUP013560; Thu, 13 Aug 2009 11:46:45 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7DGkjuh013559; Thu, 13 Aug 2009 11:46:45 -0500 (CDT) Date: Thu, 13 Aug 2009 11:46:45 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090813163319.GW10982@Sun.COM> To: Darren J Moffat Cc: Brian Cameron , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090813164645.GI1035@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 589 Even better: leave the face browser on by default, but by default leave the list of users to appear in it _empty_. Then the installer folks could do something very cute: - if there's a webcam available on install, then ask the user if they want to have a pic taken for the face browser, and if they say yes, then take it and put the user in the face browser list. By keeping a separate list of face browser users you solve the local user problem and the $HOME problem (when the user logs in, and whenever the user updates their face pic, update a cached copy of their face pic). From Darren.Moffat@sun.com Thu Aug 13 10:14:01 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DHE1X5004373 for ; Thu, 13 Aug 2009 10:14:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DHDq47011832 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 18:14:00 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00G0VRVA4R00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:13:58 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB005K5RV93TE0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:13:58 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DHDuvd000442 for ; Thu, 13 Aug 2009 17:13:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOB00A00R5SVZ00@fe-emea-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 18:13:45 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOB009BURUXS170@fe-emea-10.sun.com>; Thu, 13 Aug 2009 18:13:45 +0100 (BST) Date: Thu, 13 Aug 2009 18:13:36 +0100 From: Darren J Moffat Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090813164645.GI1035@Sun.COM> Sender: Darren.Moffat@sun.com To: Nicolas Williams Cc: Brian Cameron , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8449C0.5040600@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <20090813164645.GI1035@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 803 Nicolas Williams wrote: > Even better: leave the face browser on by default, but by default leave > the list of users to appear in it _empty_. Then the installer folks > could do something very cute: > > - if there's a webcam available on install, then ask the user if they > want to have a pic taken for the face browser, and if they say yes, > then take it and put the user in the face browser list. > > By keeping a separate list of face browser users you solve the local > user problem and the $HOME problem (when the user logs in, and whenever > the user updates their face pic, update a cached copy of their face > pic). This also helps with user privacy issues - they have to explicitly opt in for each system rather than just having something in their home dir. -- Darren J Moffat From John.Fischer@sun.com Thu Aug 13 10:33:21 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DHXKpg004835 for ; Thu, 13 Aug 2009 10:33:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DHX9f0009879 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 01:33:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00H07SRIB200@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:33:18 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB0053YSRH3WF0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 10:33:17 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DHXHoP011574 for ; Thu, 13 Aug 2009 17:33:17 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00I00SIA3400@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 11:33:17 -0600 (MDT) Received: from [192.168.10.6] ([unknown] [76.20.56.47]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB00HTZSRCXI80@mail-amer.sun.com>; Thu, 13 Aug 2009 11:33:13 -0600 (MDT) Date: Thu, 13 Aug 2009 10:31:10 -0700 From: John Fischer Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843FC4.3010102@sun.com> Sender: John.Fischer@sun.com To: Brian Cameron Cc: Casper.Dik@sun.com, Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Reply-to: John.Fischer@sun.com Message-id: <4A844DDE.3070806@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <200908131605.n7DG5Y2r036417@dm-holland-02.uk.sun.com> <4A843FC4.3010102@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090505) Status: RO Content-Length: 2116 Brian, The list seems overly static. Why not have a configuration file for GDM that has an allow/deny type of syntax? Thanks, John Brian Cameron wrote: > > Casper: > >>>> nobody:x:60001:60001:NFS Anonymous Access User:/: >>>> noaccess:x:60002:60002:No Access User:/: >>>> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: >>> >>> Since these users do not have valid shells specified, these would not >>> be shown. >> >> These actually have a valid shell (the default shell, /bin/sh, is used >> when >> the password shell lists the empty string for the shell). > > Looking more closely at the GDM code, I see that it has a hardcoded list > of users to not show in the face browser. These include: > > "bin" > "root" > "daemon" > "adm" > "lp" > "sync" > "shutdown" > "halt" > "mail" > "news" > "uucp" > "operator" > "nobody" > GDM_USERNAME (normally the "gdm" user) > "postgres" > "pvm" > "rpm" > "nfsnobody" > "pcap" > >> Can gdm determine which users are locked? > > No. GDM currently excluses users under MinimalUID (100), users without > valid shells, and users in the above list. > > It should not be hard to add extra logic to avoid adding other users > if appropriate. For example, is there a way to check which users are > locked? I am sure code could be added to exclude other types of > appropriate users. > >> Does gdm read /etc/passwd directly (to find out the "local" accounts?) >> >> Or does gdm use getent()? (This lists all users in files, nis, nis+ and >> possibly LDAP) > > It uses fgetpwent(), so it does not use nsswitch.conf. > >>>> What about when NIS or LDAP is in use ? Do we really want GDM >>>> attempting >>>> to display 38,000+ accounts ? >>> >>> As I explain above, this should not be an issue. >> >> So no getent? >> >> How does gdm detect which users logged in before? > > ConsoleKit (LSARC 2009/432) keeps track of users that are logged in > in the /var/log/ConsoleKit/history file which is owned by (root:root) > and has 644 permissions. The ck-history program is used by GDM to > figure out which users to display. > > Brian > From Brian.Cameron@sun.com Thu Aug 13 11:24:34 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DIOYn7006613 for ; Thu, 13 Aug 2009 11:24:34 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DIOTcq013668 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 12:24:34 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00N19V4W1300@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 11:24:32 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00ACAV4WHHF0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 11:24:32 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DIOW1W018612 for ; Thu, 13 Aug 2009 18:24:32 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOB00C00USGWJ00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 12:24:32 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOB009A0V4VJF90@mail-amer.sun.com>; Thu, 13 Aug 2009 12:24:32 -0600 (MDT) Date: Thu, 13 Aug 2009 13:24:53 -0500 From: Brian Cameron Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843B24.3010804@sun.com> Sender: Brian.Cameron@sun.com To: Alan Coopersmith Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A845A75.9010907@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843B24.3010804@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1505 Alan: >>> The reason I ask is because the GNOME users and groups tool gets this >>> wrong on Solaris. It correctly hides by default all those accounts with >>> a uid< 100 but it doesn't hide the other reserved system accounts: >>> >>> nobody:x:60001:60001:NFS Anonymous Access User:/: >>> noaccess:x:60002:60002:No Access User:/: >>> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: >> >> Since these users do not have valid shells specified, these would not >> be shown. > > A blank entry in the shell field indicates the system default shell should > be used - on Solaris& OpenSolaris, that's "/bin/sh", which is a valid > shell. If you're skipping those because they're blank do you also skip > non-system accounts using that shorthand? Correct. The way the code works is that it calls fgetpwent() and if /etc/passwd contains no value, then that account does not show up in the Face Browser. So, users would need to avoid using the shorthand if they want the user to show up in the GDM Face Browser. If that is inappropriate, then we could change the logic to work a different way. Note that the checking of what users are valid or not is done by the GDM greeter which runs as the "gdm" user, so it does not have the ability to read /etc/shadow directly. > (How do you determine which shells are valid? getusershell(3c) ?) Correct. Though the code also checks for "/sbin/nologin" and "/bin/false" and considers those invalid shells even if getusershell reports them. Brian From Brian.Cameron@sun.com Thu Aug 13 11:26:21 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DIQKvc006671 for ; Thu, 13 Aug 2009 11:26:20 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DIQF0W026356 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 19:26:19 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00K09V7UUX00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 11:26:18 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00HB5V7TSA30@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 11:26:18 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DIQHaJ018527 for ; Thu, 13 Aug 2009 18:26:17 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOB00C00USGWJ00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 12:26:17 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOB00907V7LJFA0@mail-amer.sun.com>; Thu, 13 Aug 2009 12:26:10 -0600 (MDT) Date: Thu, 13 Aug 2009 13:26:31 -0500 From: Brian Cameron Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A843E9C.6090205@sun.com> Sender: Brian.Cameron@sun.com To: Frank Ludolph Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A845AD7.8060406@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843E9C.6090205@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1199 Frank: >> The new GDM greeter only allows the specification of the background >> image to be used with the new GDM. Unless the "gdm" user is configured >> to use a different background image, it will use the same background >> that is shown by default for a user session. So, without any extra >> work, it will already use the same branded background we use for the >> user sessions. We can change that if we think a different branded >> background for the GDM screen improves the branding. > We will likely *not* want to use the default user session screen on the > GDM screen. Aesthetic placement and sizing of a logo on the user session > screen, if one exists at all, may not match up well with the log-in > dialog size and placement on the GDM screen. Please allow for the > specification of an alternative GDM screen background. It is not a problem to define a different background image for the new GDM. One just needs to be provided and the appropriate configuration key set by default. I can provide you with binaries of the new SUNWgnome-display-mgr packages if you want to start trying it out and looking more into how to properly brand the background. Just ask me off-list. Brian From Darren.Moffat@sun.com Thu Aug 13 11:32:57 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DIWvE7006832 for ; Thu, 13 Aug 2009 11:32:57 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DIWu7e011628 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 11:32:57 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00L05VIWAI00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 11:32:56 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00H5VVIUSG30@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 11:32:55 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DIWsbf005642 for ; Thu, 13 Aug 2009 18:32:54 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00L00VE12T00@fe-emea-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 19:32:42 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB007FAVIH9ZA0@fe-emea-09.sun.com>; Thu, 13 Aug 2009 19:32:41 +0100 (BST) Date: Thu, 13 Aug 2009 19:32:33 +0100 From: Darren J Moffat Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A845A75.9010907@sun.com> Sender: Darren.Moffat@sun.com To: Brian Cameron Cc: Alan Coopersmith , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A845C41.8090601@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843B24.3010804@sun.com> <4A845A75.9010907@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 1711 Brian Cameron wrote: > > Alan: > >>>> The reason I ask is because the GNOME users and groups tool gets this >>>> wrong on Solaris. It correctly hides by default all those accounts with >>>> a uid< 100 but it doesn't hide the other reserved system accounts: >>>> >>>> nobody:x:60001:60001:NFS Anonymous Access User:/: >>>> noaccess:x:60002:60002:No Access User:/: >>>> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: >>> >>> Since these users do not have valid shells specified, these would not >>> be shown. >> >> A blank entry in the shell field indicates the system default shell >> should >> be used - on Solaris& OpenSolaris, that's "/bin/sh", which is a valid >> shell. If you're skipping those because they're blank do you also skip >> non-system accounts using that shorthand? > > Correct. The way the code works is that it calls fgetpwent() and if > /etc/passwd contains no value, then that account does not show up in the > Face Browser. So, users would need to avoid using the shorthand if they > want the user to show up in the GDM Face Browser. Which nameservice a user is in or not is not the correct way to determine wither or not the face browser should be used. > If that is inappropriate, then we could change the logic to work a > different way. Yes I think it is inappropriate. I think this needs to be specific to GDM config rather than derived based on assumptions about specific nameservice content. Maybe rather than specific to GDM there should be a freedesktop.org spec for faces images and optin/optout of face browsing in general. Since this doesn't apply just to GDM but ideally to screenlock and fast-user switching applets. -- Darren J Moffat From Brian.Cameron@sun.com Thu Aug 13 11:44:10 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DIi9iK006970 for ; Thu, 13 Aug 2009 11:44:10 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DIi6Hn015199 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 14 Aug 2009 02:44:08 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00207W1KLF00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 11:44:08 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB0002FW1K6F90@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 11:44:08 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DIi8JE025887 for ; Thu, 13 Aug 2009 18:44:08 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00G00VO1XP00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 12:44:08 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB00453W17HY70@mail-amer.sun.com>; Thu, 13 Aug 2009 12:43:55 -0600 (MDT) Date: Thu, 13 Aug 2009 13:44:17 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090812231144.GS10982@Sun.COM> Sender: Brian.Cameron@sun.com To: Nicolas Williams Cc: Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A845F01.1050209@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <20090812231144.GS10982@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 958 Nicolas: > Any way to make sure that A11Y is enabled by default, with toggle keys > also enabled by default (but actual A11Y features disabled by default)? I am not sure what you mean by a11y being enabled but actual features disabled. If you check "text-to-speech" in the a11y dialog, this launches the configured text-to-speech program (e.g. orca) immediately. The new GDM will honor the system or gdm user preferences for launching AT programs when the GDM login GUI starts up. So it is easy to configure a system, or a LiveCD so that a particular AT program or programs be used with the GDM login GUI. I understand that the Solaris a11y team provides an accessibility LiveCD with different choices in the GRUB menu which launch GNOME with certain a11y features turned on by default, depending on the GRUB selection. So, it would be easy to also configure such a LiveCD to make GDM to launch the appropriate default AT programs as desired. Brian From Nicolas.Williams@sun.com Thu Aug 13 12:07:22 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DJ7LGc007531 for ; Thu, 13 Aug 2009 12:07:22 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DJ7Fav022748; Thu, 13 Aug 2009 20:07:19 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB0080PX47ZJ00@brm-avmta-1.central.sun.com>; Thu, 13 Aug 2009 13:07:19 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB0088GX47UW00@brm-avmta-1.central.sun.com>; Thu, 13 Aug 2009 13:07:19 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7DIud3D013651; Thu, 13 Aug 2009 13:56:39 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7DIudB2013650; Thu, 13 Aug 2009 13:56:39 -0500 (CDT) Date: Thu, 13 Aug 2009 13:56:39 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A845F01.1050209@sun.com> To: Brian Cameron Cc: Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090813185639.GA10982@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <20090812231144.GS10982@Sun.COM> <4A845F01.1050209@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1429 On Thu, Aug 13, 2009 at 01:44:17PM -0500, Brian Cameron wrote: > >Any way to make sure that A11Y is enabled by default, with toggle keys > >also enabled by default (but actual A11Y features disabled by default)? > > I am not sure what you mean by a11y being enabled but actual features > disabled. If you check "text-to-speech" in the a11y dialog, this > launches the configured text-to-speech program (e.g. orca) immediately. I'd like keyboard A11Y to be enabled, but actual keyboard A11Y features disable, with toggle keys enabled. I.e., press and release shift five times in a row and get a pop-up asking whether to enable sticky keys, for example. > The new GDM will honor the system or gdm user preferences for launching > AT programs when the GDM login GUI starts up. So it is easy to > configure a system, or a LiveCD so that a particular AT program or > programs be used with the GDM login GUI. Some A11Y features shouldn't have to be configured. There should be a quick way to enabled those, such as with toggle keys. > I understand that the Solaris a11y team provides an accessibility > LiveCD with different choices in the GRUB menu which launch GNOME with > certain a11y features turned on by default, depending on the GRUB > selection. So, it would be easy to also configure such a LiveCD to > make GDM to launch the appropriate default AT programs as desired. Yes, I've noticed this, and it's very nice! From Brian.Cameron@Sun.COM Thu Aug 13 12:29:05 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DJT5oD011357 for ; Thu, 13 Aug 2009 12:29:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DJSxUb004636 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 12:29:04 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00125Y4FVD00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 12:29:03 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00HAHY4ERU60@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 12:29:02 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DJT1Rv014848 for ; Thu, 13 Aug 2009 19:29:01 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00G00VO1XP00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 13:29:01 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB00AANY4B2HC0@mail-amer.sun.com>; Thu, 13 Aug 2009 13:28:59 -0600 (MDT) Date: Thu, 13 Aug 2009 14:29:21 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8440FD.4070409@Sun.COM> Sender: Brian.Cameron@Sun.COM To: Darren J Moffat Cc: Casper.Dik@Sun.COM, Brian Cameron , lsarc-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A846991.2040106@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <200908131605.n7DG5Y2r036417@dm-holland-02.uk.sun.com> <4A843FC4.3010102@sun.com> <4A8440FD.4070409@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1670 Darren: >> Looking more closely at the GDM code, I see that it has a hardcoded list >> of users to not show in the face browser. These include: >> >> "bin" >> "root" >> "daemon" >> "adm" >> "lp" >> "sync" >> "shutdown" >> "halt" >> "mail" >> "news" >> "uucp" >> "operator" >> "nobody" >> GDM_USERNAME (normally the "gdm" user) >> "postgres" >> "pvm" >> "rpm" >> "nfsnobody" >> "pcap" > > That list looks very "Linuxy" :-) > > It needs to have noaccess and nobody4 added to it for OpenSolaris. It should not be a problem to add "noaccess" and "nobody4" to the list. However, these users do not show up in the Face Browser because GDM uses fgetpwent and checks to see if the user's SHELL is NULL. Since these accounts have no shell defined in /etc/passwd, they are already filtered out. > and still does the < 100 check ? > >>> Can gdm determine which users are locked? >> >> No. GDM currently excluses users under MinimalUID (100), users without >> valid shells, and users in the above list. >> >> It should not be hard to add extra logic to avoid adding other users >> if appropriate. For example, is there a way to check which users are >> locked? I am sure code could be added to exclude other types of >> appropriate users. > > *LK* in as the first four chars of the password field. This is defined > in shadow(4). Note that the code which checks if users are valid is run by the login GUI currently, which runs as the "gdm" user. Does a process running as the "gdm" user have the ability to check this field for the "*LK*" string? Is it necessary to check for this if GDM already filters out accounts that do not have a shell defined in /etc/passwd? Brian From Brian.Cameron@sun.com Thu Aug 13 12:31:46 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DJVkhZ011395 for ; Thu, 13 Aug 2009 12:31:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DJVkBl006011 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 12:31:46 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB0020NY8X1400@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 12:31:45 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00HHXY8WRU60@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 12:31:44 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DJVhHW017753 for ; Thu, 13 Aug 2009 19:31:43 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOB00K00XKF4X00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 13:31:43 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOB00GL6Y8MPY70@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 13:31:35 -0600 (MDT) Date: Thu, 13 Aug 2009 14:31:57 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A844DDE.3070806@sun.com> Sender: Brian.Cameron@sun.com To: John.Fischer@sun.com Cc: Casper.Dik@sun.com, Darren J Moffat , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A846A2D.2060709@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <200908131605.n7DG5Y2r036417@dm-holland-02.uk.sun.com> <4A843FC4.3010102@sun.com> <4A844DDE.3070806@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 2430 John: > The list seems overly static. Why not have a configuration file for > GDM that has an allow/deny type of syntax? The old GDM had such configuration keys for specifying that users be allowed or denied inclusion on the Face Browers. However, the new GDM does not yet support this sort of configuration. If we think it is needed, we could work with the upstream community to add this feature back. Brian > Brian Cameron wrote: >> >> Casper: >> >>>>> nobody:x:60001:60001:NFS Anonymous Access User:/: >>>>> noaccess:x:60002:60002:No Access User:/: >>>>> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: >>>> >>>> Since these users do not have valid shells specified, these would not >>>> be shown. >>> >>> These actually have a valid shell (the default shell, /bin/sh, is >>> used when >>> the password shell lists the empty string for the shell). >> >> Looking more closely at the GDM code, I see that it has a hardcoded list >> of users to not show in the face browser. These include: >> >> "bin" >> "root" >> "daemon" >> "adm" >> "lp" >> "sync" >> "shutdown" >> "halt" >> "mail" >> "news" >> "uucp" >> "operator" >> "nobody" >> GDM_USERNAME (normally the "gdm" user) >> "postgres" >> "pvm" >> "rpm" >> "nfsnobody" >> "pcap" >> >>> Can gdm determine which users are locked? >> >> No. GDM currently excluses users under MinimalUID (100), users without >> valid shells, and users in the above list. >> >> It should not be hard to add extra logic to avoid adding other users >> if appropriate. For example, is there a way to check which users are >> locked? I am sure code could be added to exclude other types of >> appropriate users. >> >>> Does gdm read /etc/passwd directly (to find out the "local" accounts?) >>> >>> Or does gdm use getent()? (This lists all users in files, nis, nis+ and >>> possibly LDAP) >> >> It uses fgetpwent(), so it does not use nsswitch.conf. >> >>>>> What about when NIS or LDAP is in use ? Do we really want GDM >>>>> attempting >>>>> to display 38,000+ accounts ? >>>> >>>> As I explain above, this should not be an issue. >>> >>> So no getent? >>> >>> How does gdm detect which users logged in before? >> >> ConsoleKit (LSARC 2009/432) keeps track of users that are logged in >> in the /var/log/ConsoleKit/history file which is owned by (root:root) >> and has 644 permissions. The ck-history program is used by GDM to >> figure out which users to display. >> >> Brian >> From Brian.Cameron@sun.com Thu Aug 13 12:39:25 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DJdOEW011477 for ; Thu, 13 Aug 2009 12:39:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DJdLmv050388 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 13:39:24 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB0090JYLNPG00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 12:39:23 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB0040TYLMDK80@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 12:39:23 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DJdMXa020768 for ; Thu, 13 Aug 2009 19:39:22 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00G00VO1XP00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 13:39:22 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB00212YKYO700@mail-amer.sun.com>; Thu, 13 Aug 2009 13:38:58 -0600 (MDT) Date: Thu, 13 Aug 2009 14:39:20 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090813185639.GA10982@Sun.COM> Sender: Brian.Cameron@sun.com To: Nicolas Williams Cc: Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A846BE8.5090000@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <20090812231144.GS10982@Sun.COM> <4A845F01.1050209@sun.com> <20090813185639.GA10982@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 377 Nicolas: > I'd like keyboard A11Y to be enabled, but actual keyboard A11Y features > disable, with toggle keys enabled. I.e., press and release shift five > times in a row and get a pop-up asking whether to enable sticky keys, > for example. Yes, X server a11y features should work with the new GDM. You can also turn on/off such features via the GDM a11y dialog. Brian From Brian.Cameron@Sun.COM Thu Aug 13 13:08:30 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DK8Tpg012072 for ; Thu, 13 Aug 2009 13:08:30 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DK8ODU027358 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 04:08:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOB00407ZY2JK00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 13:08:26 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOB00HGMZY2SG80@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 13:08:26 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DK8PYh017639 for ; Thu, 13 Aug 2009 20:08:25 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOB00100Z96VK00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 14:08:25 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOB002GAZXNO7D0@mail-amer.sun.com>; Thu, 13 Aug 2009 14:08:12 -0600 (MDT) Date: Thu, 13 Aug 2009 15:08:34 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090813163319.GW10982@Sun.COM> Sender: Brian.Cameron@Sun.COM To: Nicolas Williams Cc: Darren J Moffat , Brian Cameron , lsarc-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A8472C2.9030900@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 5631 Nicolas: > This could happen at install time (so the face pic is available on > first login). Yes, asking at install time for any users that are added to have a face pic seems a good idea, though I think this is off-topic for this case. > Else it could happen on first login. I don't care so > much about the details of how face pics are acquired (OT for this > case) as I do about making sure that GDM: > > a) doesn't depend on heuristics to determine what users are to appear > in the face browser, > b) doesn't touch $HOME until after pam_setcred(h, PAM_ESTABLISH_CRED) > is done[*]. > > (a) means no surprises when some part of the system changes in a way > that might interact badly with such heuristics. Also, an explicit > list allows users to not necessarily be local, which is nice too -- > GDM could even have an option to display only the last few logged in > users in the face browser, which could be useful in a corporate > environment (if that's what people want). I am fairly confident that a change to hardcode the list to a configuration key would not be accepted upstream. The upstream GDM community has worked hard to try and make the Face Browser more usable for the average user. In other words, people want GDM to "just work" out of the box, without needing to do special configuration to specify a list of users to include. However, we could probably make changes to add configuration to make GDM more flexible in how it uses or does not use heuristics. For example, the following sorts of changes could probably get upstream: - A configuration key to specify that the heuristics are not used, but that users are added to the list of users after they have logged in for the first time. This is the current default for NIS users, but it could be the way it works for all users. - Configuration keys to specify what users are to be included in the list all the time, or never. - Fixes to the existing heuristics so that they work better on Solaris. Obviously we can patch GDM to work any way we want. However, I would like to avoid adding Solaris-specific configuration. So we should try to enhance GDM in ways that our improvements can go upstream. If the Face Browser is too problematic on Solaris, we can also just completely disable it in a way that users can't turn it on. This would be my recommendation if this discussion gets too bogged down. It is not a necessary feature. > (b) means that users need not be local (see previous item), or may > have special automounted home directories. And it means that GDM > need not apply any heuristics to determine whether it would be bad > for it to touch the user's $HOME prior to completing credential setup. > > [*] If a homedir is shared -o sec=krb5:sys and the local > mount/automount doesn't set -o sec=krb5, and if the host lacks > Kerberos credentials (laptops usually lack host creds), THEN > touching the user's $HOME as euid == 0 or before acquiring the > user's Kerberos credentials causes the homedir to be mounted > with sec=sys. Not having this problem is very important for > enabling Kerberos deployments to progress at non-instantaneous > rates. > > Avoiding this problem is, I suspect, one of the reasons for the > GDM local user heuristics, but you can see that those heuristics > are not robust. Better avoid the heuristics and go with an > explicit list of users + face pic caching. This is a more serious issue with the new GDM. Actually the new GDM accesses the user's $HOME directory in two situations before pam_setcred. 1) After PAM_USER is specified (normally after the username entry), the user's $HOME/.dmrc file is accessed to find out the user's default session/language choices, which are shown in the GUI as the defaults. 2) When the Face Browser is used, the $HOME/.face file is accessed to get the user's face image to show in the Face Browser. So, GDM needs some work to make it work properly with kerberos. After talking with the upstream GDM developers, the following change would be acceptable to go upstream: - The SUNWgnome-display-mgr-root package would install a directory /var/cache/gdm. - At run-time GDM would create a directory /var/cache/gdm/user-$uid when a user logs in, if the directory does not already exist. In this file will be placed two files: dmrc and face. - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then GDM will log the user into the default session/language or whichever ones they selected in the GUI. Then it will save the dmrc file to the cache with the default settings. On next login, the defaults will be read from the cache and not the user's $HOME directory. - On first login the /var/cache/gdm/user-$uid/face file will not exist so the user will see a generic user icon for their face. After authentication, GDM will check if the user has a defined face and copy it to the cached file. Also, on logout, GDM will check again if the user has a defined face and copy it to the cached file. This way the face image will be available on next login if the user defined it during their session. Obviously the face image will only be copied to the cache if one is not already in the cache or if the cached file is older. Using this technique, GDM would only access the face images from the cache, and not the user's $HOME directory. If it is a TCR requirement for GDM to work this way before it integrates, then we can make it work this way. Is that reasonable? Brian From Alan.Coopersmith@Sun.COM Thu Aug 13 13:40:04 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DKe33q012830 for ; Thu, 13 Aug 2009 13:40:04 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DKdxNV017262 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 21:40:03 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC006031EPNJ00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 13:40:01 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC00HTZ1EORZC0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 13:40:00 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DKe0Ed012826 for ; Thu, 13 Aug 2009 13:40:00 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOC00A001DPUS00@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 13:40:00 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOC00B8X1EO3GF0@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 13:40:00 -0700 (PDT) Date: Thu, 13 Aug 2009 13:40:00 -0700 From: Alan Coopersmith Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A844576.7020906@sun.com> Sender: Alan.Coopersmith@Sun.COM To: Brian Cameron Cc: Darren J Moffat , lsarc-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A847A20.5030705@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <4A844576.7020906@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 440 Brian Cameron wrote: > This is probably a good topic for the inception review. Wait - is this a fasttrack or a full case? Since you sent out the spec to LSARC looking like a fasttrack, I think we all assumed this was the fasttrack review, but I've just realized you never actually said it was a fasttrack or set a timer. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Nicolas.Williams@sun.com Thu Aug 13 13:40:46 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DKejnW012864 for ; Thu, 13 Aug 2009 13:40:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DKea8Y017627; Thu, 13 Aug 2009 21:40:43 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC006031FVPK00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Aug 2009 13:40:43 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC00HOR1FUSAC0@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Aug 2009 13:40:43 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7DKU4Ng013704; Thu, 13 Aug 2009 15:30:04 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7DKU4RM013703; Thu, 13 Aug 2009 15:30:04 -0500 (CDT) Date: Thu, 13 Aug 2009 15:30:04 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8472C2.9030900@sun.com> To: Brian Cameron Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090813203004.GC10982@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 3229 On Thu, Aug 13, 2009 at 03:08:34PM -0500, Brian Cameron wrote: > I am fairly confident that a change to hardcode the list to a ^^^^^^^^ > configuration key would not be accepted upstream. The upstream GDM > community has worked hard to try and make the Face Browser more usable > for the average user. In other words, people want GDM to "just work" > out of the box, without needing to do special configuration to specify > a list of users to include. I never said anything about "hardcoding" anything. Quite the contrary. Clearly GDM's face browser cannot ""just work" out of the box" if there are no face pics, and when the user takes/installs the face pic the user can then just be added (silently or otherwise) to the face browser list. I see nothing controversial about that, and plenty controversial about the heuristics you've described. I think the subject ought to at least be broached with the upstream community, and if they'll take #ifdef SOLARIS code from you anyways, then just do it. But, you've proffered a solution that gets close -- let's work with it: > After talking with the upstream GDM developers, the following change > would be acceptable to go upstream: > > - The SUNWgnome-display-mgr-root package would install a directory > /var/cache/gdm. Yes, let's cache dmrc and face pics. > - At run-time GDM would create a directory /var/cache/gdm/user-$uid > when a user logs in, if the directory does not already exist. In > this file will be placed two files: dmrc and face. Yup. > - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then > GDM will log the user into the default session/language or whichever > ones they selected in the GUI. Then it will save the dmrc file to > the cache with the default settings. On next login, the defaults > will be read from the cache and not the user's $HOME directory. The cache should also be updated at logout time, if at all possible. (But the system component doing a logout-time update wouldn't necessarily be part of GDM.) > - On first login the /var/cache/gdm/user-$uid/face file will not > exist so the user will see a generic user icon for their face. > After authentication, GDM will check if the user has a defined > face and copy it to the cached file. Also, on logout, GDM will check > again if the user has a defined face and copy it to the cached file. > This way the face image will be available on next login if the user > defined it during their session. Obviously the face image will only > be copied to the cache if one is not already in the cache or if the > cached file is older. Using this technique, GDM would only access > the face images from the cache, and not the user's $HOME directory. IMO an option to not include users in the face browser who lack cached face pics is necessary: when that option is enabled then GDM would not need any local user heuristics. I find such heuristics rather objectionable. > If it is a TCR requirement for GDM to work this way before it > integrates, then we can make it work this way. > > Is that reasonable? It is reasonable, except for that one minor issue mentioned above. Thanks, Nico -- From Brian.Cameron@sun.com Thu Aug 13 14:07:49 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DL7mvJ013731 for ; Thu, 13 Aug 2009 14:07:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DL7dm0026035 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 05:07:47 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00L052OXAX00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 14:07:45 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC00JAY2OWZD40@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 14:07:44 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DL7i6D024808 for ; Thu, 13 Aug 2009 21:07:44 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOC00J002J35W00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 15:07:44 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOC00LO42OQHS40@mail-amer.sun.com>; Thu, 13 Aug 2009 15:07:38 -0600 (MDT) Date: Thu, 13 Aug 2009 16:08:00 -0500 From: Brian Cameron Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A845C41.8090601@Sun.COM> Sender: Brian.Cameron@sun.com To: Darren J Moffat Cc: Alan Coopersmith , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8480B0.2070602@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843B24.3010804@sun.com> <4A845A75.9010907@sun.com> <4A845C41.8090601@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 4220 Darren: >> Correct. The way the code works is that it calls fgetpwent() and if >> /etc/passwd contains no value, then that account does not show up in the >> Face Browser. So, users would need to avoid using the shorthand if they >> want the user to show up in the GDM Face Browser. > > Which nameservice a user is in or not is not the correct way to > determine wither or not the face browser should be used. I disagree. The Face Browser was designed to be useful in one very common use-case. The situation where a person has a laptop machine with multiple users to provide a login experience similar to what one gets with other popular operating systems. An easy-to-use click on my name, type my password, and login process. All other distros which ship GDM turn on this feature by default since this is their most common use case. They do this with the understanding that sysadmins who want to do more sophisticated things (e.g. use other PAM stacks, use NIS/LDAP in ways that would make the list of users shown cumbersome, have security issues with the Face Browser, etc.) will turn it off. Whether we enable this feature by default or not depends on whether Sun also wants to facilitate this common use-case or not. While I can also imagine that the Face Browser may be useful in some terminal server or thin-client situations (e.g. when the number of users is not cumbersome and the default PAM stack is used), or in some situations where NIS/LDAP is used, these are not use cases that the Face Browser is designed to support well. If Sun wants to invest time and energy to make the Face Browser work better or support more use cases, we can consider doing so. However, I do not foresee such work being a part of this case unless we are able to decide on a solution that is not very cumbersome to implement. >> If that is inappropriate, then we could change the logic to work a >> different way. > > Yes I think it is inappropriate. I think this needs to be specific to > GDM config rather than derived based on assumptions about specific > nameservice content. Maybe rather than specific to GDM there should be a > freedesktop.org spec for faces images and optin/optout of face browsing > in general. Since this doesn't apply just to GDM but ideally to > screenlock and fast-user switching applets. For its warts, the Face Browser seems to work fairly reasonably on OpenSolaris today with the caveat that you need to make sure that /etc/passwd has a defined shell for users you want to show up in it. If we can come up with more intelligent heuristics that could make GDM work better (e.g. so that users who are valid users but do not have a shell defined can show up, etc.) then it would not be too cumbersome to fix such issues before integration. However, defining freedesktop.org specifications and an optin/optout infrastructure that would be acceptable to the upstream GDM community is not something that can be addressed in the timeframe of this case. Note that the current GDM in OpenSolaris has a Face Browser that has much worse warts, but it is off by default. There have been several reasons provided why the Face Browser should not be turned on by default on Solaris: - Showing usernames before authentication is a security concern. - It accesses the face images from the user's $HOME directory before authentication. - It does not work in some environments (as described above) and would need to be turned off in those situations. Since the Face Browser is not a particularly necessary feature, I recommend that we either decide to do one of the following: Option #1: Accept it as-is (or with a few minor enhancements to make it work better) and make it the default. Option #2: Accept it as-is (or with a few minor enhancements to make it work better) and make it not the default (much like with the current GDM). Option #3: Completely disable the Face Browser so it cannot be used on OpenSolaris. If we go with Option #2 or #3 and want to discuss what work will be necessary to make it Option #1 in a future ARC case, that's not a problem. But first, I would like to decide what option we will take for this case. Brian From Brian.Cameron@sun.com Thu Aug 13 14:09:23 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DL9Mag013770 for ; Thu, 13 Aug 2009 14:09:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DL9Csj004991 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 22:09:21 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC008012RKO900@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 14:09:20 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC00HU42RKS4C0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 14:09:20 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DL9J6l027226 for ; Thu, 13 Aug 2009 21:09:19 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOC00J002CTYC00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 15:09:19 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOC005OA2RJ2960@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 15:09:19 -0600 (MDT) Date: Thu, 13 Aug 2009 16:09:41 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A847A20.5030705@sun.com> Sender: Brian.Cameron@sun.com To: Alan Coopersmith Cc: Darren J Moffat , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A848115.4030507@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <4A844576.7020906@sun.com> <4A847A20.5030705@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 427 Alan: >> This is probably a good topic for the inception review. > > Wait - is this a fasttrack or a full case? Since you sent out the spec > to LSARC looking like a fasttrack, I think we all assumed this was the > fasttrack review, but I've just realized you never actually said it was > a fasttrack or set a timer. This is a full case. The inception review is next Tuesday and a commitment review will follow. Brian From Brian.Cameron@sun.com Thu Aug 13 14:24:49 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DLOmtO013951 for ; Thu, 13 Aug 2009 14:24:49 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DLOfu1013044 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Thu, 13 Aug 2009 22:24:48 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC000033HAIO00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 14:24:46 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC00J5D3HAZDB0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 14:24:46 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DLOk81000609 for ; Thu, 13 Aug 2009 21:24:46 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOC00H002Y85600@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 15:24:46 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOC005BV3H529C0@mail-amer.sun.com>; Thu, 13 Aug 2009 15:24:42 -0600 (MDT) Date: Thu, 13 Aug 2009 16:25:04 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090813203004.GC10982@Sun.COM> Sender: Brian.Cameron@sun.com To: Nicolas Williams Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8484B0.7030409@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> <20090813203004.GC10982@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 5195 Nicolas: > On Thu, Aug 13, 2009 at 03:08:34PM -0500, Brian Cameron wrote: >> I am fairly confident that a change to hardcode the list to a > ^^^^^^^^ >> configuration key would not be accepted upstream. The upstream GDM >> community has worked hard to try and make the Face Browser more usable >> for the average user. In other words, people want GDM to "just work" >> out of the box, without needing to do special configuration to specify >> a list of users to include. > > I never said anything about "hardcoding" anything. Quite the contrary. I thought you were suggesting that the list of users to be shown in the face browser be specified by GDM configuration, rather than using heuristics to decide which users to show. The word "hardcoding" was a poor word choice on my part. What I meant was: - We want to avoid a sysadmin needing to configure GDM to specify what users to include in the face browser. - An opt-in mechanism has been suggested. Perhaps you mean that after authentication, the GDM GUI would ask the user if they want to show up in the face browser or not, and the configuration would be modified to only include users who opt-in. Something like this could work, though it would be a fair bit of work to get it right with upstream. For example, how do users change their mind if they picked "No", but then decide "Yes" later (or vice versa). Does GDM need new GUI elements to allow users to change their setting, and if so, how to properly integrate this into the overall desktop experience. Not impossible to implement, but time consuming. > Clearly GDM's face browser cannot ""just work" out of the box" if there > are no face pics, and when the user takes/installs the face pic the user > can then just be added (silently or otherwise) to the face browser list. If the user does not have a face picture, then GDM just shows the username in the Face Browser list without the image next to it. So, currently the logic probes the $HOME directory and puts the image next to the username if an image exists. So, it does "just work" out of the box even if the user has no image. > I see nothing controversial about that, and plenty controversial about > the heuristics you've described. I think the subject ought to at least > be broached with the upstream community, and if they'll take #ifdef > SOLARIS code from you anyways, then just do it. > > But, you've proffered a solution that gets close -- let's work with it: > >> After talking with the upstream GDM developers, the following change >> would be acceptable to go upstream: >> >> - The SUNWgnome-display-mgr-root package would install a directory >> /var/cache/gdm. > > Yes, let's cache dmrc and face pics. > >> - At run-time GDM would create a directory /var/cache/gdm/user-$uid >> when a user logs in, if the directory does not already exist. In >> this file will be placed two files: dmrc and face. > > Yup. > >> - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then >> GDM will log the user into the default session/language or whichever >> ones they selected in the GUI. Then it will save the dmrc file to >> the cache with the default settings. On next login, the defaults >> will be read from the cache and not the user's $HOME directory. > > The cache should also be updated at logout time, if at all possible. > (But the system component doing a logout-time update wouldn't > necessarily be part of GDM.) A logout update is not necessary for caching this file since the choices can only be selected in the login GUI before authenticating. If the values change, you know they have changed before authentication. >> - On first login the /var/cache/gdm/user-$uid/face file will not >> exist so the user will see a generic user icon for their face. >> After authentication, GDM will check if the user has a defined >> face and copy it to the cached file. Also, on logout, GDM will check >> again if the user has a defined face and copy it to the cached file. >> This way the face image will be available on next login if the user >> defined it during their session. Obviously the face image will only >> be copied to the cache if one is not already in the cache or if the >> cached file is older. Using this technique, GDM would only access >> the face images from the cache, and not the user's $HOME directory. > > IMO an option to not include users in the face browser who lack cached > face pics is necessary: Why? The Face Browser just shows the username with no picture in this case. > when that option is enabled then GDM would not > need any local user heuristics. I find such heuristics rather > objectionable. The heuristics have nothing to do with the image. The heuristics are used to determine which users show up in the Face Browser at all. Normally you only want the local users to show up in the Face Browser. >> If it is a TCR requirement for GDM to work this way before it >> integrates, then we can make it work this way. >> >> Is that reasonable? > > It is reasonable, except for that one minor issue mentioned above. Brian From Nicolas.Williams@sun.com Thu Aug 13 15:04:29 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DM4SWq014759 for ; Thu, 13 Aug 2009 15:04:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DM4Lkl020893; Fri, 14 Aug 2009 06:04:23 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00C055BAR900@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Aug 2009 15:04:22 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC00B6J5B9CX10@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Aug 2009 15:04:21 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7DLrfh3013757; Thu, 13 Aug 2009 16:53:41 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7DLrfqv013756; Thu, 13 Aug 2009 16:53:41 -0500 (CDT) Date: Thu, 13 Aug 2009 16:53:41 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8484B0.7030409@sun.com> To: Brian Cameron Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090813215341.GF10982@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> <20090813203004.GC10982@Sun.COM> <4A8484B0.7030409@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 4256 On Thu, Aug 13, 2009 at 04:25:04PM -0500, Brian Cameron wrote: > >On Thu, Aug 13, 2009 at 03:08:34PM -0500, Brian Cameron wrote: > >>I am fairly confident that a change to hardcode the list to a > > ^^^^^^^^ > >>configuration key would not be accepted upstream. The upstream GDM > >>community has worked hard to try and make the Face Browser more usable > >>for the average user. In other words, people want GDM to "just work" > >>out of the box, without needing to do special configuration to specify > >>a list of users to include. > > > >I never said anything about "hardcoding" anything. Quite the contrary. > > I thought you were suggesting that the list of users to be shown in the > face browser be specified by GDM configuration, rather than using > heuristics to decide which users to show. The word "hardcoding" was > a poor word choice on my part. What I meant was: Not configuration as such, but a local database or cache -- as simple as the dmrc/face cache directory that you proposed. The key is to not use heuristics. Not using heuristics does not imply configuration. > - We want to avoid a sysadmin needing to configure GDM to specify what > users to include in the face browser. Of course. That's NOT what I had in mind. What I had in mind was: - face browser on/off option - face browser list updated when face pics are found (which would be: at successful login time, and at logout time) Note the lack of reference to "local users". Simple, no config. > - An opt-in mechanism has been suggested. Perhaps you mean that after > authentication, the GDM GUI would ask the user if they want to show > up in the face browser or not, and the configuration would be modified > to only include users who opt-in. Something like this could work, > though it would be a fair bit of work to get it right with upstream. That would be fine, but it's more than the minimum that I'm asking for. To restate: a) GDM must not touch $HOME prior to credentials establishment, nor with euid != the user's UID, b) GDM must not use any /etc/passwd-based heuristics to determined what users are appropriate for placement on the face browser list. Within the above two constraints you can design an opt-in or opt-out system, with or without configuration. We don't need to discuss design on the ARC list, but the constraints given above are architecture. > >The cache should also be updated at logout time, if at all possible. > >(But the system component doing a logout-time update wouldn't > >necessarily be part of GDM.) > > A logout update is not necessary for caching this file since the choices > can only be selected in the login GUI before authenticating. If the > values change, you know they have changed before authentication. Consider a user with a shared home directory. That user may login to multiple hosts at different times. And the face pics can be updated at any time, not just at login time. All the more reason to update the cache at logout time. > >IMO an option to not include users in the face browser who lack cached > >face pics is necessary: > > Why? The Face Browser just shows the username with no picture in this > case. Because this is a simple opt-in mechanism: no face pic -> not listed in the face browser. But yes, the above opinion is really design, not architecture, therefore I withdraw it. > >when that option is enabled then GDM would not > >need any local user heuristics. I find such heuristics rather > >objectionable. > > The heuristics have nothing to do with the image. The heuristics are > used to determine which users show up in the Face Browser at all. And I strongly object to such heuristics. > Normally you only want the local users to show up in the Face Browser. Not so! I might want the last few users to login to appear in that browser, without regard to whether they are local. Take my desktop system on SWAN for example. My $HOME is remote, and my user account is defined in a non-files name service, but why on Earth should GDM not put my username and face pic in the face browser? The whole notion of that GDM needs to care about whether a user is local or not is broken. Please remove it. Nico -- From Mike.Oliver@sun.com Thu Aug 13 15:09:42 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DM9fqd014825 for ; Thu, 13 Aug 2009 15:09:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DM9a6M023432 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 06:09:40 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00D0D5K33U00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 15:09:39 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC00BR15K3CK10@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 15:09:39 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7DM9djq025695 for ; Thu, 13 Aug 2009 15:09:39 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOC00F0052QTN00@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 15:09:39 -0700 (PDT) Received: from sunray4.SFBay.Sun.COM ([unknown] [10.6.102.104]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOC0028G5JXI880@fe-sfbay-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 15:09:34 -0700 (PDT) Date: Thu, 13 Aug 2009 15:09:33 -0700 From: Mike Oliver Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8484B0.7030409@sun.com> Sender: Mike.Oliver@sun.com To: Brian Cameron Cc: lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A848F1D.7060100@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> <20090813203004.GC10982@Sun.COM> <4A8484B0.7030409@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080119) Status: RO Content-Length: 1536 Brian Cameron wrote: >>> - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then >>> GDM will log the user into the default session/language or whichever >>> ones they selected in the GUI. Then it will save the dmrc file to >>> the cache with the default settings. On next login, the defaults >>> will be read from the cache and not the user's $HOME directory. >> >> The cache should also be updated at logout time, if at all possible. >> (But the system component doing a logout-time update wouldn't >> necessarily be part of GDM.) > > A logout update is not necessary for caching this file since the choices > can only be selected in the login GUI before authenticating. If the > values change, you know they have changed before authentication. If $HOME is shared across systems then my ~/.dmrc can be changed by a login through a GDM running on some other machine. That would mean that the cache on *this* machine would become stale. That's not necessarily a bad thing but it could be confusing to users. What does GDM do if the session type specified in my ~/.dmrc is not available on this system? I hope it proceeds as though no session-type entry had been found. BTW, dtlogin avoids the pre-authentication $HOME access issue by not translating a "follow user's previous session selection" choice to a concrete session type until the desktop is actually being launched, long after authentication has succeeded and the user's session credentials have been established. Mike. -- mike.oliver@sun.com From Brian.Cameron@sun.com Thu Aug 13 15:36:49 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DManHG015541 for ; Thu, 13 Aug 2009 15:36:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7DMamNt005587 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 13 Aug 2009 16:36:49 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00F176TC3M00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 15:36:48 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC00BGN6TBCW30@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 15:36:48 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DMal2i025207 for ; Thu, 13 Aug 2009 22:36:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOC00F006C30F00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Thu, 13 Aug 2009 16:36:47 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOC00CGA6T62J40@mail-amer.sun.com>; Thu, 13 Aug 2009 16:36:43 -0600 (MDT) Date: Thu, 13 Aug 2009 17:37:04 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A83EEC9.5080800@sun.com> Sender: Brian.Cameron@sun.com To: Joerg Barfurth Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A849590.1090509@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_2pldx5Ph3+TBIT4kd12NMA)" X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A83EEC9.5080800@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 40774 This is a multi-part message in MIME format. --Boundary_(ID_2pldx5Ph3+TBIT4kd12NMA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT 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 --Boundary_(ID_2pldx5Ph3+TBIT4kd12NMA) Content-type: text/xml; name=%gconf-tree.xml Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=%gconf-tree.xml /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true /bin/true gdm-screenshot disabled disabled disabled disabled disabled disabled disabled Print disabled disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled Disabled gdm-screenshot
  • cube
  • decoration
  • gconf
  • glib
  • move
  • place
  • resize
  • screenshot
  • wobbly
    • --Boundary_(ID_2pldx5Ph3+TBIT4kd12NMA)-- From Brian.Cameron@sun.com Thu Aug 13 16:17:50 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DNHnWR020326 for ; Thu, 13 Aug 2009 16:17:50 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DNHk6l026150 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 07:17:49 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00C038POC900@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 17:17:48 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC006IX8PO5M20@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 17:17:48 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DNHli3007813 for ; Thu, 13 Aug 2009 23:17:48 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOC00J008NBBL00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 17:17:47 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOC00HVI8PNN900@mail-amer.sun.com>; Thu, 13 Aug 2009 17:17:47 -0600 (MDT) Date: Thu, 13 Aug 2009 18:18:09 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090813215341.GF10982@Sun.COM> Sender: Brian.Cameron@sun.com To: Nicolas Williams Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A849F31.4010606@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> <20090813203004.GC10982@Sun.COM> <4A8484B0.7030409@sun.com> <20090813215341.GF10982@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 7852 Nicolas: >> I thought you were suggesting that the list of users to be shown in the >> face browser be specified by GDM configuration, rather than using >> heuristics to decide which users to show. The word "hardcoding" was >> a poor word choice on my part. What I meant was: > > Not configuration as such, but a local database or cache -- as simple as > the dmrc/face cache directory that you proposed. > > The key is to not use heuristics. Not using heuristics does not imply > configuration. > >> - We want to avoid a sysadmin needing to configure GDM to specify what >> users to include in the face browser. > > Of course. That's NOT what I had in mind. What I had in mind was: > > - face browser on/off option > - face browser list updated when face pics are found (which would be: > at successful login time, and at logout time) > > Note the lack of reference to "local users". Simple, no config. That is an interesting idea. Thanks for suggesting it. However, it is not quite that simple since the Face Browser is designed to work even if the user does not have a defined face image. So, the existence of a face image is not an indication that the user should be in the Face Browser or not. I suppose we could make it work that way on Solaris and require users to create a face image for their user to show up. Or, perhaps, we could assume that any user who logs in wants to be in the Face Browser and add an empty face file for that user on logout to indicate they want to show up in the Face Browser with the default face image. This sort of design is contrary to the way people want GDM to work on other distros, so I am unsure if the changes needed to make it work this way would go upstream. Most other distros want it to work with all local userids out-of-the-box as it does in other popular operating systems. But, as you say, we could use #ifdef's or perhaps add a configuration option to make it work any way we like. >> - An opt-in mechanism has been suggested. Perhaps you mean that after >> authentication, the GDM GUI would ask the user if they want to show >> up in the face browser or not, and the configuration would be modified >> to only include users who opt-in. Something like this could work, >> though it would be a fair bit of work to get it right with upstream. > > That would be fine, but it's more than the minimum that I'm asking for. > > To restate: a) GDM must not touch $HOME prior to credentials > establishment, nor with euid != the user's UID, b) GDM must not use any > /etc/passwd-based heuristics to determined what users are appropriate > for placement on the face browser list. > > Within the above two constraints you can design an opt-in or opt-out > system, with or without configuration. We don't need to discuss design > on the ARC list, but the constraints given above are architecture. Fair enough. I think requirement (a) is probably a hard requirement and is likely going to be a TCR. Some questions, I think, remain: - Is requirement (b) a TCR or not? - If the new GDM does not meet requirement (b) then does this mean that we need to disable the Face Browser so it can't be used, or just be turned off by default? - Assuming we have time to meet both requirements, will the Face Browser be turned on or off by default? >>> The cache should also be updated at logout time, if at all possible. >>> (But the system component doing a logout-time update wouldn't >>> necessarily be part of GDM.) >> >> A logout update is not necessary for caching this file since the choices >> can only be selected in the login GUI before authenticating. If the >> values change, you know they have changed before authentication. > > Consider a user with a shared home directory. That user may login to > multiple hosts at different times. If the dmrc file is saved in /var/cache, then the defaults are machine specific. If we move the dmrc file to /var/cache, then there would be no $HOME configuration file to worry about. If you are suggesting that GDM try to sync the $HOME/.dmrc file with the one in /var/cache, then I don't think that is worth the bother. It seems more sensible to not assume that the user wants to use the same session type on every machine they log into. The same sessions and languages might not even be available on all the machines a person wants to use with a shared $HOME directory. Making it more machine specific seems to make more sense to me since sessions and languages are also machine specific. The only situation where a race condition would exist would be in the unlikely event if the user were to enter their username and password into two terminals connected to the same server and hit "Log In" at the same time on both. In that situation, I am not sure it would matter which settings got saved as the default if they happened to be different. > And the face pics can be updated at any time, not just at login time. > All the more reason to update the cache at logout time. Agreed for face images. >>> IMO an option to not include users in the face browser who lack cached >>> face pics is necessary: >> >> Why? The Face Browser just shows the username with no picture in this >> case. > > Because this is a simple opt-in mechanism: no face pic -> not listed in > the face browser. But yes, the above opinion is really design, not > architecture, therefore I withdraw it. As I say above, the Face Browser is designed to work even if the user doesn't have a face image. Unless we want to add that constraint. My suggestion that users who log in get an empty face image file that means the same as "use the default face image" could also work. The problem with making the user define a face image to show up in the Face Browser is that this makes the login user experience very different than the way it works on other popular operating systems. Though, we can be different if we think there is a lot of value in doing so. >>> when that option is enabled then GDM would not >>> need any local user heuristics. I find such heuristics rather >>> objectionable. >> >> The heuristics have nothing to do with the image. The heuristics are >> used to determine which users show up in the Face Browser at all. > > And I strongly object to such heuristics. > >> Normally you only want the local users to show up in the Face Browser. > > Not so! I might want the last few users to login to appear in that > browser, without regard to whether they are local. Take my desktop > system on SWAN for example. My $HOME is remote, and my user account is > defined in a non-files name service, but why on Earth should GDM not put > my username and face pic in the face browser? The way GDM currently works: - You would see your local UID in the Face Browser initially - After logging into your name service account, it shows up too. The way you suggest it should work: - Nobody shows up initially - You log in n-number of times, and after you define a face image in your two accounts, they show up. I also suggest it could work: - Nobody shows up initially - The users show up in the face browser after you log into them the first time. Personally I think the way GDM already works is nicer, though it does use heuristics that you strongly object to. If requiring users to opt-in then the second choice is reasonable by forcing users to create an image to opt-in. The third choice is also reasonable if requiring users to opt-in is not really a requirement. > The whole notion of that GDM needs to care about whether a user is local > or not is broken. Please remove it. I guess the question for now is whether this means we have time to fix the Face Browser as described for initial integration. If not, I am guessing that "removing it" means removing the entire Face Browser for now. Brian From Brian.Cameron@sun.com Thu Aug 13 16:19:14 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DNJDq7020387 for ; Thu, 13 Aug 2009 16:19:14 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DNIlMq026519 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 07:19:12 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00G058RX7000@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 16:19:09 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC006KJ8RXPI40@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 16:19:09 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DNJ97L008273 for ; Thu, 13 Aug 2009 23:19:09 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOC00J008NBBL00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 17:19:09 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOC00HAT8RWN910@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Thu, 13 Aug 2009 17:19:09 -0600 (MDT) Date: Thu, 13 Aug 2009 18:19:31 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A848F1D.7060100@sun.com> Sender: Brian.Cameron@sun.com To: Mike Oliver Cc: lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A849F83.7080109@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> <20090813203004.GC10982@Sun.COM> <4A8484B0.7030409@sun.com> <4A848F1D.7060100@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1391 Mike: >>>> - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then >>>> GDM will log the user into the default session/language or whichever >>>> ones they selected in the GUI. Then it will save the dmrc file to >>>> the cache with the default settings. On next login, the defaults >>>> will be read from the cache and not the user's $HOME directory. >>> >>> The cache should also be updated at logout time, if at all possible. >>> (But the system component doing a logout-time update wouldn't >>> necessarily be part of GDM.) >> >> A logout update is not necessary for caching this file since the choices >> can only be selected in the login GUI before authenticating. If the >> values change, you know they have changed before authentication. > > If $HOME is shared across systems then my ~/.dmrc can be changed by a > login through a GDM running on some other machine. That would mean > that the cache on *this* machine would become stale. That's not > necessarily a bad thing but it could be confusing to users. If we move the dmrc file to /var/cache, then this issue would go away. So I think that is a good idea. > What does GDM do if the session type specified in my ~/.dmrc is not > available on this system? I hope it proceeds as though no session-type > entry had been found. It uses the system default if the choice in your $HOME/.dmrc file is not available. Brian From Brian.Cameron@Sun.COM Thu Aug 13 16:57:46 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DNvj9t022467 for ; Thu, 13 Aug 2009 16:57:46 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7DNvXsN014424 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 14 Aug 2009 07:57:44 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00G03AK5S800@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Thu, 13 Aug 2009 17:57:41 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC006CRAK55K50@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Thu, 13 Aug 2009 17:57:41 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7DNvfIv007847 for ; Thu, 13 Aug 2009 23:57:41 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOC00L00AJC7700@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Thu, 13 Aug 2009 17:57:40 -0600 (MDT) Received: from [129.153.250.184] ([unknown] [129.153.250.184]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOC00HJXAK4N9D0@mail-amer.sun.com>; Thu, 13 Aug 2009 17:57:40 -0600 (MDT) Date: Thu, 13 Aug 2009 18:58:03 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> Sender: Brian.Cameron@Sun.COM To: Brian Cameron Cc: lsarc-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A84A88B.9040407@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_pgkNZLkbDZn28vCBU0R6Nw)" X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 14050 This is a multi-part message in MIME format. --Boundary_(ID_pgkNZLkbDZn28vCBU0R6Nw) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT I have updated the GDM one-pager with some better examples and some corrections based on the discussion so far. The diff file showing these changes, compared to the original materials submitted with the case, is attached. Brian --Boundary_(ID_pgkNZLkbDZn28vCBU0R6Nw) Content-type: text/plain; name=GDM.diff Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=GDM.diff --- onepager-gdm-rewrite.txt-orig Wed Aug 12 15:57:01 2009 +++ onepager-gdm-rewrite.txt Thu Aug 13 16:26:43 2009 @@ -59,7 +59,7 @@ The GDM rewrite provides a login experience that is similar to the gdmlogin GUI provided by the older GDM. The usability has been much - improved with a more usable face browser and a panel which displays a + improved with a more usable Face Browser and a panel which displays a number of new options. GDM uses the GTK+ widget set and supports accessibility. @@ -84,21 +84,42 @@ for shutting down and restarting the machine. Refer to section 4.1.9 for more information. - 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 + By default GDM now displays all users on the local system in a Face + Browser (it uses fgetpwent(3C) to get the list of local users and to + avoid accessing users via nsswitch.conf). It also displays any + non-system users that have previously logged in on the system (for + example NIS/LDAP users). It gets this list via calling the ck-history + ConsoleKit interface. + + The user can select the username from the Face Browser list and 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. 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. + interface. If the user starts typing, it will automatically scroll down + to the users that match that search prefix. The Face Browser also + 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), or to login as a NIS/LDAP user. 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. + To be more clear what is meant by "system user", the GDM Face Browser + filters out all users which have a UID less than 100, users which do + not have a valid shell (valid shells are any shell that getusershell() + returns. /sbin/nologin or /bin/false are considered invalid shells + even if getusershell() returns them), and users which are in the + following list: bin, root, daemon, adm, lp, sync, shutdown, halt, mail, + news, uucp, operator, nobody, GDM_USERNAME (normally the "gdm" user), + postgres, pvm, rpm, nfsnobody, and pcap. + + If GDM is configured to not display the Face Browser, then the user + must click a "Log In" button on the GUI to start the PAM conversation + and enter the username and password. + Once the user has entered their username, or selected it via the - face browser, the panel shows interfaces for selecting the session to + Face Browser, the panel shows interfaces for selecting the session to log into and 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 @@ -156,7 +177,8 @@ 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. + with ConsoleKit, this will be removed. New users should use the + new ck-seat-tool program. - /usr/bin/gdmflexiserver [--version] [--debug] @@ -207,6 +229,9 @@ 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. + The gdm-session-worker process also launches the /etc/gdm/Xsession + script after successful login, which starts the user session (e.g. + gnome-session for a GNOME user session). - /usr/lib/gdm-simple-greeter @@ -287,17 +312,22 @@ - 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. + key is set for the "gdm" user, then GOK will be autolaunched. - 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. + is set for the "gdm" user, then orca will be autolaunched. 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. + Also note that GDM has a bug that all GDM login GUI's share the same + GConf settings, so that changing a setting (such as enabling an a11y + feature) will affect logins on all systems. Until this bug is fixed, + it is best to disable GDM a11y in multi-user environments. + 4.1.3 Detail About GDM Server Configuration The GDM rewrite uses different configuration mechanisms than the old @@ -425,13 +455,15 @@ Boolean value. Controls whether to show the restart and shutdown buttons in the login window. Even if true, GDM checks to see if the "gdm" user (or the user specified in the daemon/User - configuration option) has RBAC privileges for - solaris.system.shutdown. If not, the buttons are not displayed - regardless of this configuration setting. Default value is false. + configuration option) has authorization for the + solaris.system.shutdown key (the system default is that the "gdm" + user does not have such authorization). If not, the buttons are not + displayed regardless of this configuration setting. Default value is + false. - /apps/gdm/simple-greeter/disable_user_list - Boolean value. If true, then the face browser with known users is + Boolean value. If true, then the Face Browser with known users is not shown. In this case, normal PAM prompting is used. - /apps/gdm/simple-greeter/logo_icon_name @@ -530,6 +562,10 @@ does not bother to show the user a dialog to select the session and assumes to start the only available session. + GDM delivers a /usr/share/xsessions/xterm.desktop to allow users + to log into an xterm window, much like the Failsafe option in the + older GDM. + - $HOME/.dmrc This file contains the user's default language and session choices. @@ -678,10 +714,11 @@ GDM provides Shutdown and Reboot buttons for shutting down and restarting the system. These buttons are only available if enabled - in the configuration, and if the "gdm" user has permissions for - the solaris.system.shutdown RBAC key. GDM does not do the actual - shutdown/restart operation, but sends a message to ConsoleKit which - does the work. Note that ConsoleKit also will only allow these + in the configuration, and if the "gdm" user has authorization for + the solaris.system.shutdown RBAC key (the system default is that the + "gdm" user does not have such authorization). GDM does not do the + actual shutdown/restart operation, but sends a message to ConsoleKit + which does the work. Note that ConsoleKit also will only allow these operations if the requesting user (the "gdm" user in the situation where the user presses the button on the GDM login GUI) has RBAC permissions for the solaris.system.shutdown RBAC key. @@ -690,7 +727,7 @@ associated TTY value of the Xserver on a given display after starting the Xserver. - GDM calls /usr/bin/ck-history when using the face browser to show + GDM calls /usr/bin/ck-history when using the Face Browser to show the most frequently logged in users first, making it easier for such users to log in quickly. @@ -778,10 +815,6 @@ - GDM no longer provides the ability to start the chooser program from the login greeter GUI program. - - GDM no longer provides a "Failsafe Session". Since the new GDM - assumes that console users have access to VT, the VT mechanism - should be used for failsafe purposes. - - GDM no longer provides the "gdmsetup" program, so there is no longer a GUI interface for configuring GDM. In some ways this is a good thing since the old gdmsetup could only be run with root privileges. @@ -810,10 +843,10 @@ --------------------------------------- ----------- ------------- SUNWgnome-display-mgr Uncommitted Package name. SUNWgnome-display-mgr-root Uncommitted Package name. + svc:/application/graphical-login/gdm:default Uncommitted GDM FMRI /var/svc/manifest/application/graphical-login/gdm.xml - Uncommitted SMF - integration - file. + Project SMF manifest + Private integration /lib/svc/method/svc-gdm Volatile SMF integration startup, @@ -822,7 +855,8 @@ script. /usr/bin/gdm-screenshot Volatile See 4.1.1. - /usr/bin/gdmdynamic Volatile See 4.1.1. + /usr/bin/gdmdynamic Obsolete See 4.1.1. + Volatile /usr/bin/gdmflexiserver Volatile See 4.1.1. /usr/sbin/gdm-binary Volatile See 4.1.1. /usr/sbin/gdm-stop Volatile See 4.1.1. @@ -865,6 +899,7 @@ /etc/X11/xinit/xinitrc.d Uncommitted See 4.1.13. /usr/share/xsessions Uncommitted See 4.1.6 + /usr/share/xsessions/xterm.desktop Uncommitted See 4.1.6 /var/lib/gdm Uncommitted $HOME directory for "gdm" @@ -912,7 +947,7 @@ GDM_KEYBOARD_LAYOUT Uncommitted See 4.1.7. - Obsolete Interfaces Stability Comments + Removed Interfaces Stability Comments ---------------------------- ----------------- ----------------------- Note section 4.1.15 which discusses regressions associated with these @@ -1043,6 +1078,10 @@ Since VT support requires driver support, user switching features will not work on systems where the graphics driver does not support VT. + Note that the GDM themes previously delivered to /usr/share/gdm/themes + by the SUNWgnome-themes package will no longer be delivered once the + new GDM is integrated, since they will no longer be used. + 4.6. L10N Impact: The Desktop team and the G11N team are working together to evaluate and @@ -1093,7 +1132,9 @@ are managed in the desktop. GDM makes use of RBAC so that the Shut Down and Reboot options are only - available if the "gdm" user has solaris.system.shutdown authority. + available if the "gdm" user has authorization for the + solaris.system.shutdown RBAC key. The system default is that the "gdm" + user does not have such authorization. The following cases relate to how Shut Down and Reboot functions work with the Desktop stack. --Boundary_(ID_pgkNZLkbDZn28vCBU0R6Nw)-- From Nicolas.Williams@sun.com Thu Aug 13 16:58:11 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7DNwAE1022485 for ; Thu, 13 Aug 2009 16:58:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7DNw663004198; Fri, 14 Aug 2009 00:58:08 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00L03AKWQ500@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Aug 2009 16:58:08 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC006P5AKVPF40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 13 Aug 2009 16:58:08 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7DNlSaT001289; Thu, 13 Aug 2009 18:47:28 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7DNlSJd001288; Thu, 13 Aug 2009 18:47:28 -0500 (CDT) Date: Thu, 13 Aug 2009 18:47:28 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A849F31.4010606@sun.com> To: Brian Cameron Cc: Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090813234728.GB1043@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> <20090813203004.GC10982@Sun.COM> <4A8484B0.7030409@sun.com> <20090813215341.GF10982@Sun.COM> <4A849F31.4010606@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 4491 On Thu, Aug 13, 2009 at 06:18:09PM -0500, Brian Cameron wrote: > This sort of design is contrary to the way people want GDM to work > on other distros, so I am unsure if the changes needed to make it work > this way would go upstream. Most other distros want it to work with > all local userids out-of-the-box as it does in other popular operating > systems. I don't think the local user heuristics are a good idea on any Unix or Unix-like OS. I don't mind if the upstream community prefers to have those heuristics on Linux or *BSD, but I don't think those heuristics are at all appropriate, so let's not have those on Solaris. > But, as you say, we could use #ifdef's or perhaps add a configuration > option to make it work any way we like. Yes. I'd prefer #ifdef, because if someone enables those heuristics then we can have surprises later on when some other change breaks those heuristics. > Fair enough. I think requirement (a) is probably a hard requirement > and is likely going to be a TCR. Some questions, I think, remain: > > - Is requirement (b) a TCR or not? IMO: yes, but I'm not an ARC member. Moreover, I think solving (a) makes it trivial to solve (b) -- we've discussed a variety of schemes that solve (b) already. > - If the new GDM does not meet requirement (b) then does this mean that > we need to disable the Face Browser so it can't be used, or just be > turned off by default? I'd say "disable the Face Browser so it can't be used". > - Assuming we have time to meet both requirements, will the Face Browser > be turned on or off by default? IMO: on by default. Whether AI disables it by default is another matter (and, IMO, AI should disable it by default). > >And the face pics can be updated at any time, not just at login time. > >All the more reason to update the cache at logout time. > > Agreed for face images. OK. > >>Normally you only want the local users to show up in the Face Browser. > > > >Not so! I might want the last few users to login to appear in that > >browser, without regard to whether they are local. Take my desktop > >system on SWAN for example. My $HOME is remote, and my user account is > >defined in a non-files name service, but why on Earth should GDM not put > >my username and face pic in the face browser? > > The way GDM currently works: > ... > The way you suggest it should work: > ... > I also suggest it could work: > > - Nobody shows up initially > - The users show up in the face browser after you log into them the > first time. Yes that's fine. > >The whole notion of that GDM needs to care about whether a user is local > >or not is broken. Please remove it. > > I guess the question for now is whether this means we have time to > fix the Face Browser as described for initial integration. If not, I > am guessing that "removing it" means removing the entire Face Browser > for now. I think so, yes. > >>A logout update is not necessary for caching this file since the choices > >>can only be selected in the login GUI before authenticating. If the > >>values change, you know they have changed before authentication. > > > >Consider a user with a shared home directory. That user may login to > >multiple hosts at different times. > > If the dmrc file is saved in /var/cache, then the defaults are machine > specific. If we move the dmrc file to /var/cache, then there would be > no $HOME configuration file to worry about. If you are suggesting > that GDM try to sync the $HOME/.dmrc file with the one in /var/cache, > then I don't think that is worth the bother. It seems more sensible to > not assume that the user wants to use the same session type on every > machine they log into. The same sessions and languages might not even > be available on all the machines a person wants to use with a shared > $HOME directory. Making it more machine specific seems to make more > sense to me since sessions and languages are also machine specific. That's fair for dmrc, but not for face. Since both files could have the same cache semantics you don't necessarily save code by not bothering with caching/syncing dmrc. But I don't mind if dmrc becomes a purely local matter. In fact, I would even prefer that. Consider a multi-lingual user with multiple systems/zones/VMs but with one home directory, and who wishes to login with different locales on different systems. For such a user a purely local dmrc would be much better than storing the dmrc in $HOME! Nico -- From wyang@tjhsst.edu Thu Aug 13 17:28:54 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7E0SrF9022724 for ; Thu, 13 Aug 2009 17:28:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7E0Sljt029972; Fri, 14 Aug 2009 08:28:49 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00001C00EE00@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Aug 2009 17:28:48 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC00B4SBZZCR90@nwk-avmta-2.sfbay.sun.com>; Thu, 13 Aug 2009 17:28:47 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7E0DKEG007776; Fri, 14 Aug 2009 00:28:47 +0000 (GMT) Received: from mmp42es.mmp.us.syntegra.com ([160.41.221.11] [160.41.221.11]) by relay41i.sun.com with ESMTP id BT-MMP-2569876; Fri, 14 Aug 2009 00:28:47 +0000 (Z) Received: from relay41i.sun.com (relay41i.sun.com [192.5.209.70]) by mmp42es.mmp.us.syntegra.com with ESMTP id BT-MMP-56659853; Fri, 14 Aug 2009 00:28:46 +0000 (Z) Received: from ipex3.johnshopkins.edu ([128.220.161.140] [128.220.161.140]) by relay4i.sun.com with ESMTP id BT-MMP-19797227; Fri, 14 Aug 2009 00:28:46 +0000 (Z) Received: from pool-72-66-41-253.washdc.east.verizon.net (HELO WEYangTPT61) ([72.66.41.253]) by ipex3.johnshopkins.edu with ESMTP/TLS/RC4-MD5; Thu, 13 Aug 2009 20:28:45 -0400 Date: Thu, 13 Aug 2009 20:28:37 -0400 From: William Yang Subject: RE: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8472C2.9030900@sun.com> To: "'Brian Cameron'" , "'Nicolas Williams'" Cc: "'Brian Cameron'" , desktop-discuss@opensolaris.org, lsarc-ext@sun.com, "'Darren J Moffat'" Message-id: <003301ca1c76$2aaba0d0$8002e270$@edu> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcocUe7u4UMR4bAKS5qtGWeTLC1hZgAI3zLw X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: E=Sophos;i="4.43,377,1246852800"; d="scan'208";a="287703785" X-Antispam: No, score=0.0/5.0, scanned in 0.100sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> Status: RO Content-Length: 1604 > - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then > GDM will log the user into the default session/language or whichever > ones they selected in the GUI. Then it will save the dmrc file to > the cache with the default settings. On next login, the defaults > will be read from the cache and not the user's $HOME directory. I've read the subsequent comments on this, but I'll reply here since this was the original point of suggestion. While I acknowledge the merits of storing the dmrc locally in /var/cache, this could cause much trouble for Sun Ray failover groups. Sun Rays can connect to any one of a number of servers in the failover group. Using a local dmrc would mean that logging in after logging out, even on the same Sun Ray DTU, could result in a different session. A workaround could be to NFS mount /var/cache/gdm across all these systems, but that seems to be a poor way to do things. Kerberos-secured and even AFS homedirs work fine with the current dtlogin and gdm behavior for using the last session, which is that there is literally an option for "use last session" in the sessions list and the dmrc is read after successful pam_setcred. While that means the user isn't told ahead of time what exactly that last session is, I have never heard a complaint about that particular missing feature. The right solution here might be to make it a GDM configurable, perhaps with the default to store in /var/cache, but then have a Sun Ray install script either prompt the sysadmin to choose or just change the default to using $HOME/.dmrc. William Yang From Joerg.Barfurth@sun.com Fri Aug 14 00:32:06 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7E7W6Bt008118 for ; Fri, 14 Aug 2009 00:32:06 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7E7W3oh005921 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 14 Aug 2009 01:32:06 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC00G09VLHG400@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Fri, 14 Aug 2009 00:32:05 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC00661VLF5M70@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Fri, 14 Aug 2009 00:32:04 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7E7W3xq020845 for ; Fri, 14 Aug 2009 07:32:03 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOC00N00VJ03G00@fe-emea-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Fri, 14 Aug 2009 08:31:44 +0100 (BST) Received: from [10.16.66.63] ([unknown] [10.16.66.63]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOC002QDVKWD1C0@fe-emea-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Fri, 14 Aug 2009 08:31:44 +0100 (BST) Date: Fri, 14 Aug 2009 09:31:44 +0200 From: Joerg Barfurth Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A849590.1090509@sun.com> Sender: Joerg.Barfurth@sun.com To: Brian Cameron Cc: LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8512E0.7030807@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A83EEC9.5080800@sun.com> <4A849590.1090509@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 5324 Brian Cameron schrieb: > 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. > Yes, I know and agree. I justed wanted to know (and have recorded in this case) some of the architectural gotchas we have to deal with, at least for the transition. >>> 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. > Ah yes. I recall Jon describing this. It just wasn't clear from your description. Not listing non-local users unless they are in ck-history is a good compromise between the needs of the standalone PC/laptop case and those of a server. >> 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. > [...] > 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. > We'll need to do extra work to make Kiosk Mode work under new GDM anyway. From what I know now, it certainly seems that AutomaticLogin with the "!scriptname" feature would be the best approach here. > That said, I think getting this to work with AutomaticLogin, if > possible, would be the better approach. > Yes. I'll try to work with you on 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 you plan to change it, is "Uncommitted" the right stability for the $HOME/.dmrc path? OTOH that is a pre-existing gdm interface (and for example Kiosk Mode is currently using it ...), so switching that will not be that easy. > 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. > On Sun Ray systems you often have large number of sessions sitting at the greeter (on unused clients). But if use of AutomaticLogin avoids this in cases that don't need it at all, that addresses an important part of my concerns. Thanks for responding. - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From casper@holland.sun.com Fri Aug 14 01:01:00 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7E810si008718 for ; Fri, 14 Aug 2009 01:01:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7E80xMt008245 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@Sun.COM>; Fri, 14 Aug 2009 01:01:00 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOC0010HWXN9G00@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri, 14 Aug 2009 02:01:00 -0600 (MDT) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOC009SHWXMD360@brm-avmta-1.central.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri, 14 Aug 2009 02:00:58 -0600 (MDT) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7E80qo1042746; Fri, 14 Aug 2009 09:00:53 +0100 (BST) Date: Fri, 14 Aug 2009 10:00:52 +0200 From: Casper.Dik@sun.com Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A845A75.9010907@sun.com> Sender: casper@holland.sun.com To: Brian Cameron Cc: Alan Coopersmith , Darren J Moffat , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <200908140800.n7E80qo1042746@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843B24.3010804@sun.com> <4A845A75.9010907@sun.com> Status: RO Content-Length: 404 >Correct. The way the code works is that it calls fgetpwent() and if >/etc/passwd contains no value, then that account does not show up in the >Face Browser. So, users would need to avoid using the shorthand if they >want the user to show up in the GDM Face Browser. > >If that is inappropriate, then we could change the logic to work a >different way. I would suggest that that is a bug. Casper From Joerg.Barfurth@Sun.COM Fri Aug 14 02:14:21 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7E9EL6p009572 for ; Fri, 14 Aug 2009 02:14:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7E9EKFo026092 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 02:14:20 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD007030BU4M00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 02:14:18 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD003H50BQ5XD0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 02:14:15 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7E9EEgS006496 for ; Fri, 14 Aug 2009 09:14:14 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOD00B0006C7200@fe-emea-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 10:13:57 +0100 (BST) Received: from [10.16.66.63] ([unknown] [10.16.66.63]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOD001U00B7JH30@fe-emea-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 10:13:55 +0100 (BST) Date: Fri, 14 Aug 2009 11:13:55 +0200 From: Joerg Barfurth Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A844165.70306@Sun.COM> Sender: Joerg.Barfurth@Sun.COM To: Bob Doolittle Cc: Brian Cameron , desktop-discuss@opensolaris.org, lsarc-ext@Sun.COM Message-id: <4A852AD3.4050002@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A844165.70306@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 1743 Bob Doolittle schrieb: > Brian Cameron wrote: >>> What about when NIS or LDAP is in use ? Do we really want GDM attempting >>> to display 38,000+ accounts ? >> As I explain above, this should not be an issue. > > In a server-based (e.g. thin client) desktop environment, the number of > users who have ever utilized a server could still wind up in the > hundreds or thousands. I don't know if GDM does that now, but with ck-history, the selection could be only users that have logged in to the current 'seat'. In a Sun Ray environment it would require proper integration (so that Sun Ray client ids are mapped to unique ConsoleKit seat ids) to make that useful. But an RFE to allow configuring a limit for how many users to take from the history or a console-kit feature to expire the history database so it doesn't grow boundlessly may also be ways to limit this. > That's a lot of faces. There should be some upper > limit, beyond which the face browser isn't utilized since it becomes > impractical. There's also a $HOME access delay per user, if pictures are > stored in $HOME. That could become substantial at some point > particularly in an NFS-mounted $HOME environment. > Fortunately the $HOME issue appears to be on its way of being addressed. > It's always possible for sites to turn off the face browser, but of > course better if it were more intelligent and adaptive as above. > - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From Joerg.Barfurth@sun.com Fri Aug 14 02:18:35 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7E9IY5K009628 for ; Fri, 14 Aug 2009 02:18:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7E9ISeU008869 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 10:18:33 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00H0H0IX1800@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 02:18:33 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00AHQ0IWJGE0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 02:18:32 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7E9IVja027230 for ; Fri, 14 Aug 2009 09:18:31 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOD00B0006C7200@fe-emea-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 10:18:13 +0100 (BST) Received: from [10.16.66.63] ([unknown] [10.16.66.63]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOD001T80I9JH50@fe-emea-10.sun.com>; Fri, 14 Aug 2009 10:18:10 +0100 (BST) Date: Fri, 14 Aug 2009 11:18:09 +0200 From: Joerg Barfurth Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A84A88B.9040407@sun.com> Sender: Joerg.Barfurth@sun.com To: Brian Cameron Cc: Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A852BD1.8010200@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A84A88B.9040407@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 1127 Brian Cameron schrieb: > > I have updated the GDM one-pager with some better examples and some > corrections based on the discussion so far. The diff file showing > these changes, compared to the original materials submitted with the > case, is attached. > > + Also note that GDM has a bug that all GDM login GUI's share the same > + GConf settings, so that changing a setting (such as enabling an a11y > + feature) will affect logins on all systems. Until this bug is fixed, > + it is best to disable GDM a11y in multi-user environments. > + This probably should be worded to be more about multi-*seat* environments. On a single seat it isn't really surprising that login settings are sticky. (And I don't know what "all systems" should mean in this context.) - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Fri Aug 14 02:51:23 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7E9pNF6009710 for ; Fri, 14 Aug 2009 02:51:23 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7E9pMqZ018630 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 02:51:22 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00C0P21MZH00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 03:51:22 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD0094M21KD1F0@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 03:51:20 -0600 (MDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7E9n7Im026555 for ; Fri, 14 Aug 2009 09:51:20 +0000 (GMT) Received: from mmp11es.mmp.us.syntegra.com ([160.41.208.11] [160.41.208.11]) by relay14i.sun.com with ESMTP id BT-MMP-65502 for lsarc-ext@sun.com; Fri, 14 Aug 2009 09:50:05 +0000 (Z) Received: from relay11i.sun.com (relay11i.sun.com [129.179.4.121]) by mmp11es.mmp.us.syntegra.com with ESMTP id BT-MMP-52149042 for lsarc-ext@sun.com; Fri, 14 Aug 2009 09:49:53 +0000 (Z) Received: from relay04-haj2.antispameurope.com ([83.246.65.54] [83.246.65.54]) by relay1i.sun.com with ESMTP id BT-MMP-7598484 for lsarc-ext@sun.com; Fri, 14 Aug 2009 09:48:39 +0000 (Z) Received: by relay04-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id 07EE55EC1FE; Fri, 14 Aug 2009 11:48:31 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay04-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 1AA795EC13F; Fri, 14 Aug 2009 11:48:31 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n7E9mURo017313; Fri, 14 Aug 2009 11:48:30 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Aug 2009 11:48:30 +0200 Date: Fri, 14 Aug 2009 11:47:55 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A845A75.9010907@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Brian.Cameron@sun.com, Alan.Coopersmith@sun.com Cc: lsarc-ext@sun.com, desktop-discuss@opensolaris.org, bc99092@sac.sfbay.sun.com Message-id: <4a8532cb.d6v4eMlEPZaAflWP%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 10.514sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843B24.3010804@sun.com> <4A845A75.9010907@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 14 Aug 2009 09:48:30.0447 (UTC) FILETIME=[61439FF0:01CA1CC4] Status: RO Content-Length: 1356 Brian Cameron wrote: > >>> nobody:x:60001:60001:NFS Anonymous Access User:/: > >>> noaccess:x:60002:60002:No Access User:/: > >>> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: > >> > >> Since these users do not have valid shells specified, these would not > >> be shown. > > > > A blank entry in the shell field indicates the system default shell should > > be used - on Solaris& OpenSolaris, that's "/bin/sh", which is a valid > > shell. If you're skipping those because they're blank do you also skip > > non-system accounts using that shorthand? > > Correct. The way the code works is that it calls fgetpwent() and if > /etc/passwd contains no value, then that account does not show up in the > Face Browser. So, users would need to avoid using the shorthand if they > want the user to show up in the GDM Face Browser. Giving any kind of information about known user names is considered a security risk since aprox. 35 years on UNIX. Is this "show ID featur" an optional feature, or is it enabled by default? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Joerg.Barfurth@Sun.COM Fri Aug 14 03:05:12 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EA5CJK010174 for ; Fri, 14 Aug 2009 03:05:12 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7EA59Ar016783 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 04:05:12 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00E1T2OOEV00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 04:05:12 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00E9O2ON3O00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 04:05:11 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7EA5Arj004536 for ; Fri, 14 Aug 2009 10:05:11 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOD00D0026ZA300@fe-emea-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 11:04:54 +0100 (BST) Received: from [10.16.46.61] ([unknown] [10.16.46.61]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOD00LC52O5UK80@fe-emea-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 11:04:54 +0100 (BST) Date: Fri, 14 Aug 2009 12:04:53 +0200 From: Joerg Barfurth Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090813234728.GB1043@Sun.COM> Sender: Joerg.Barfurth@Sun.COM To: Nicolas Williams Cc: Brian Cameron , desktop-discuss@opensolaris.org, lsarc-ext@Sun.COM Message-id: <4A8536C5.5060200@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> <20090813203004.GC10982@Sun.COM> <4A8484B0.7030409@sun.com> <20090813215341.GF10982@Sun.COM> <4A849F31.4010606@sun.com> <20090813234728.GB1043@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 5373 Nicolas Williams schrieb: > On Thu, Aug 13, 2009 at 06:18:09PM -0500, Brian Cameron wrote: >> This sort of design is contrary to the way people want GDM to work >> on other distros, so I am unsure if the changes needed to make it work >> this way would go upstream. Most other distros want it to work with >> all local userids out-of-the-box as it does in other popular operating >> systems. > > I don't think the local user heuristics are a good idea on any Unix or > Unix-like OS. I don't mind if the upstream community prefers to have > those heuristics on Linux or *BSD, but I don't think those heuristics > are at all appropriate, so let's not have those on Solaris. > Browsable user lists [*] are a standard feature of the login experience on most systems. They should be usable out of the box on a newly installed system. Local users added during installation or using local management tool should usually be part of the browseable list. Obviously these user browsers have a problem when used with a usually large user list from a central name service. Another reason not to show all users from a network name service is that the computer may still be a personal one that is (almost) never used by anyone but the owner. The local/non-local distinction seems to be an obvious one to reconcile these requirements. But with local accounts a set of rules is needed to eliminate the system accounts. [*] The term 'Face Browser' is misleading here. There is absolutely no need to use photos of the users as the login picture. > IMO: yes, but I'm not an ARC member. Moreover, I think solving (a) > makes it trivial to solve (b) -- we've discussed a variety of schemes > that solve (b) already. > I don't see that. This is about a browsable user list, not about having anyone's actual face in that list. >> - If the new GDM does not meet requirement (b) then does this mean that >> we need to disable the Face Browser so it can't be used, or just be >> turned off by default? > > I'd say "disable the Face Browser so it can't be used". > I'd say that is too hard. I may want to use the face browser, even if some stray accounts that aren't meant for actual login show up at the end of the list over time. It would be useful to have an admin-accessible exclusion list so I can at least fix that locally, like old gdm had. I believe a design goal of new gdm was to avoid requiring admins to have to configure this kind of things over and over. But not having such a list means that third-party developers that need to add special user accounts for their layered products have no way to hide their accounts from the list. The alternative design is see is to have a positive list of accounts to always include and to make interactive install and local GUI tools for user administration add new users to that list (by default). Accounts for which this had been missed could still become browseable through the history. We'd still need a way to filter accounts like root from the history, but here the uid<100 rule might be sufficient (vs. more extensive heuristics. Such a positive list should become a freedektop.org standard, in order to get it supported accross display managers and user management tools. That makes this a longer-term effort. >> - Assuming we have time to meet both requirements, will the Face Browser >> be turned on or off by default? > > IMO: on by default. Whether AI disables it by default is another matter > (and, IMO, AI should disable it by default). > Why? >> I also suggest it could work: >> >> - Nobody shows up initially >> - The users show up in the face browser after you log into them the >> first time. > > Yes that's fine. > The part where nobody shows up initially and newly added local users also don't show up is what I don't agree to: - Mummy, you said you'd make me an account on the computer - But Nick, I did - But it doesn't know me! I am not in the list! (And that can happen not only with children. Why should people have to remember and type correctly a strange shorthand user 'name', when the can find and select their real name in almost on almost all systems.) >>> The whole notion of that GDM needs to care about whether a user is local >>> or not is broken. Please remove it. On a personal computer with a few accounts which I - the owner - have added myself, I want all of them to show up in the list by default. Without me having to remember obscure user names or having to copy files into strange locations assigning equally obscure file names. If I am on a network that provides a long list of centrally configured accounts, I don't really want all of those to show up on my login screen. Here the history-only mechanism is a reasonable choice. And I definitely don't want accounts (local or not) which aren't for real people but internal mechanisms of some piece of software in my list. If there aren't reliable interfaces for all these distinctions, it may require heuristics to satisfy those requirements. - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From Darren.Moffat@sun.com Fri Aug 14 03:33:53 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EAXrOr010283 for ; Fri, 14 Aug 2009 03:33:53 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7EAXjPb021562 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 03:33:53 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00H0J40GGQ00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 04:33:52 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00EL540F3S10@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 04:33:51 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7EAXoM3020284 for ; Fri, 14 Aug 2009 10:33:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOD00G003RJX600@fe-emea-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 11:33:48 +0100 (BST) Received: from [129.156.173.215] ([unknown] [129.156.173.215]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOD00IYK4058A70@fe-emea-09.sun.com>; Fri, 14 Aug 2009 11:33:41 +0100 (BST) Date: Fri, 14 Aug 2009 11:34:10 +0100 From: Darren J Moffat Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8484B0.7030409@sun.com> Sender: Darren.Moffat@sun.com To: Brian Cameron Cc: Nicolas Williams , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A853DA2.6000408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> <20090813203004.GC10982@Sun.COM> <4A8484B0.7030409@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 3995 Brian Cameron wrote: > > Nicolas: > >> On Thu, Aug 13, 2009 at 03:08:34PM -0500, Brian Cameron wrote: >>> I am fairly confident that a change to hardcode the list to a >> ^^^^^^^^ >>> configuration key would not be accepted upstream. The upstream GDM >>> community has worked hard to try and make the Face Browser more usable >>> for the average user. In other words, people want GDM to "just work" >>> out of the box, without needing to do special configuration to specify >>> a list of users to include. >> >> I never said anything about "hardcoding" anything. Quite the contrary. > > I thought you were suggesting that the list of users to be shown in the > face browser be specified by GDM configuration, rather than using > heuristics to decide which users to show. The word "hardcoding" was > a poor word choice on my part. What I meant was: > > - We want to avoid a sysadmin needing to configure GDM to specify what > users to include in the face browser. > - An opt-in mechanism has been suggested. Perhaps you mean that after > authentication, the GDM GUI would ask the user if they want to show > up in the face browser or not, and the configuration would be modified > to only include users who opt-in. Something like this could work, > though it would be a fair bit of work to get it right with upstream. > For example, how do users change their mind if they picked "No", but > then decide "Yes" later (or vice versa). Does GDM need new GUI > elements to allow users to change their setting, and if so, how to > properly integrate this into the overall desktop experience. Not > impossible to implement, but time consuming. You need that optin/out and change of mind anyway. Not having it presents a privacy problem. Consider a multi national company that has facebrowsing on by default and users from all over the world (with different privacy jurisdictions and personal expectations). They all use a common set of Sun Ray or other multi seat systems. You need to have a per user method of optin and/or optout. This can not be done (and be safe legally) based on heuristics keyed off assumptions that local nameservice accounts are different. There maybe cases where it is acceptable for a user to be in the face-browser on some machines that share the same nameservice and home directory but not others. Though I'd regard that as a more advanced config. For example, wanting their face on their local workstation in their office but not if they use a Sun Ray server in a public area - same nameservice, same home dir (neither of which have a local account). >> when that option is enabled then GDM would not >> need any local user heuristics. I find such heuristics rather >> objectionable. > > The heuristics have nothing to do with the image. The heuristics are > used to determine which users show up in the Face Browser at all. > Normally you only want the local users to show up in the Face Browser. Local user is a bogus requirement. Am I a local user on my workstation in my office ? Yes, but I may not have an account in /etc/passwd or a local home dir. Am I a local user on the Sun Ray DTU in my office ? Yes ? and again no local account or home dir is likely. Am I a local user on my laptop ? Yes and in this case I likely do have a local password entry and local home dir. Am I a local user on my at home workstation ? Yes and like the laptop case I may have a local password entry and I may or may not have a local home dir. So what is "normal" here ? I think we are actually pretty close with the caching proposal to having this be able to work by default. The one change I believe is necessary is not making assumptions based on nameservice location of a user. Partly because it really isn't as simple as looking in /etc/passwd - what about when compat mode is on ? What about accounts with local passwd but remote home dir ? -- Darren J Moffat From Joerg.Barfurth@sun.com Fri Aug 14 03:54:47 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EAskkw010618 for ; Fri, 14 Aug 2009 03:54:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7EAsinm037391 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 04:54:46 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00K054Z9V900@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Fri, 14 Aug 2009 03:54:45 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00CIC4Z8PWE0@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@Sun.COM); Fri, 14 Aug 2009 03:54:45 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7EAshxZ013222 for ; Fri, 14 Aug 2009 10:54:43 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOD00I004NBZ000@fe-emea-10.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri, 14 Aug 2009 11:54:39 +0100 (BST) Received: from [10.16.66.63] ([unknown] [10.16.66.63]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOD00FST4YWOGA0@fe-emea-10.sun.com> for lsarc-ext@Sun.COM (ORCPT lsarc-ext@Sun.COM); Fri, 14 Aug 2009 11:54:33 +0100 (BST) Date: Fri, 14 Aug 2009 12:54:32 +0200 From: Joerg Barfurth Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4a8532cb.d6v4eMlEPZaAflWP%Joerg.Schilling@fokus.fraunhofer.de> Sender: Joerg.Barfurth@sun.com To: Joerg Schilling Cc: Brian.Cameron@sun.com, Alan.Coopersmith@sun.com, lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A854268.6020802@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843B24.3010804@sun.com> <4A845A75.9010907@sun.com> <4a8532cb.d6v4eMlEPZaAflWP%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 1941 Joerg Schilling schrieb: > Brian Cameron wrote: > >>>>> nobody:x:60001:60001:NFS Anonymous Access User:/: >>>>> noaccess:x:60002:60002:No Access User:/: >>>>> nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: >>>> Since these users do not have valid shells specified, these would not >>>> be shown. >>> A blank entry in the shell field indicates the system default shell should >>> be used - on Solaris& OpenSolaris, that's "/bin/sh", which is a valid >>> shell. If you're skipping those because they're blank do you also skip >>> non-system accounts using that shorthand? >> Correct. The way the code works is that it calls fgetpwent() and if >> /etc/passwd contains no value, then that account does not show up in the >> Face Browser. So, users would need to avoid using the shorthand if they >> want the user to show up in the GDM Face Browser. > > Giving any kind of information about known user names is considered a security > risk since aprox. 35 years on UNIX. > Hum. User names are not really secrets either. And other desktop OSs have had browsable user lists on their login screens by default and that isn't generally considered a breach of security. But in environments where knowledge of user names is a security issue, you either shouldn't offer a graphical login (remote graphical login is off by default) or make sure this feature is switched off. > Is this "show ID featur" an optional feature, or is it enabled by default? > BTW: Usually this doesn't show IDs (i.e user names in the UNIX sense), but human-readable names, probably taken from the 'gecos' fields, if available. It is optional. upstream has it enabled by default. - Jörg -- Joerg Barfurth Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From Joerg.Barfurth@sun.com Fri Aug 14 05:37:03 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7ECb2WW015273 for ; Fri, 14 Aug 2009 05:37:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7ECavaf028585 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Fri, 14 Aug 2009 13:37:02 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00B079PPXW00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 05:37:01 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD004IE9POBL20@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 05:37:01 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7ECb04X000326 for ; Fri, 14 Aug 2009 12:37:00 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOD000009JNSP00@fe-emea-10.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Fri, 14 Aug 2009 13:36:40 +0100 (BST) Received: from [10.16.46.61] ([unknown] [10.16.46.61]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOD00IBS9P0VZG0@fe-emea-10.sun.com>; Fri, 14 Aug 2009 13:36:36 +0100 (BST) Date: Fri, 14 Aug 2009 14:36:36 +0200 From: Joerg Barfurth Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A853DA2.6000408@Sun.COM> Sender: Joerg.Barfurth@sun.com To: Darren J Moffat Cc: Brian Cameron , Brian Cameron , lsarc-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A855A54.4040703@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> <20090813203004.GC10982@Sun.COM> <4A8484B0.7030409@sun.com> <4A853DA2.6000408@Sun.COM> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 7799 Darren J Moffat schrieb: >> I thought you were suggesting that the list of users to be shown in the >> face browser be specified by GDM configuration, rather than using >> heuristics to decide which users to show. The word "hardcoding" was >> a poor word choice on my part. What I meant was: >> >> - We want to avoid a sysadmin needing to configure GDM to specify what >> users to include in the face browser. >> - An opt-in mechanism has been suggested. Perhaps you mean that after >> authentication, the GDM GUI would ask the user if they want to show >> up in the face browser or not, and the configuration would be modified >> to only include users who opt-in. Something like this could work, >> though it would be a fair bit of work to get it right with upstream. >> For example, how do users change their mind if they picked "No", but >> then decide "Yes" later (or vice versa). Does GDM need new GUI >> elements to allow users to change their setting, and if so, how to >> properly integrate this into the overall desktop experience. Not >> impossible to implement, but time consuming. > > You need that optin/out and change of mind anyway. Not having it > presents a privacy problem. > In all desktop environments I know, there is no individual opt in/out for being listed in user lists. If listing any (real) users is a privacy problem, then userlist browsing should be turned off on the system. Note that, unless strong lockdown is configured, authenticated users will generally be able to browse user lists (e.g. 'getent passwd'). > Consider a multi national company that has facebrowsing on by default > and users from all over the world (with different privacy jurisdictions > and personal expectations). They all use a common set of Sun Ray or > other multi seat systems. You need to have a per user method of optin > and/or optout. This can not be done (and be safe legally) based on > heuristics keyed off assumptions that local nameservice accounts are > different. > > There maybe cases where it is acceptable for a user to be in the > face-browser on some machines that share the same nameservice and home > directory but not others. Though I'd regard that as a more advanced > config. For example, wanting their face on their local workstation in > their office but not if they use a Sun Ray server in a public area - > same nameservice, same home dir (neither of which have a local account). > Whether face browsing is on is a characteristic of the system, not of the user. All a user gets to control is the image associated with them, if they are listed. If listing the name in a list that is visible to unauthenticated users with access to a login screen is a legal problem in any relevant legislation, then face browsing should be turned off across the system. If Sun Ray servers are in a fail over group, you need to have local system config be as identical as possible to provide a true failover experience. If a set of Sun Rays has different security characteristics (e.g. is in a publically accessible location) to the rest, they should be on a different server (with different security config). We don't have logn-head specific PAM configuration either (today). There may be an exception, if a special seat offers a special environment instead of ordinary login (e.g. you currently can have Kiosk running on selected Sun Rays, but I wouldn't recommend that, if that main uses of the server are sensitive). >>> when that option is enabled then GDM would not >>> need any local user heuristics. I find such heuristics rather >>> objectionable. >> >> The heuristics have nothing to do with the image. The heuristics are >> used to determine which users show up in the Face Browser at all. >> Normally you only want the local users to show up in the Face Browser. > > Local user is a bogus requirement. > It seems the term is ambiguous. I think here the focus is on 'locally added', i.e. the user (account) was explicitly added to the specific system. This corresponds to 'local user' in the sense of 'in a local name service and authentication authority'. This has nothing to do with 'user having a local login (or session)' vs. 'remote login', which is another context in which the term 'local user' is sometimes used.. > Am I a local user on my workstation in my office ? Yes, but I may not > have an account in /etc/passwd or a local home dir. > In the sense that is relevant here, you are a local user of that workstation, if you (or whoever administers that workstation) has explicitly configured this machine to be used by you rather than you having access because the machine trusts a non-local user authority. The intent is that: - if this machine has been explicitly set up for *your* use, you show up in the list. - if you use a machine from a pool of machines that accepts you by reference to a non-local authority, then you become listed after first using the machine. > Am I a local user on the Sun Ray DTU in my office ? Yes ? and again no > local account or home dir is likely. > Similar, but here the 'configured explicitly for your use' case is less likely. > Am I a local user on my laptop ? Yes and in this case I likely do have a > local password entry and local home dir. > Yes. And thus it should show only you (or people you share your laptop with) in that list. > Am I a local user on my at home workstation ? Yes and like the laptop > case I may have a local password entry and I may or may not have a local > home dir. > Again, if the association with you gets created explicitly (and most often by creation of a local 'files' account), you should be listed by virtue of that configuration step. If the association with you gets created by you starting to use the machine without anyone explicitly provisioning you as user of the machine, then you should be listed only by virtue of being in the history files. > So what is "normal" here ? > I think the two sets of scenarios: - Personal machine with individually configured local account (where the home dir is doesn't make a difference, really) - Shared/sharable machine, using a network user authority. .. are considered normal. Certainly these scenarios and a mix where there are both locally defined and network accounts are what seems to be addressed by the described heuristic. Deployments where local passwd files containing large user populations are copied from elsewhere are probably considered too 'un-normal' to get special consideration by this feature: either they live with showing all those accounts or else they should turn off the feature for the system. Sounds at least as reasonable as creating and maintaining configuration knobs for all remote possibilities. > I think we are actually pretty close with the caching proposal to having > this be able to work by default. The one change I believe is necessary > is not making assumptions based on nameservice location of a user. > Partly because it really isn't as simple as looking in /etc/passwd - > what about when compat mode is on ? What about accounts with local > passwd but remote home dir ? > I think it is the mere fact that the user has an explicit entry in the local passwd file that is supposed to trigger the 'include in list'. What I don't know is, if the currently implemented fgetpwent-based logic will handle all these cases properly. - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From Nicolas.Williams@sun.com Fri Aug 14 09:28:53 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7EGSqId022120 for ; Fri, 14 Aug 2009 09:28:52 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7EGSoTk019710; Fri, 14 Aug 2009 17:28:50 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOD00801KG1CN00@brm-avmta-1.central.sun.com>; Fri, 14 Aug 2009 10:28:49 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOD00L7SKG1RR70@brm-avmta-1.central.sun.com>; Fri, 14 Aug 2009 10:28:49 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7EGI97R001511; Fri, 14 Aug 2009 11:18:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7EGI9R5001510; Fri, 14 Aug 2009 11:18:09 -0500 (CDT) Date: Fri, 14 Aug 2009 11:18:09 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8536C5.5060200@sun.com> To: Joerg Barfurth Cc: Brian Cameron , desktop-discuss@opensolaris.org, lsarc-ext@sun.com Message-id: <20090814161809.GE1043@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A843780.809@sun.com> <4A843BC9.5070607@Sun.COM> <20090813163319.GW10982@Sun.COM> <4A8472C2.9030900@sun.com> <20090813203004.GC10982@Sun.COM> <4A8484B0.7030409@sun.com> <20090813215341.GF10982@Sun.COM> <4A849F31.4010606@sun.com> <20090813234728.GB1043@Sun.COM> <4A8536C5.5060200@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2404 On Fri, Aug 14, 2009 at 12:04:53PM +0200, Joerg Barfurth wrote: > Nicolas Williams schrieb: > >On Thu, Aug 13, 2009 at 06:18:09PM -0500, Brian Cameron wrote: > >>This sort of design is contrary to the way people want GDM to work > >>on other distros, so I am unsure if the changes needed to make it work > >>this way would go upstream. Most other distros want it to work with > >>all local userids out-of-the-box as it does in other popular operating > >>systems. > > > >I don't think the local user heuristics are a good idea on any Unix or > >Unix-like OS. I don't mind if the upstream community prefers to have > >those heuristics on Linux or *BSD, but I don't think those heuristics > >are at all appropriate, so let's not have those on Solaris. > > Browsable user lists [*] are a standard feature of the login experience > on most systems. They should be usable out of the box on a newly > installed system. Local users added during installation or using local > management tool should usually be part of the browseable list. I believe you missed the point. It is NOT the case that the face browser can't work out of the box just because there's an opt-in system. That's because _obviously_ the installer can opt-in the user automatically. > The local/non-local distinction seems to be an obvious one to reconcile > these requirements. But with local accounts a set of rules is needed to > eliminate the system accounts. On a personal system the installer can opt-in the user. Additional users created by a useradd tool can also be automatically opted-in. And the face browser can also list recently logged-in users. That way the face browser can work out of the box with no local user heuristics, no user enumeration. And it can work for local and non-local users alike. To make that work you need a local store of users that should appear in the face browser. That could be /var/gdm/users/$username/{dmrc, face, ...}. Depending on the install and other tools teams to manage the opt-in of local users may seem annoying, but it allows GDM to avoid those heuristics. > >>- The users show up in the face browser after you log into them the > >> first time. > > > >Yes that's fine. > > > > The part where nobody shows up initially and newly added local users > also don't show up is what I don't agree to: You're taking parts of the thread out of context. See above. Nico -- From Alan.Coopersmith@sun.com Sat Aug 15 09:52:16 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7FGqF2L006492 for ; Sat, 15 Aug 2009 09:52:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7FGq8HD003364 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Sat, 15 Aug 2009 17:52:15 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOF00F01G72SK00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 15 Aug 2009 09:52:14 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOF003OHG6PGEA0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 15 Aug 2009 09:52:13 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7FGq1DN026668 for ; Sat, 15 Aug 2009 09:52:01 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOF00400FXI6E00@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 15 Aug 2009 09:52:01 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOF004JIG6O2O00@fe-sfbay-09.sun.com>; Sat, 15 Aug 2009 09:52:01 -0700 (PDT) Date: Sat, 15 Aug 2009 09:52:00 -0700 From: Alan Coopersmith Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4a8532cb.d6v4eMlEPZaAflWP%Joerg.Schilling@fokus.fraunhofer.de> Sender: Alan.Coopersmith@sun.com To: Joerg Schilling Cc: Brian.Cameron@sun.com, lsarc-ext@sun.com, desktop-discuss@opensolaris.org, bc99092@sac.sfbay.sun.com Message-id: <4A86E7B0.8070103@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843B24.3010804@sun.com> <4A845A75.9010907@sun.com> <4a8532cb.d6v4eMlEPZaAflWP%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 495 Joerg Schilling wrote: > Giving any kind of information about known user names is considered a security > risk since aprox. 35 years on UNIX. Depends on site security policy - it's in the same area as deciding whether or not to allow fingerd to run to allow remote user name queries. It's not always bad or forbidden, just an option some sites will want and others will not. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com Sat Aug 15 10:43:50 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7FHhne3007070 for ; Sat, 15 Aug 2009 10:43:50 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7FHhlw1023355 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Sat, 15 Aug 2009 18:43:48 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOF00J07IKZZV00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 15 Aug 2009 10:43:47 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOF0081AIKZN020@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 15 Aug 2009 10:43:47 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7FHeH4R009203 for ; Sat, 15 Aug 2009 17:43:46 +0000 (GMT) Received: from mmp12es.mmp.us.syntegra.com ([160.41.208.12] [160.41.208.12]) by relay14i.sun.com with ESMTP id BT-MMP-144830 for lsarc-ext@sun.com; Sat, 15 Aug 2009 17:43:46 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp12es.mmp.us.syntegra.com with ESMTP id BT-MMP-54496203 for lsarc-ext@sun.com; Sat, 15 Aug 2009 17:43:43 +0000 (Z) Received: from relay02-haj2.antispameurope.com ([83.246.65.52] [83.246.65.52]) by relay1i.sun.com with ESMTP id BT-MMP-5293786 for lsarc-ext@sun.com; Sat, 15 Aug 2009 17:43:42 +0000 (Z) Received: by relay02-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id F0E4E6F0590; Sat, 15 Aug 2009 19:43:41 +0200 (CEST) Received: from pluto.fokus.fraunhofer.de (pluto.fokus.fraunhofer.de [195.37.77.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by relay02-haj2.antispameurope.com (ASE-Secure-MTA) with ESMTP id 6651E6F057E; Sat, 15 Aug 2009 19:43:41 +0200 (CEST) Received: from EXCHSRV.fokus.fraunhofer.de (bohr.fokus.fraunhofer.de [10.147.9.231]) by pluto.fokus.fraunhofer.de (8.14.2/8.14.2) with SMTP id n7FHhduD025768; Sat, 15 Aug 2009 19:43:39 +0200 (MEST) Received: from rigel ([10.147.65.195]) by EXCHSRV.fokus.fraunhofer.de with Microsoft SMTPSVC(6.0.3790.3959); Sat, 15 Aug 2009 19:43:39 +0200 Date: Sat, 15 Aug 2009 19:43:04 +0200 From: Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A86E7B0.8070103@sun.com> Sender: Joerg.Schilling9ab33xy531fokus.fraunhofer.de@bounce.antispameurope.com To: Alan.Coopersmith@sun.com Cc: lsarc-ext@sun.com, desktop-discuss@opensolaris.org, Brian.Cameron@sun.com, bc99092@sac.sfbay.sun.com Message-id: <4a86f3a8.NYBmyXVbS0SNhWVG%Joerg.Schilling@fokus.fraunhofer.de> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Antispam: No, score=0.0/5.0, scanned in 3.017sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843B24.3010804@sun.com> <4A845A75.9010907@sun.com> <4a8532cb.d6v4eMlEPZaAflWP%Joerg.Schilling@fokus.fraunhofer.de> <4A86E7B0.8070103@sun.com> User-Agent: nail 11.22 3/20/05 X-OriginalArrivalTime: 15 Aug 2009 17:43:39.0704 (UTC) FILETIME=[EC84C380:01CA1DCF] Status: RO Content-Length: 857 Alan Coopersmith wrote: > Joerg Schilling wrote: > > Giving any kind of information about known user names is considered a security > > risk since aprox. 35 years on UNIX. > > Depends on site security policy - it's in the same area as deciding whether or > not to allow fingerd to run to allow remote user name queries. It's not always > bad or forbidden, just an option some sites will want and others will not. OK, you are right with fingerd, but the last time I did see a working fingerd on a worldwide base was in 1997 ;-) Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily From Alan.Coopersmith@sun.com Sat Aug 15 12:15:41 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7FJFeZe011841 for ; Sat, 15 Aug 2009 12:15:41 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7FJFbML000998 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Sat, 15 Aug 2009 20:15:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOF00201MU3MH00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 15 Aug 2009 12:15:39 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOF00J81MU28J60@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 15 Aug 2009 12:15:38 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7FJFcrh028819 for ; Sat, 15 Aug 2009 12:15:38 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOF00B00MTMZS00@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Sat, 15 Aug 2009 12:15:38 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOF004WPMU22OB0@fe-sfbay-09.sun.com>; Sat, 15 Aug 2009 12:15:38 -0700 (PDT) Date: Sat, 15 Aug 2009 12:15:38 -0700 From: Alan Coopersmith Subject: Re: [desktop-discuss] GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4a86f3a8.NYBmyXVbS0SNhWVG%Joerg.Schilling@fokus.fraunhofer.de> Sender: Alan.Coopersmith@sun.com To: Joerg Schilling Cc: lsarc-ext@sun.com, desktop-discuss@opensolaris.org, Brian.Cameron@sun.com, bc99092@sac.sfbay.sun.com Message-id: <4A87095A.3050404@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A82820E.3020700@Sun.COM> <4A843780.809@sun.com> <4A843B24.3010804@sun.com> <4A845A75.9010907@sun.com> <4a8532cb.d6v4eMlEPZaAflWP%Joerg.Schilling@fokus.fraunhofer.de> <4A86E7B0.8070103@sun.com> <4a86f3a8.NYBmyXVbS0SNhWVG%Joerg.Schilling@fokus.fraunhofer.de> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1120 Joerg Schilling wrote: > Alan Coopersmith wrote: > >> Joerg Schilling wrote: >>> Giving any kind of information about known user names is considered a security >>> risk since aprox. 35 years on UNIX. >> Depends on site security policy - it's in the same area as deciding whether or >> not to allow fingerd to run to allow remote user name queries. It's not always >> bad or forbidden, just an option some sites will want and others will not. > > OK, you are right with fingerd, but the last time I did see a working fingerd > on a worldwide base was in 1997 ;-) Given this is the gui login, it's even more restricted than finger - by default, only exposing the usernames to those with direct physical console access. If sites optionally turn on remote gui login via XDMCP, most will have that restricted to inside their firewall. (The first time I saw a "face browser" login was around 1995 on SGI Irix machines, so there is a long history of this on Unix systems.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Brian.Cameron@sun.com Mon Aug 17 12:43:24 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7HJhNh2006031 for ; Mon, 17 Aug 2009 12:43:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7HJh4ug017969 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 17 Aug 2009 20:43:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOJ00A03DGADA00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 17 Aug 2009 12:43:22 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOJ009SNDG9MO20@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 17 Aug 2009 12:43:22 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7HJhL9b011334 for ; Mon, 17 Aug 2009 19:43:21 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOJ00600DDKMO00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Mon, 17 Aug 2009 13:43:21 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.211.121.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOJ000UBDG10YF0@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Mon, 17 Aug 2009 13:43:14 -0600 (MDT) Date: Mon, 17 Aug 2009 14:43:38 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8512E0.7030807@sun.com> Sender: Brian.Cameron@sun.com To: Joerg Barfurth Cc: LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A89B2EA.9020301@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A83EEC9.5080800@sun.com> <4A849590.1090509@sun.com> <4A8512E0.7030807@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 4443 Joerg: On 08/14/09 02:31, Joerg Barfurth wrote: > Brian Cameron schrieb: > I justed wanted to know (and have recorded in this case) some of the > architectural gotchas we have to deal with, at least for the transition. Much appreciated. >>> 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. >> > > [...] > >> 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. >> > > We'll need to do extra work to make Kiosk Mode work under new GDM > anyway. From what I know now, it certainly seems that AutomaticLogin > with the "!scriptname" feature would be the best approach here. Okay, this is a fairly trivial feature to add back to the new GDM and generally useful for terminal server environments where you might want different users to log into different machines based on the display. I'll make sure this feature gets added back to the new GDM. >> That said, I think getting this to work with AutomaticLogin, if >> possible, would be the better approach. >> > > Yes. I'll try to work with you on that. Once I get the above feature working, I'll provide you with packages for testing. >>> 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 you plan to change it, is "Uncommitted" the right stability for the > $HOME/.dmrc path? No. Volatile would be better. > OTOH that is a pre-existing gdm interface (and for example Kiosk Mode is > currently using it ...), so switching that will not be that easy. I think the best solution is to add a configuration option to GDM so that it can be configured to access the file either from the user's $HOME directory or from the cache. >> 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. > > On Sun Ray systems you often have large number of sessions sitting at > the greeter (on unused clients). That shouldn't be a performance issue. The processes that run with the greeter are not resources intensive. There might be a bit of a performance hit when they first start up, especially when a lot of them start up at once, which does happen in Sun Ray environments. But it is a one-time hit each time you restart the server, and shouldn't be a big impact after that. > But if use of AutomaticLogin avoids this in cases that don't need it at > all, that addresses an important part of my concerns. Great. I'm sure we can work together and get it working. Brian From Brian.Cameron@Sun.COM Mon Aug 17 13:02:49 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7HK2nrb006680 for ; Mon, 17 Aug 2009 13:02:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7HK2moQ026239 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 17 Aug 2009 13:02:48 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOJ00F03ECOSU00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 17 Aug 2009 13:02:48 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOJ0096FECNO260@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 17 Aug 2009 13:02:47 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7HK2iiS019418 for ; Mon, 17 Aug 2009 20:02:47 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOJ00G00CYIQL00@mail-amer.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 17 Aug 2009 14:02:44 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.211.121.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOJ00CQXEBKGQ70@mail-amer.sun.com>; Mon, 17 Aug 2009 14:02:09 -0600 (MDT) Date: Mon, 17 Aug 2009 15:02:33 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A852BD1.8010200@sun.com> Sender: Brian.Cameron@Sun.COM To: Joerg Barfurth Cc: Brian Cameron , LSARC-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A89B759.3060900@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A84A88B.9040407@sun.com> <4A852BD1.8010200@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1208 Joerg: >> + Also note that GDM has a bug that all GDM login GUI's share the same >> + GConf settings, so that changing a setting (such as enabling an a11y >> + feature) will affect logins on all systems. Until this bug is fixed, >> + it is best to disable GDM a11y in multi-user environments. >> + > > This probably should be worded to be more about multi-*seat* > environments. On a single seat it isn't really surprising that login > settings are sticky. (And I don't know what "all systems" should mean in > this context.) Yes, I meant multi-seat. Poor wording on my part. Instead of "logins on all systems" I meant to say that whenever one GConf setting changes for the "gdm" user it affects all login programs on that machine since they all share the same "gdm" user account. For example, if you turn on GOK in one GDM window, it will start running in all gdmgreeter screens that are running at the same time. To fix this problem, we likely need to make use of the new GCONF_DEFAULT_SOURCE_PATH so that each seat can specify its own GConf settings directory. Then the settings would be sticky per-seat, which would likely be reasonable. http://bugzilla.gnome.org/show_bug.cgi?id=586183 Brian From Brian.Cameron@sun.com Mon Aug 17 17:15:27 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7I0FR4m016017 for ; Mon, 17 Aug 2009 17:15:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7I0FRSS017609 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 17 Aug 2009 17:15:27 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOJ00F03Q1RXW00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 17 Aug 2009 18:15:27 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOJ00A5WQ1QR820@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Mon, 17 Aug 2009 18:15:27 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7I0FQoh017004 for ; Tue, 18 Aug 2009 00:15:26 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOJ00G00PS0EI00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Mon, 17 Aug 2009 18:15:26 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.213.24.197]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOJ0016OQ1P2IE0@mail-amer.sun.com>; Mon, 17 Aug 2009 18:15:26 -0600 (MDT) Date: Mon, 17 Aug 2009 19:15:50 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A83EEC9.5080800@sun.com> Sender: Brian.Cameron@sun.com To: Joerg Barfurth Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A89F2B6.2030605@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A83EEC9.5080800@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1636 Joerg: >> - /usr/bin/gdmdynamic [--add=DISPLAY | --delete=DISPLAY | --list ] > > This still allows specifying the X server to start when adding a > display, doesn't it? Yes, although this is not specified on the gdmdynamic command any longer. Instead this is specified in the ConsoleKit configuration. The /usr/bin/gdmdynamic script passes ck-seat-tool the --display-type=Sunray argument, which specifies the Xserver to use. >> - /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, the Fast User Switch applet just tells GDM to start up a new VT session and passes along the userid that the user has picked. Then GDM starts the normal PAM session passing in PAM_USER. > 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? I simply meant that the Fast User Switch applet assumes that the PAM stack will work with a supplied username. Not all PAM stacks will work with the Fast User Switch applet. For example, if you configured a system to only work with a fingerprint scanner, the Fast User Switch applet would not work with that since the username is associated with the fingerprint and not something that is supplied. Brian From Brian.Cameron@Sun.COM Mon Aug 17 18:19:56 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7I1JtHb016878 for ; Mon, 17 Aug 2009 18:19:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7I1Js9k000933 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 18 Aug 2009 02:19:55 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOJ00F03T13E700@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Mon, 17 Aug 2009 18:19:51 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOJ002K5T139S80@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Mon, 17 Aug 2009 18:19:51 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7I1Jpt0003286 for ; Tue, 18 Aug 2009 01:19:51 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOJ00300ST6LS00@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Mon, 17 Aug 2009 19:19:51 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.213.24.197]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOJ00JJ4T12X0B0@mail-amer.sun.com>; Mon, 17 Aug 2009 19:19:50 -0600 (MDT) Date: Mon, 17 Aug 2009 20:20:14 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> Sender: Brian.Cameron@Sun.COM To: Brian Cameron Cc: LSARC-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A8A01CE.5070708@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 8692 Thanks to everyone for helping to review this GDM case. I would like to summarize the issues raised so far, and the proposed solutions. I have not yet updated the case materials to reflect the proposed solutions, but will do so if the committee is agreeable to approve this case with these changes. - Although nobody has raised this issue, I feel obligated to remind people of the issue discussed in section 4.1.14. The last time that GDM proposed to be the default login program (LSARC 2005/417), it was derailed because GDM lacks a "drop to console" feature like CDE login has. When graphical VT support is integrated in build 122, it will be possible for people to use VT switching to drop to console. However, in my recent discussions with the VT team, they plan to not enable the vtdaemon service by default until a later build. There are still some remaining bugs with vtdaemon which are unlikely to be fixed by the time that this case integrates. It is not yet clear when these issues will be resolved and which build the service will be enabled by default. Once the vtdaemon is enabled by default, or if the user enables it, then GDM will work with graphical VT. So, in the meantime, users who need a drop to console feature will need to enable the vtdaemon service to use this. Since users have lived without a "drop to console" feature in OpenSolaris from day one, this case does not make the situation any worse. - Several people (Joerg Barfurth, Darren Moffat, Nicolas Williams) have highlighted that GDM should not touch the user's $HOME directory before the user authenticates. Currently GDM accesses the user's face image ($HOME/.face) and the user's session/language defaults ($HOME/.dmrc) before pam_setcred. Touching the user's $HOME directory before pam_setcred causes problems for kerberos, for example. Proposed solution: - The SUNWgnome-display-mgr-root package would install a directory /var/cache/gdm. - At run-time GDM would create a directory /var/cache/gdm/user-$uid when a user logs in, if the directory does not already exist. In this directory will be placed two files: dmrc and face. - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then GDM will log the user into the default session/language or whichever ones they selected in the GUI. Then it will save the dmrc file to the cache with the default settings. On next login, the defaults will be read from the cache. - On first login the /var/cache/gdm/user-$uid/face file will not exist so the user will see a generic user icon for their face. After authentication, GDM will check if the user has a defined face and copy it to the cached file. Also, on logout, GDM will check again if the user has a defined face and copy it to the cached file. Updating the cache on logout ensures the face image will be available on next login if the user defined it during their session. Obviously the face image will only be copied to the cache if one is not already in the cache or if the cached file is older. - Darren Moffat and Nicolas Williams say that the Face Browser should not use any heuristics to determine if users should be displayed in the Face Browser or not. For example, GDM should not assume that only users in /etc/passwd with a valid shell should be included. Darren Moffat further suggests that users must opt-in to be visible in the Face Browser. Otherwise Darren feels there is a privacy issue. Proposed solution: This issue is partly solved by addressing the issue above, where we move the user's face image to /var/cache/gdm. In addition to that solution, one of the two following approaches could be used to address these concerns: 1) Only display users in the Face Browser which have an image file specified. Though users with a UID < 100 would be filtered out even if somebody put an image file in the cache. 2) When users first login, create an empty file in /var/cache/gdm/user-$uid/face, which would indicate to the Face Browser to display any user who has logged in on this machine. Again, aside from system users who have a UID < 100. Solution #1 better addresses Darren Moffat's preference that users must opt-in to use the Face Browser. However, I personally think solution #2 is more appropriate. The problem with solution #1 is that it makes using the Face Browser more cumbersome. Other operating systems use Face Browsers that "just work" and do not require such configuration. To me it seems more appropriate to simply turn off the Face Browser entirely in environments where such privacy issues are a concern. - There are many concerns about the Face Browser and whether it should be turned on by default. - Glenn Faden suggested it not be the default because it is a potential security vulnerability to expose usernames before authentication. Proposed Solution: Turn off the Face Browser by default. This will make OpenSolaris different than everybody else, but our users love us because we are such curmudgeons about these things, I guess. - Joerg Barfurth highlighted that Sun Ray kiosk mode needs the greeter to not display when the PAM stack requires no user interaction. GDM provides an Automatic Login feature which works mostly as desired. However, some work will be needed to make it work as needed by Sun Ray. The new GDM only allows you to hardcode a single username to work with AutomaticLogin, while Sun Ray needs the ability to specify this username per-display. Proposed Solution: The old GDM had a feature where you could specify the username as a script which is passed the DISPLAY environment variable and which returns the username to be used with AutomaticLogin. Adding back this feature should provide Sun Ray kiosk mode with the feature they need. - Joerg Barfurth highlighted that since the "gdm" user only has a single GConf directory that any configuration change on one seat will affect all the others. For example, if you turn on a greeter accessibility feature on one seat, then that feature will turn on for all displays that are showing the greeter. Proposed Solution: Make use of the new GCONF_DEFAULT_SOURCE_PATH environment variable so that each seat can specify its own GConf settings directory. Then the settings would be sticky per-seat, which would likely be reasonable. Other issues which were discussed, which I think were addressed in the email discussion, include: - Alan Coopersmith raised the issue that we need a follow-up case to EOL CDE Login. Personally I think that it would make more sense if the engineers within the Desktop team who are responsible for CDE login were to follow-up with such a case. It would be better, I think, if those people who best understand how CDE login works were to be responsible for such a case and answering questions about how the transition will be managed, etc. - Glenn Faden had a concern that the "Shutdown" and "Reboot" buttons should not appear in the GDM login GUI by default. This is not a problem since they only appear if the "gdm" user has the solaris.system.shutdown authority, which it does not have by default. - Darren Moffat suggested that we offer an xterm.desktop file so that user's can have access to a terminal session. The project team agreed and has already integrated this into our GDM development build. - Joerg Barfurth highlighted that the new GDM does not provide a true "failsafe session". While the xterm.desktop does allow people to login without starting the full GNOME stack, it does source the user's .profile, etc. So, if the user needs to fix an error in this sort of configuration file, then they would need to use some other mechanism, such as VT switching to the console. - Nicolas Williams wanted clarification that the session should be started by the process that did the PAM and audit work, or by its progeny, after pam_open_session(3PAM) is called, and before pam_close_session(3PAM) is called. I verified that this is the case. - Nicolas Williams wanted verification that Xserver a11y is available when GDM is used. I verified that it is available. - Also note the regressions in section 4.1.15. I don't think these are cause for much concern, nor have they generated much discussion but I recommend that people look over them if they have not already. --- Brian From jason.brian.king@gmail.com Mon Aug 17 19:21:56 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7I2Luxp017619 for ; Mon, 17 Aug 2009 19:21:56 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7I2Ltp9022462; Mon, 17 Aug 2009 19:21:55 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOJ00605VWJX600@brm-avmta-1.central.sun.com>; Mon, 17 Aug 2009 20:21:55 -0600 (MDT) Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOJ00A0DVWIQQ90@brm-avmta-1.central.sun.com>; Mon, 17 Aug 2009 20:21:55 -0600 (MDT) Received: from relay43i.sun.com ([192.5.209.74]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7I2Ls4p012641; Tue, 18 Aug 2009 02:21:54 +0000 (GMT) Received: from mms48es.mms.us.syntegra.com ([160.41.221.230] [160.41.221.230]) by relay43i.sun.com with ESMTP id BT-MMP-2833248; Tue, 18 Aug 2009 02:19:54 +0000 (Z) Received: from relay42i.sun.com (relay42i.sun.com [192.5.209.72]) by mms48es.mms.us.syntegra.com with ESMTP id BT-MMP-60777503; Tue, 18 Aug 2009 02:19:53 +0000 (Z) Received: from mail-bw0-f228.google.com ([209.85.218.228] [209.85.218.228]) by relay4i.sun.com with ESMTP id BT-MMP-13680323; Tue, 18 Aug 2009 02:19:53 +0000 (Z) Received: by bwz28 with SMTP id 28so2629932bwz.6 for ; Mon, 17 Aug 2009 19:19:51 -0700 (PDT) Received: by 10.239.130.145 with SMTP id 17mr424509hbj.52.1250561991565; Mon, 17 Aug 2009 19:19:51 -0700 (PDT) Date: Mon, 17 Aug 2009 21:19:51 -0500 From: Jason King Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8A01CE.5070708@sun.com> Sender: jason.brian.king@gmail.com To: Brian Cameron Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=mTc62pqDj2/gAoD7yWsMuJhdxcALJ48ZMyh1nleMiX0=; b=fMGJkEu8fnc0NvVGqeS333rOJzkXynXHTAkOA0l/ticeePCU4r/IJDsvqrGZz4KKwy dUZ/gTpwYwcOzjn6qZ9jkiaSL3C7CkXlQfwBqDQLUlY7gt3WMZP/I5S/cxgqeosuRss/ fIMrqxlP426GwwlkyhmmWVNUxM+Etz0khok0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=oA8AYUuxIfv0rLakxkNsHqUa8m6k4B8WfUxqJoRsVJt3TesTiikL3BBzvfHKHT/ZF2 1o7QtmQkbMRiuWv7F6e0WuYUt0BIQ6pYwKhWNgZ/odVCzA4cBCf+x1OmJoUE+gFG5BWz AXPT35iWTwGoLOKKnspTahdTazH0+8PsM65qA= X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-Google-Sender-Auth: cb0f0476a9c31706 X-Antispam: No, score=-2.6/5.0, scanned in 0.155sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sac.sfbay.sun.com id n7I2Luxp017619 Status: RO Content-Length: 9555 Two questions from the peanut gallery, inline... On Mon, Aug 17, 2009 at 8:20 PM, Brian Cameron wrote: > > Thanks to everyone for helping to review this GDM case.  I would like > to summarize the issues raised so far, and the proposed solutions. > I have not yet updated the case materials to reflect the proposed > solutions, but will do so if the committee is agreeable to approve > this case with these changes. > > - Although nobody has raised this issue, I feel obligated to remind >  people of the issue discussed in section 4.1.14.  The last time >  that GDM proposed to be the default login program (LSARC 2005/417), >  it was derailed because GDM lacks a "drop to console" feature like >  CDE login has. > >  When graphical VT support is integrated in build 122, it will be >  possible for people to use VT switching to drop to console.  However, >  in my recent discussions with the VT team, they plan to not enable >  the vtdaemon service by default until a later build.  There are still >  some remaining bugs with vtdaemon which are unlikely to be fixed by >  the time that this case integrates.  It is not yet clear when these >  issues will be resolved and which build the service will be enabled >  by default.  Once the vtdaemon is enabled by default, or if the user >  enables it, then GDM will work with graphical VT.  So, in the >  meantime, users who need a drop to console feature will need to >  enable the vtdaemon service to use this. > >  Since users have lived without a "drop to console" feature in >  OpenSolaris from day one, this case does not make the situation any >  worse. > > - Several people (Joerg Barfurth, Darren Moffat, Nicolas Williams) have >  highlighted that GDM should not touch the user's $HOME directory >  before the user authenticates.  Currently GDM accesses the user's >  face image ($HOME/.face) and the user's session/language defaults >  ($HOME/.dmrc) before pam_setcred.  Touching the user's $HOME >  directory before pam_setcred causes problems for kerberos, for >  example. > >  Proposed solution: > >  - The SUNWgnome-display-mgr-root package would install a directory >    /var/cache/gdm. >  - At run-time GDM would create a directory /var/cache/gdm/user-$uid >    when a user logs in, if the directory does not already exist.  In >    this directory will be placed two files: dmrc and face. >  - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then >    GDM will log the user into the default session/language or whichever >    ones they selected in the GUI.  Then it will save the dmrc file to >    the cache with the default settings.  On next login, the defaults >    will be read from the cache. >  - On first login the /var/cache/gdm/user-$uid/face file will not >    exist so the user will see a generic user icon for their face. >    After authentication, GDM will check if the user has a defined >    face and copy it to the cached file.  Also, on logout, GDM will >    check again if the user has a defined face and copy it to the >    cached file.  Updating the cache on logout ensures the face image >    will be available on next login if the user defined it during their >    session.  Obviously the face image will only be copied to the cache >    if one is not already in the cache or if the cached file is older. > > - Darren Moffat and Nicolas Williams say that the Face Browser should >  not use any heuristics to determine if users should be displayed in >  the Face Browser or not.  For example, GDM should not assume that >  only users in /etc/passwd with a valid shell should be included. >  Darren Moffat further suggests that users must opt-in to be visible >  in the Face Browser.  Otherwise Darren feels there is a privacy issue. > >  Proposed solution: > >  This issue is partly solved by addressing the issue above, where >  we move the user's face image to /var/cache/gdm.  In addition to that >  solution, one of the two following approaches could be used to >  address these concerns: > >  1) Only display users in the Face Browser which have an image file >     specified.  Though users with a UID < 100 would be filtered out >     even if somebody put an image file in the cache. >  2) When users first login, create an empty file in >     /var/cache/gdm/user-$uid/face, which would indicate to the Face >     Browser to display any user who has logged in on this machine. >     Again, aside from system users who have a UID < 100. > >  Solution #1 better addresses Darren Moffat's preference that users >  must opt-in to use the Face Browser.  However, I personally think >  solution #2 is more appropriate.  The problem with solution #1 is >  that it makes using the Face Browser more cumbersome.  Other >  operating systems use Face Browsers that "just work" and do not >  require such configuration.  To me it seems more appropriate to >  simply turn off the Face Browser entirely in environments where >  such privacy issues are a concern. > > - There are many concerns about the Face Browser and whether it should >  be turned on by default. > >  - Glenn Faden suggested it not be the default because it is a >    potential security vulnerability to expose usernames before >    authentication. > >  Proposed Solution: > >  Turn off the Face Browser by default.  This will make OpenSolaris >  different than everybody else, but our users love us because we are >  such curmudgeons about these things, I guess. My apologies if I missed this in the prior discussion, but how will this setting be managed? Specifically, can it be controlled via SMF? If my understanding is correct, having the ability to manage the behavior via SMF would tie in nicely to some of the automated installation work that is going on. If not, how would one control this behavior during an automated install? > > - Joerg Barfurth highlighted that Sun Ray kiosk mode needs the greeter >  to not display when the PAM stack requires no user interaction.  GDM >  provides an Automatic Login feature which works mostly as desired. >  However, some work will be needed to make it work as needed by Sun >  Ray.  The new GDM only allows you to hardcode a single username to >  work with AutomaticLogin, while Sun Ray needs the ability to specify >  this username per-display. > >  Proposed Solution: > >  The old GDM had a feature where you could specify the username as >  a script which is passed the DISPLAY environment variable and which >  returns the username to be used with AutomaticLogin.  Adding back >  this feature should provide Sun Ray kiosk mode with the feature they >  need. > > - Joerg Barfurth highlighted that since the "gdm" user only has a >  single GConf directory that any configuration change on one seat >  will affect all the others.  For example, if you turn on a greeter >  accessibility feature on one seat, then that feature will turn on >  for all displays that are showing the greeter. > >  Proposed Solution: > >  Make use of the new GCONF_DEFAULT_SOURCE_PATH environment variable so >  that each seat can specify its own GConf settings directory.  Then >  the settings would be sticky per-seat, which would likely be >  reasonable. > > Other issues which were discussed, which I think were addressed in the > email discussion, include: > > - Alan Coopersmith raised the issue that we need a follow-up case to >  EOL CDE Login.  Personally I think that it would make more sense if >  the engineers within the Desktop team who are responsible for CDE >  login were to follow-up with such a case.  It would be better, I >  think, if those people who best understand how CDE login works were >  to be responsible for such a case and answering questions about >  how the transition will be managed, etc. > > - Glenn Faden had a concern that the "Shutdown" and "Reboot" buttons >  should not appear in the GDM login GUI by default.  This is not a >  problem since they only appear if the "gdm" user has the >  solaris.system.shutdown authority, which it does not have by default. I could see this as being useful (though I agree not the default). Will this be documented anywhere (outside of this case) for those that might wish to enable it? > > - Darren Moffat suggested that we offer an xterm.desktop file so that >  user's can have access to a terminal session.  The project team >  agreed and has already integrated this into our GDM development build. > > - Joerg Barfurth highlighted that the new GDM does not provide a >  true "failsafe session".  While the xterm.desktop does allow people >  to login without starting the full GNOME stack, it does source the >  user's .profile, etc.  So, if the user needs to fix an error in >  this sort of configuration file, then they would need to use some >  other mechanism, such as VT switching to the console. > > - Nicolas Williams wanted clarification that the session should be >  started by the process that did the PAM and audit work, or by its >  progeny, after pam_open_session(3PAM) is called, and before >  pam_close_session(3PAM) is called.  I verified that this is the >  case. > > - Nicolas Williams wanted verification that Xserver a11y is available >  when GDM is used.  I verified that it is available. > > - Also note the regressions in section 4.1.15.  I don't think these >  are cause for much concern, nor have they generated much discussion >  but I recommend that people look over them if they have not already. > > --- > > Brian > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org > From Brian.Cameron@sun.com Mon Aug 17 21:12:26 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7I4CQgC023733 for ; Mon, 17 Aug 2009 21:12:26 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7I4CPUk051335 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Mon, 17 Aug 2009 22:12:26 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOK0050F10P8L00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 17 Aug 2009 21:12:25 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOK004BK10O6950@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 17 Aug 2009 21:12:25 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7I4COWv009541 for ; Tue, 18 Aug 2009 04:12:24 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOK00A000YQ2G00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Mon, 17 Aug 2009 22:12:24 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.213.24.197]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOK00CUR10NLD70@mail-amer.sun.com>; Mon, 17 Aug 2009 22:12:24 -0600 (MDT) Date: Mon, 17 Aug 2009 23:12:48 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: Sender: Brian.Cameron@sun.com To: Jason King Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8A2A40.8080105@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 2447 Jason: > Two questions from the peanut gallery, inline... > > On Mon, Aug 17, 2009 at 8:20 PM, Brian Cameron wrote: >> - There are many concerns about the Face Browser and whether it should >> be turned on by default. >> >> - Glenn Faden suggested it not be the default because it is a >> potential security vulnerability to expose usernames before >> authentication. >> >> Proposed Solution: >> >> Turn off the Face Browser by default. This will make OpenSolaris >> different than everybody else, but our users love us because we are >> such curmudgeons about these things, I guess. > > My apologies if I missed this in the prior discussion, but how will > this setting be managed? Specifically, can it be controlled via SMF? > If my understanding is correct, having the ability to manage the > behavior via SMF would tie in nicely to some of the automated > installation work that is going on. If not, how would one control > this behavior during an automated install? Making this work via a SMF properly seems a good idea to me. Especially if this is the sort of setting people would want to change during an automated install. Is this the only configuration option that needs such management? Note that GDM has GUI and daemon configuration. Some daemon configuration requires restarting GDM for a change to take effect. So it might be hard to make this work via SMF property for GDM server configuration options. However the Face Browser is a GDM greeter GUI configuration option, and easier to update on the fly. Without such a property, it would be necessary to set a GConf setting for the GDM user. This could be done by running the gconftool-2 command with the right arguments to set the desired configuration key as the "gdm" user. >> - Glenn Faden had a concern that the "Shutdown" and "Reboot" buttons >> should not appear in the GDM login GUI by default. This is not a >> problem since they only appear if the "gdm" user has the >> solaris.system.shutdown authority, which it does not have by default. > > I could see this as being useful (though I agree not the default). > Will this be documented anywhere (outside of this case) for those that > might wish to enable it? How about the GDM docs? http://library.gnome.org/admin/gdm/2.27/security.html.en#rbac These docs will match the docs that are installed on the local filesystem with the GDM packages. Brian From Alan.Coopersmith@sun.com Tue Aug 18 11:06:29 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7II6TA7029904 for ; Tue, 18 Aug 2009 11:06:29 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7II6S9o022872 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 18 Aug 2009 11:06:28 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL00F093MSP800@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 18 Aug 2009 11:06:28 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL00D7I3MRTA30@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 18 Aug 2009 11:06:28 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7II6RMB025230 for ; Tue, 18 Aug 2009 11:06:27 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KOL00F002WM6M00@fe-sfbay-10.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 18 Aug 2009 11:06:27 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KOL008B83MR0I90@fe-sfbay-10.sun.com>; Tue, 18 Aug 2009 11:06:27 -0700 (PDT) Date: Tue, 18 Aug 2009 11:06:27 -0700 From: Alan Coopersmith Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8A01CE.5070708@sun.com> Sender: Alan.Coopersmith@sun.com To: Brian Cameron Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8AEDA3.1000106@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1107 Brian Cameron wrote: > - Alan Coopersmith raised the issue that we need a follow-up case to > EOL CDE Login. Personally I think that it would make more sense if > the engineers within the Desktop team who are responsible for CDE > login were to follow-up with such a case. It would be better, I > think, if those people who best understand how CDE login works were > to be responsible for such a case and answering questions about > how the transition will be managed, etc. While EOL'ing dtlogin can be a separate case, this case must go forward with gdm as default, since we know that has happened without ARC review already. Things that were treated in previous gdm ARC cases as advice of "before gdm becomes the default login screen" must be treated as TCR's or TCA's for the "now that gdm is default" get-well plan. Pretending that gdm is not default is irresponsible and ignoring the reality of our existing OpenSolaris releases, and all Nevada builds 128 and later. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Nicolas.Williams@sun.com Tue Aug 18 11:26:20 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7IIQJjY000984 for ; Tue, 18 Aug 2009 11:26:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7IIPbxj019926; Tue, 18 Aug 2009 19:26:17 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL0090F4JQ1W00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 18 Aug 2009 11:26:14 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL006X94JPMJ10@nwk-avmta-1.sfbay.Sun.COM>; Tue, 18 Aug 2009 11:26:14 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7IIFUVV003555; Tue, 18 Aug 2009 13:15:30 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7IIFUGO003554; Tue, 18 Aug 2009 13:15:30 -0500 (CDT) Date: Tue, 18 Aug 2009 13:15:30 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8A01CE.5070708@sun.com> To: Brian Cameron Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090818181529.GM1043@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 3699 On Mon, Aug 17, 2009 at 08:20:14PM -0500, Brian Cameron wrote: > - Several people (Joerg Barfurth, Darren Moffat, Nicolas Williams) have > highlighted that GDM should not touch the user's $HOME directory > before the user authenticates. Currently GDM accesses the user's > face image ($HOME/.face) and the user's session/language defaults > ($HOME/.dmrc) before pam_setcred. Touching the user's $HOME > directory before pam_setcred causes problems for kerberos, for > example. > > Proposed solution: > > - The SUNWgnome-display-mgr-root package would install a directory > /var/cache/gdm. What will be the permissions on this and the files in it? > [...] Looks good to me. > - Darren Moffat and Nicolas Williams say that the Face Browser should > not use any heuristics to determine if users should be displayed in > the Face Browser or not. For example, GDM should not assume that > only users in /etc/passwd with a valid shell should be included. > Darren Moffat further suggests that users must opt-in to be visible > in the Face Browser. Otherwise Darren feels there is a privacy issue. > > Proposed solution: > > This issue is partly solved by addressing the issue above, where > we move the user's face image to /var/cache/gdm. In addition to that > solution, one of the two following approaches could be used to > address these concerns: I'd even say that /var/cache/gdm is sufficient because the installer can touch(1) the initial user's cached and $HOME/.face files, and so can the Users and Groups and useradd(1M) utilities. That means that local users will appear in the face browser, but with no local user heuristics. Opt-in can be a checkbox in the installer, Users and Groups, and useradd(1M) utilities. But that's probably not necessary: just opt-in all such users in the installer/useradd tools (no checkbox, just do it). If users/admins don't like that they can disable the face browser altogether. > 1) Only display users in the Face Browser which have an image file > specified. Though users with a UID < 100 would be filtered out > even if somebody put an image file in the cache. How would you determine (1) without looing in $HOME? If root is not a role, then why not put root in the face browser? > 2) When users first login, create an empty file in > /var/cache/gdm/user-$uid/face, which would indicate to the Face > Browser to display any user who has logged in on this machine. > Again, aside from system users who have a UID < 100. My comments to (1) apply here too. But also, one way to opt-out might be to rm $HOME/.face, yet (2) would seemingly not allow that (since it seems to clash with the idea that /var/cache/gdm/user-$uid/face is updated at logout time to be a copy of $HOME/.face). > - There are many concerns about the Face Browser and whether it should > be turned on by default. > > - Glenn Faden suggested it not be the default because it is a > potential security vulnerability to expose usernames before > authentication. > > Proposed Solution: > > Turn off the Face Browser by default. This will make OpenSolaris > different than everybody else, but our users love us because we are > such curmudgeons about these things, I guess. IMO: This is an issue, but it's an installer issue, not really a GDM issue. AI should almost certainly disable it by default, while the OpenSolaris installer should probably enable it by default. To force the matter GDM could have this feature disabled by default (a "safe" default), such that the OpenSolaris installer project team would have to do the enabling. Nico -- From Brian.Cameron@Sun.COM Tue Aug 18 11:49:44 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7IInhim001854 for ; Tue, 18 Aug 2009 11:49:43 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7IInelS006282 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 18 Aug 2009 19:49:42 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL00I0D5MTDL00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 18 Aug 2009 12:49:41 -0600 (MDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL00ABN5MS3W60@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 18 Aug 2009 12:49:40 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7IIneFI019999 for ; Tue, 18 Aug 2009 18:49:40 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOL00F004XHH200@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 18 Aug 2009 12:49:40 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.213.24.197]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOL00BD75MMWA80@mail-amer.sun.com>; Tue, 18 Aug 2009 12:49:34 -0600 (MDT) Date: Tue, 18 Aug 2009 13:49:58 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8AEDA3.1000106@sun.com> Sender: Brian.Cameron@Sun.COM To: Alan Coopersmith Cc: Brian Cameron , LSARC-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A8AF7D6.3000003@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <4A8AEDA3.1000106@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 3332 Alan: > Brian Cameron wrote: >> - Alan Coopersmith raised the issue that we need a follow-up case to >> EOL CDE Login. Personally I think that it would make more sense if >> the engineers within the Desktop team who are responsible for CDE >> login were to follow-up with such a case. It would be better, I >> think, if those people who best understand how CDE login works were >> to be responsible for such a case and answering questions about >> how the transition will be managed, etc. > > While EOL'ing dtlogin can be a separate case, this case must go forward > with gdm as default, since we know that has happened without ARC review > already. Lin Ma, the engineer on the Desktop team responsible for CDE login has been assigned the task of EOL'ing dtlogin. > Things that were treated in previous gdm ARC cases as advice > of "before gdm becomes the default login screen" must be treated as TCR's > or TCA's for the "now that gdm is default" get-well plan. Pretending > that gdm is not default is irresponsible and ignoring the reality of our > existing OpenSolaris releases, and all Nevada builds 128 and later. Looking at the mail log of LSARC 2005/417, the only issue raised as a TCR was the "drop to console" issue. As I have already stated in the ARC case and this mail thread, this will be addressed by VT. Since build 122, VT will be available, but not on by default. Users simply need to enable the vtdaemon service to have this feature. Also, the VT team plans to address the remaining bugs so the vtdaemon service can be enabled by default, though this probably will not happen before the end of this year. While there are some issues, this is a big step forward compared to what exists in OpenSolaris today. The other issues raised as needing to be done before GDM becomes the default login program have been addressed. These include: + IPv6 support + Solaris audit support + Solaris logindevperm & fbconsole support + accessibility support + G11N/I18N/L10N support + SunRay support with reasonable performance + Support XDMCP Wrappers. This provides XDMCP host allowed access since CDE login supports this feature via the accessFile /usr/dt/config/Xconfig resource. + Need to be able to launch chooser from login program + Support /var/dt/sdtlogin pipe with Xserver With one exception: + Need to be able to launch chooser from login program Which was listed as a known regression in this ARC case. This will be treated as a bug and fixed when we have the opportunity. Also, there were a few other "requirements" that no longer apply to the new GDM: + Specify different gdm.conf configuration file on startup. + Support /usr/share/gdm/gdm.conf and /etc/share/gdm/gdm.conf config files for system-wide and machine-specific configuration support. This is in GDM CVS head, and the default file is installed to /usr/share/gdm/gdm.conf. These are no longer needed because GDM now uses GConf to store its internal configuration and sysadmins can use normal GConf mechanisms to manage GConf default/mandatory settings across machines to provide alternative configurations. I am not aware of any further issues. If there are any, then please let me know. Brian From Brian.Cameron@sun.com Tue Aug 18 15:44:21 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7IMiKgt015037 for ; Tue, 18 Aug 2009 15:44:20 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7IMi91B001228 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 18 Aug 2009 23:44:19 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL00J05GHVOX00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 18 Aug 2009 16:44:19 -0600 (MDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL00890GHUZI40@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Tue, 18 Aug 2009 16:44:18 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7IMiIW7008248 for ; Tue, 18 Aug 2009 22:44:18 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOL00B00GDHBM00@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Tue, 18 Aug 2009 16:44:18 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.213.24.197]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOL006HPGHTKV90@mail-amer.sun.com>; Tue, 18 Aug 2009 16:44:18 -0600 (MDT) Date: Tue, 18 Aug 2009 17:44:43 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8A01CE.5070708@sun.com> Sender: Brian.Cameron@sun.com To: Brian Cameron Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8B2EDB.1000608@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 5863 I just had a two hour discussion about these topics with the upstream GDM co-maintainers, and want to update the proposal based on what would be acceptable to get these code changes upstream. Darren Moffat, I also have some questions about your requirement that the Face Browser support opt-in/opt-out, see below. > Proposed solution: > > - The SUNWgnome-display-mgr-root package would install a directory > /var/cache/gdm. root:gdm ownership and 640 permissions seem reasonable to me. > - At run-time GDM would create a directory /var/cache/gdm/user-$uid > when a user logs in, if the directory does not already exist. In > this directory will be placed two files: dmrc and face. > - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then > GDM will log the user into the default session/language or whichever > ones they selected in the GUI. Then it will save the dmrc file to > the cache with the default settings. On next login, the defaults > will be read from the cache. > - On first login the /var/cache/gdm/user-$uid/face file will not > exist so the user will see a generic user icon for their face. > After authentication, GDM will check if the user has a defined > face and copy it to the cached file. Also, on logout, GDM will > check again if the user has a defined face and copy it to the > cached file. Updating the cache on logout ensures the face image > will be available on next login if the user defined it during their > session. Obviously the face image will only be copied to the cache > if one is not already in the cache or if the cached file is older. In addition to the above, we will add a configuration option to GDM that will make it behave much like the old GDM where the default language/session choice is "Last Selected". When this configuration option is turned on, then GDM will copy the user's $HOME/.dmrc file into the cache after pam_setcred and just log into whatever session the user has defined there. This will be useful in Sun Ray environments where there is a cluster of servers and there is a desire to avoid the situation where the caches on different machines can get out-of-sync, and you really want to use whatever defaults the user has defined in their $HOME directory. > - Darren Moffat and Nicolas Williams say that the Face Browser should > not use any heuristics to determine if users should be displayed in > the Face Browser or not. For example, GDM should not assume that > only users in /etc/passwd with a valid shell should be included. > Darren Moffat further suggests that users must opt-in to be visible > in the Face Browser. Otherwise Darren feels there is a privacy issue. > > Proposed solution: > > This issue is partly solved by addressing the issue above, where > we move the user's face image to /var/cache/gdm. This will be managed by adding back the IncludeAll GDM configuration option. When IncludeAll is false, GDM will call ck-history and present only those users who have logged in previously. When IncludeAll is true, the existing fgetpwent() heuristics will be used. On Solaris, the default for IncludeAll will be false so that the heuristics are not used. However, users who want the heuristics can change the GDM configuration to make GDM work that way if desired. This is similar to how the old GDM worked with the IncludeAll configuration option. > In addition to that > solution, one of the two following approaches could be used to > address these concerns: > > 1) Only display users in the Face Browser which have an image file > specified. Though users with a UID < 100 would be filtered out > even if somebody put an image file in the cache. > 2) When users first login, create an empty file in > /var/cache/gdm/user-$uid/face, which would indicate to the Face > Browser to display any user who has logged in on this machine. > Again, aside from system users who have a UID < 100. > > Solution #1 better addresses Darren Moffat's preference that users > must opt-in to use the Face Browser. However, I personally think > solution #2 is more appropriate. The problem with solution #1 is > that it makes using the Face Browser more cumbersome. Other > operating systems use Face Browsers that "just work" and do not > require such configuration. To me it seems more appropriate to > simply turn off the Face Browser entirely in environments where > such privacy issues are a concern. The GDM co-maintainers did not like the above proposal. They disagreed strongly with the idea of including or excluding users based on whether they have a face image defined. Remember the face browser shows users who do not have a face image defined with a generic "face" image. Instead, they propose the following: Add back the GDM Include and Exclude configuration options so that the sysadmin can define which users should be included in the face browser even if they have not previously logged in and which users should be always excluded. This is how the old GDM also worked. Will this satisfy the opt-in/opt-out requirements? Or do we also need the ability for opt-out to be a user preference so that user's can opt-out of the face browser even if they do not have the authority to modify the GDM Include/Exclude configuration options? If so, can someone give a justification why users need the ability to do this? In my discussion with the upstream maintainers, we couldn't think of a use case where it makes sense to allow users to opt-out of the face browser. Each example we could think of seemed better managed by just having the sysadmin control this via the Include/Exclude configuration options. If this is needed, then we could add a new field to the $HOME/.dmrc file (e.g. ShowInFaceBrowser=true), which the user could change to false if they no longer wish to show up in the face browser. Thanks, Brian From Brian.Cameron@Sun.COM Tue Aug 18 15:59:49 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7IMxnDt015491 for ; Tue, 18 Aug 2009 15:59:49 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7IMxnL1008662 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 18 Aug 2009 15:59:49 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL00C09H7OI400@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 18 Aug 2009 15:59:48 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL002AYH7KZM60@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 18 Aug 2009 15:59:44 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7IMxhxF026919 for ; Tue, 18 Aug 2009 22:59:43 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOL00K00GSJE800@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 18 Aug 2009 16:59:43 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.213.24.197]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOL0060AH7JKVE0@mail-amer.sun.com>; Tue, 18 Aug 2009 16:59:43 -0600 (MDT) Date: Tue, 18 Aug 2009 18:00:08 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090818181529.GM1043@Sun.COM> Sender: Brian.Cameron@Sun.COM To: Nicolas Williams Cc: Brian Cameron , LSARC-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A8B3278.9070908@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <20090818181529.GM1043@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 6592 Nicolas: > On Mon, Aug 17, 2009 at 08:20:14PM -0500, Brian Cameron wrote: >> - Several people (Joerg Barfurth, Darren Moffat, Nicolas Williams) have >> highlighted that GDM should not touch the user's $HOME directory >> before the user authenticates. Currently GDM accesses the user's >> face image ($HOME/.face) and the user's session/language defaults >> ($HOME/.dmrc) before pam_setcred. Touching the user's $HOME >> directory before pam_setcred causes problems for kerberos, for >> example. >> >> Proposed solution: >> >> - The SUNWgnome-display-mgr-root package would install a directory >> /var/cache/gdm. > > What will be the permissions on this and the files in it? root:gdm 640 seems to make the most sense. >> [...] > > Looks good to me. > >> - Darren Moffat and Nicolas Williams say that the Face Browser should >> not use any heuristics to determine if users should be displayed in >> the Face Browser or not. For example, GDM should not assume that >> only users in /etc/passwd with a valid shell should be included. >> Darren Moffat further suggests that users must opt-in to be visible >> in the Face Browser. Otherwise Darren feels there is a privacy issue. >> >> Proposed solution: >> >> This issue is partly solved by addressing the issue above, where >> we move the user's face image to /var/cache/gdm. In addition to that >> solution, one of the two following approaches could be used to >> address these concerns: > > I'd even say that /var/cache/gdm is sufficient because the installer can > touch(1) the initial user's cached and $HOME/.face files, and so can the > Users and Groups and useradd(1M) utilities. That means that local users > will appear in the face browser, but with no local user heuristics. > > Opt-in can be a checkbox in the installer, Users and Groups, and > useradd(1M) utilities. But that's probably not necessary: just opt-in > all such users in the installer/useradd tools (no checkbox, just do it). > If users/admins don't like that they can disable the face browser > altogether. We can file enhancement requests against the installer, Users and Groups, and useradd(1M) projects to provide deeper integration with GDM if desired. In talking with the upstream GDM co-maintainers, they disagreed with the idea of the existance of the user's face image to control the user's opt-in/opt-out state. Instead they would prefer to add back the Include/Exclude options that the old GDM supported. I just sent a separate email where I go into more detail about this. But, this should not be a problem. As long as GDM exposes interfaces that the installer, Users and Groups, and useradd(1M) interfaces can use to configure GDM to show the right users in the Face Browser, this sort of deeper integration should be possible. >> 1) Only display users in the Face Browser which have an image file >> specified. Though users with a UID< 100 would be filtered out >> even if somebody put an image file in the cache. > > How would you determine (1) without looing in $HOME? GDM would look into $HOME after the user has passed pam_setcred and copy the face image from the $HOME directory into the cache. GDM will also copy the face image from the $HOME directory into the cache on logout. This way, if the user defines their face during the session, it will be copied into the cache for next login. This does mean that the user's face image won't show up in the face browser until the second login, when the image is in the cache. Instead the user will see the generic "face" image GDM uses when it can not determine the user's specific image file to use. On subsequent logins after the image file has moved to the cache, the user's defined image will appear properly in the Face Browser. In most situations, this would not be an issue since users would not have a face defined until after they login the first time. There are some situations where this wouldn't be true (like when the user has an NFS mounted $HOME directory), but not seeing their chosen image on first login shouldn't cause any real problems. > If root is not a role, then why not put root in the face browser? Currently the code filters out UID's under 100. If someone thinks it is important for GDM not to do this, then an ARC member will need to say it would otherwise be a TCR. >> 2) When users first login, create an empty file in >> /var/cache/gdm/user-$uid/face, which would indicate to the Face >> Browser to display any user who has logged in on this machine. >> Again, aside from system users who have a UID< 100. > > My comments to (1) apply here too. But also, one way to opt-out might > be to rm $HOME/.face, yet (2) would seemingly not allow that (since it > seems to clash with the idea that /var/cache/gdm/user-$uid/face is > updated at logout time to be a copy of $HOME/.face). The cache will be kept in sync. If the user removes their $HOME/.face, then the version in the cache would be removed and they would no longer see their image in the face browser. That said, in talking with the upstream GDM co-maintainers, we decided it would be better to manage opt-in/opt-out via adding back the Include/Exclude configuration options which were supported in the old GDM. Again, see my other email for more details on how this will work. >> - There are many concerns about the Face Browser and whether it should >> be turned on by default. >> >> - Glenn Faden suggested it not be the default because it is a >> potential security vulnerability to expose usernames before >> authentication. >> >> Proposed Solution: >> >> Turn off the Face Browser by default. This will make OpenSolaris >> different than everybody else, but our users love us because we are >> such curmudgeons about these things, I guess. > > IMO: > > This is an issue, but it's an installer issue, not really a GDM > issue. AI should almost certainly disable it by default, while the > OpenSolaris installer should probably enable it by default. To > force the matter GDM could have this feature disabled by default (a > "safe" default), such that the OpenSolaris installer project team > would have to do the enabling. It makes sense to me to file an enhancement request with the installer so that the user can select whether they want the Face Browser turned on or off by default. Or to just assume that if the user installs via the graphical installer that they wish to have it on seems fine with me. Brian From Nicolas.Williams@sun.com Tue Aug 18 16:17:09 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7INH8EH020709 for ; Tue, 18 Aug 2009 16:17:09 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7INH63i035903; Tue, 18 Aug 2009 17:17:08 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL00003I0J6G00@brm-avmta-1.central.sun.com>; Tue, 18 Aug 2009 17:17:07 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL00834I0JZA80@brm-avmta-1.central.sun.com>; Tue, 18 Aug 2009 17:17:07 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7IN6MWi003796; Tue, 18 Aug 2009 18:06:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7IN6MOO003795; Tue, 18 Aug 2009 18:06:22 -0500 (CDT) Date: Tue, 18 Aug 2009 18:06:22 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8B3278.9070908@sun.com> To: Brian Cameron Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090818230622.GX1043@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <20090818181529.GM1043@Sun.COM> <4A8B3278.9070908@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2236 On Tue, Aug 18, 2009 at 06:00:08PM -0500, Brian Cameron wrote: > [...] > But, this should not be a problem. As long as GDM exposes interfaces > that the installer, Users and Groups, and useradd(1M) interfaces can use to > configure GDM to show the right users in the Face Browser, this sort of > deeper integration should be possible. Exactly :) That's what I want to see. That approach lets you solve the $HOME access issue and avoid naughty local user heuristics. > >If root is not a role, then why not put root in the face browser? > > Currently the code filters out UID's under 100. If someone thinks it > is important for GDM not to do this, then an ARC member will need to > say it would otherwise be a TCR. I'm not an ARC member, and I don't care very much about seeing non-role root appear in the face browser. But that does make me wonder: should GDM not filter out roles from the face browser as a general rule? And if one wanted to do per-user opt-in then user_attr(4) seems like a good place to manage that. > That said, in talking with the upstream GDM co-maintainers, we decided > it would be better to manage opt-in/opt-out via adding back the > Include/Exclude configuration options which were supported in the old > GDM. Again, see my other email for more details on how this will work. As long as that's manageable, I don't mind. (See above comment about user_attr(4), in case that's more palatable to you.) > >IMO: > > > > This is an issue, but it's an installer issue, not really a GDM > > issue. AI should almost certainly disable it by default, while the > > OpenSolaris installer should probably enable it by default. To > > force the matter GDM could have this feature disabled by default (a > > "safe" default), such that the OpenSolaris installer project team > > would have to do the enabling. > > It makes sense to me to file an enhancement request with the installer so > that the user can select whether they want the Face Browser turned on or > off by default. Or to just assume that if the user installs via the > graphical installer that they wish to have it on seems fine with me. It also makes sense to kick this can to some other project team :) Nico -- From Nicolas.Williams@sun.com Tue Aug 18 16:21:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7INLblo020729 for ; Tue, 18 Aug 2009 16:21:37 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7INLRWR022516; Wed, 19 Aug 2009 00:21:35 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL00005I7XP700@brm-avmta-1.central.sun.com>; Tue, 18 Aug 2009 17:21:33 -0600 (MDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL008YHI7WZL60@brm-avmta-1.central.sun.com>; Tue, 18 Aug 2009 17:21:33 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7INAmtv003802; Tue, 18 Aug 2009 18:10:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7INAmAe003801; Tue, 18 Aug 2009 18:10:48 -0500 (CDT) Date: Tue, 18 Aug 2009 18:10:48 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8B2EDB.1000608@sun.com> To: Brian Cameron Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090818231048.GY1043@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <4A8B2EDB.1000608@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1267 On Tue, Aug 18, 2009 at 05:44:43PM -0500, Brian Cameron wrote: > The GDM co-maintainers did not like the above proposal. They > disagreed strongly with the idea of including or excluding users > based on whether they have a face image defined. Remember the > face browser shows users who do not have a face image defined with > a generic "face" image. > > Instead, they propose the following: > > Add back the GDM Include and Exclude configuration options so that > the sysadmin can define which users should be included in the face > browser even if they have not previously logged in and which users > should be always excluded. This is how the old GDM also worked. > Will this satisfy the opt-in/opt-out requirements? Provided that it is possible for the installer(s) and user add tools to edit the configuration, yes. If not then... no. BTW, the cache did have one nice side-effect: you could see recently logged in, not just opted-in users, in the face browser. > Or do we also need the ability for opt-out to be a user preference so > that user's can opt-out of the face browser even if they do not have > the authority to modify the GDM Include/Exclude configuration options? That'd be nice, but I don't think that should be a requirement. Nico -- From Brian.Cameron@sun.com Tue Aug 18 16:29:16 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7INTGTL020820 for ; Tue, 18 Aug 2009 16:29:16 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7INTFsw040784 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 18 Aug 2009 17:29:16 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL00109IKQGB00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 18 Aug 2009 17:29:14 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL0083TIKHZC80@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.COM); Tue, 18 Aug 2009 17:29:05 -0600 (MDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7INT5TF001714 for ; Tue, 18 Aug 2009 23:29:05 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOL00I00II24T00@mail-amer.sun.com> for LSARC-ext@Sun.COM (ORCPT LSARC-ext@Sun.COM); Tue, 18 Aug 2009 17:29:05 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.213.24.197]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOL00MDOIKG4060@mail-amer.sun.com>; Tue, 18 Aug 2009 17:29:04 -0600 (MDT) Date: Tue, 18 Aug 2009 18:29:29 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090818231048.GY1043@Sun.COM> Sender: Brian.Cameron@sun.com To: Nicolas Williams Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8B3959.20901@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <4A8B2EDB.1000608@sun.com> <20090818231048.GY1043@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1922 Nicolas: > On Tue, Aug 18, 2009 at 05:44:43PM -0500, Brian Cameron wrote: >> The GDM co-maintainers did not like the above proposal. They >> disagreed strongly with the idea of including or excluding users >> based on whether they have a face image defined. Remember the >> face browser shows users who do not have a face image defined with >> a generic "face" image. >> >> Instead, they propose the following: >> >> Add back the GDM Include and Exclude configuration options so that >> the sysadmin can define which users should be included in the face >> browser even if they have not previously logged in and which users >> should be always excluded. This is how the old GDM also worked. >> Will this satisfy the opt-in/opt-out requirements? > > Provided that it is possible for the installer(s) and user add tools to > edit the configuration, yes. If not then... no. If the installer runs as a user which can modify the GDM configuration file /etc/gdm/custom.conf with 644 root:sys permissions, then it can. I'd think the installer would be able to do this. In fact there was no reason that the installer couldn't have had this sort of integration with the old GDM 2.20, since it also supported a Face Browser. This isn't really a new GDM feature, though the Face Browser does work better in the new GDM. > BTW, the cache did have one nice side-effect: you could see recently > logged in, not just opted-in users, in the face browser. This would be the behavior if the new IncludeAll setting is false. In this case ck-history is used to get the list of recently logged in users to display. This would be the default setting on Solaris. If the setting is changed to true, then GDM will use the heuristics to add local users to the system. The Include/Exclude options will simply filter the output of ck-history so the users will still show up in recently logged in order when IncludeAll is false. Brian From Nicolas.Williams@sun.com Tue Aug 18 16:43:25 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7INhPOT021627 for ; Tue, 18 Aug 2009 16:43:25 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7INhKDc004643; Wed, 19 Aug 2009 00:43:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL00F07J8AP600@nwk-avmta-2.sfbay.sun.com>; Tue, 18 Aug 2009 16:43:22 -0700 (PDT) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL0026MJ89ZM80@nwk-avmta-2.sfbay.sun.com>; Tue, 18 Aug 2009 16:43:22 -0700 (PDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n7INWbG0003823; Tue, 18 Aug 2009 18:32:37 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n7INWbgO003822; Tue, 18 Aug 2009 18:32:37 -0500 (CDT) Date: Tue, 18 Aug 2009 18:32:37 -0500 From: Nicolas Williams Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8B3959.20901@sun.com> To: Brian Cameron Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <20090818233237.GZ1043@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <4A8B2EDB.1000608@sun.com> <20090818231048.GY1043@Sun.COM> <4A8B3959.20901@sun.com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1350 On Tue, Aug 18, 2009 at 06:29:29PM -0500, Brian Cameron wrote: > >Provided that it is possible for the installer(s) and user add tools to > >edit the configuration, yes. If not then... no. > > If the installer runs as a user which can modify the GDM configuration > file /etc/gdm/custom.conf with 644 root:sys permissions, then it can. > I'd think the installer would be able to do this. That's fine. What I meant was: can the installer import that interface? And the answer is almost certainly yes. (For the user add tools there's also the question of locking around edits of /etc/gdm/custom.conf.) > >BTW, the cache did have one nice side-effect: you could see recently > >logged in, not just opted-in users, in the face browser. > > This would be the behavior if the new IncludeAll setting is false. In > this case ck-history is used to get the list of recently logged in > users to display. This would be the default setting on Solaris. If > the setting is changed to true, then GDM will use the heuristics to > add local users to the system. I like the first part and not the second, but I'll live. > The Include/Exclude options will simply filter the output of ck-history > so the users will still show up in recently logged in order when IncludeAll > is false. Awesome. Thanks. My concerns are all addressed. Thanks, Nico -- From Brian.Cameron@sun.com Tue Aug 18 22:44:38 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7J5icpA004009 for ; Tue, 18 Aug 2009 22:44:38 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7J5ic1c014213 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Tue, 18 Aug 2009 22:44:38 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOL00J03ZYEGP00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 18 Aug 2009 22:44:38 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOL0080OZYDE180@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 18 Aug 2009 22:44:37 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7J5ibdh017552 for ; Wed, 19 Aug 2009 05:44:37 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOL00H00ZXDPX00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Tue, 18 Aug 2009 23:44:37 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.213.24.197]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOL00JNOZYC6780@mail-amer.sun.com>; Tue, 18 Aug 2009 23:44:37 -0600 (MDT) Date: Wed, 19 Aug 2009 00:45:02 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090818233237.GZ1043@Sun.COM> Sender: Brian.Cameron@sun.com To: Nicolas Williams Cc: Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8B915E.3020706@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <4A8B2EDB.1000608@sun.com> <20090818231048.GY1043@Sun.COM> <4A8B3959.20901@sun.com> <20090818233237.GZ1043@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 1829 Nicolas: > On Tue, Aug 18, 2009 at 06:29:29PM -0500, Brian Cameron wrote: >>> Provided that it is possible for the installer(s) and user add tools to >>> edit the configuration, yes. If not then... no. >> >> If the installer runs as a user which can modify the GDM configuration >> file /etc/gdm/custom.conf with 644 root:sys permissions, then it can. >> I'd think the installer would be able to do this. > > That's fine. What I meant was: can the installer import that interface? > And the answer is almost certainly yes. (For the user add tools there's > also the question of locking around edits of /etc/gdm/custom.conf.) The configuration file is in standard INI format. The GDM code uses the glib gkeyfile() interfaces to read it and write to it. The INI format is pretty simple so you would not need to use the glib functions to access the file if you did not want to. Though, probably a better way to update configuration options will be introduced when the gdmsetup program is added back to GDM. This work is currently being done by Canonical and will likely make it into GDM in the 2.30 timeframe. http://bugzilla.gnome.org/show_bug.cgi?id=587750 Note that when this is integrated that it will add new D-Bus interfaces for modifying GDM configuration, so that programs like the installer can make D-Bus calls to tell the GDM daemon to tell it to update the configuration file. The GDM daemon can be expected to manage such updates in a safe way so that you do not need to worry about locking the file when making changes. And it would be cool to make D-Bus a dependency of useradd, no? Note that the patches in the above bug use PolicyKit to ensure that only users with authority can edit the GDM configuration. When we port this to Solaris, we will obviously need to make it use RBAC instead. Brian From Darren.Moffat@sun.com Wed Aug 19 02:09:02 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7J9918F015818 for ; Wed, 19 Aug 2009 02:09:02 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7J98tj3009587 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 19 Aug 2009 10:09:00 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOM00E019EZX800@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 02:08:59 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOM00G4T9EX8WB0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 02:08:58 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7J98v5F026779 for ; Wed, 19 Aug 2009 09:08:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOM0090099HQR00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 10:08:38 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOM003Y29DWH4C0@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 10:08:20 +0100 (BST) Date: Wed, 19 Aug 2009 10:08:20 +0100 From: Darren J Moffat Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8B2EDB.1000608@sun.com> Sender: Darren.Moffat@sun.com To: Brian Cameron Cc: LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8BC104.4040001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <4A8B2EDB.1000608@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 2218 Brian Cameron wrote: > The GDM co-maintainers did not like the above proposal. They > disagreed strongly with the idea of including or excluding users > based on whether they have a face image defined. Remember the > face browser shows users who do not have a face image defined with > a generic "face" image. > > Instead, they propose the following: > > Add back the GDM Include and Exclude configuration options so that > the sysadmin can define which users should be included in the face > browser even if they have not previously logged in and which users > should be always excluded. This is how the old GDM also worked. > Will this satisfy the opt-in/opt-out requirements? > > Or do we also need the ability for opt-out to be a user preference so > that user's can opt-out of the face browser even if they do not have > the authority to modify the GDM Include/Exclude configuration options? > If so, can someone give a justification why users need the ability to > do this? That would be nice but I think doing at least what the old GDM did would be better than the all or nothing situation that was originally proposed. > In my discussion with the upstream maintainers, we couldn't think of a use > case where it makes sense to allow users to opt-out of the face browser. > Each example we could think of seemed better managed by just having the > sysadmin control this via the Include/Exclude configuration options. What about because it is users personal wish not to have even their real name shown up because the systems are in a public area - even if the host admin has not disabled the face browser ? Consider Sun Rays in drop in centres. Remember that this information is going to be visible to anyone walking past the machine without them being a valid user. I'm happy enough with the proposal to bring back the admin level control. > If this is needed, then we could add a new field to the $HOME/.dmrc file > (e.g. ShowInFaceBrowser=true), which the user could change to false if they > no longer wish to show up in the face browser. That would be be very nice, but isn't dmrc a file controlled by a freedesktop.org spec ? Or is that just the .desktop files ? -- Darren J Moffat From Darren.Moffat@Sun.COM Wed Aug 19 02:09:53 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7J99r6t015835 for ; Wed, 19 Aug 2009 02:09:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7J99rJj011913 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 19 Aug 2009 02:09:53 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOM00F0B9GF1800@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 02:09:51 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOM00G7X9GE8WB0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 02:09:51 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7J99nno004464 for ; Wed, 19 Aug 2009 09:09:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOM00E008WRQ300@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 10:09:40 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOM0030P9FXH4D0@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 10:09:34 +0100 (BST) Date: Wed, 19 Aug 2009 10:09:33 +0100 From: Darren J Moffat Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <20090818230622.GX1043@Sun.COM> Sender: Darren.Moffat@Sun.COM To: Nicolas Williams Cc: Brian Cameron , LSARC-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A8BC14D.4000903@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <20090818181529.GM1043@Sun.COM> <4A8B3278.9070908@sun.com> <20090818230622.GX1043@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 1534 Nicolas Williams wrote: > On Tue, Aug 18, 2009 at 06:00:08PM -0500, Brian Cameron wrote: >> [...] >> But, this should not be a problem. As long as GDM exposes interfaces >> that the installer, Users and Groups, and useradd(1M) interfaces can use to >> configure GDM to show the right users in the Face Browser, this sort of >> deeper integration should be possible. > > Exactly :) > > That's what I want to see. That approach lets you solve the $HOME > access issue and avoid naughty local user heuristics. > >>> If root is not a role, then why not put root in the face browser? >> Currently the code filters out UID's under 100. If someone thinks it >> is important for GDM not to do this, then an ARC member will need to >> say it would otherwise be a TCR. > > I'm not an ARC member, and I don't care very much about seeing non-role > root appear in the face browser. But that does make me wonder: should > GDM not filter out roles from the face browser as a general rule? Yes it probably should, since they won't be able to login. However given they won't be able to login they shouldn't be appearing there anyway. Note that customer defined roles won't have UID < 100 but the existing (and future) Solaris defined ones will. > And if one wanted to do per-user opt-in then user_attr(4) seems like a > good place to manage that. It would be but that is Solaris specific, I think having a non Solaris specific method to control wither or not a user is shown in the face browser would be useful. -- Darren J Moffat From Joerg.Barfurth@sun.com Wed Aug 19 02:52:27 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7J9qQBI016652 for ; Wed, 19 Aug 2009 02:52:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7J9qLtC000107 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Wed, 19 Aug 2009 17:52:25 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOM0000ZBFCAQ00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 03:52:24 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOM00AKDBFBCL90@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 03:52:24 -0600 (MDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7J9qNQw005238 for ; Wed, 19 Aug 2009 09:52:23 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOM00600AQECV00@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 10:52:01 +0100 (BST) Received: from [10.16.66.63] ([unknown] [10.16.66.63]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOM003U3BEOLR70@fe-emea-09.sun.com>; Wed, 19 Aug 2009 10:52:00 +0100 (BST) Date: Wed, 19 Aug 2009 11:52:00 +0200 From: Joerg Barfurth Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8B3278.9070908@sun.com> Sender: Joerg.Barfurth@sun.com To: Brian Cameron Cc: Nicolas Williams , Brian Cameron , LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8BCB40.2090209@sun.com> Organization: Sun Microsystem - Desktop MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <20090818181529.GM1043@Sun.COM> <4A8B3278.9070908@sun.com> User-Agent: Thunderbird 2.0.0.17 (X11/20081014) Status: RO Content-Length: 1282 Brian Cameron schrieb: >> Opt-in can be a checkbox in the installer, Users and Groups, and >> useradd(1M) utilities. But that's probably not necessary: just opt-in >> all such users in the installer/useradd tools (no checkbox, just do it). >> If users/admins don't like that they can disable the face browser >> altogether. > > We can file enhancement requests against the installer, Users and > Groups, and > useradd(1M) projects to provide deeper integration with GDM if desired. > While that is not this case, I don't think it is a good idea to have useradd opt-in users by default: - Any user account that is actually used for interactive login will be 'opted-in' anyhow by the history feature. - The face browser may not be able to identify locked accounts easily: - the face browser won't be able to read shadow - these accounts may still need to have valid shells An example of accounts that should not show up are kiosk accounts. - Jörg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth@sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/ From Brian.Cameron@sun.com Wed Aug 19 12:20:21 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7JJKKLW022605 for ; Wed, 19 Aug 2009 12:20:21 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7JJKHFf004432 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 20 Aug 2009 03:20:19 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KON004031PUEH00@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 12:20:18 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KON002Q61PTTC80@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 12:20:17 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7JJKHEZ011903 for ; Wed, 19 Aug 2009 19:20:17 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KON00K001FAJZ00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 13:20:17 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.213.24.197]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KON00HAP1PQUY40@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Wed, 19 Aug 2009 13:20:15 -0600 (MDT) Date: Wed, 19 Aug 2009 14:20:39 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8BC104.4040001@Sun.COM> Sender: Brian.Cameron@sun.com To: Darren J Moffat Cc: LSARC-ext@sun.com, desktop-discuss@opensolaris.org Message-id: <4A8C5087.20100@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <4A8B2EDB.1000608@sun.com> <4A8BC104.4040001@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 3943 Darren: On 08/19/09 04:08, Darren J Moffat wrote: > Brian Cameron wrote: >> The GDM co-maintainers did not like the above proposal. They >> disagreed strongly with the idea of including or excluding users >> based on whether they have a face image defined. Remember the >> face browser shows users who do not have a face image defined with >> a generic "face" image. >> >> Instead, they propose the following: >> >> Add back the GDM Include and Exclude configuration options so that >> the sysadmin can define which users should be included in the face >> browser even if they have not previously logged in and which users >> should be always excluded. This is how the old GDM also worked. >> Will this satisfy the opt-in/opt-out requirements? >> >> Or do we also need the ability for opt-out to be a user preference so >> that user's can opt-out of the face browser even if they do not have >> the authority to modify the GDM Include/Exclude configuration options? >> If so, can someone give a justification why users need the ability to >> do this? > > That would be nice but I think doing at least what the old GDM did would > be better than the all or nothing situation that was originally proposed. Right. >> In my discussion with the upstream maintainers, we couldn't think of a >> use >> case where it makes sense to allow users to opt-out of the face browser. >> Each example we could think of seemed better managed by just having the >> sysadmin control this via the Include/Exclude configuration options. > > What about because it is users personal wish not to have even their real > name shown up because the systems are in a public area - even if the > host admin has not disabled the face browser ? Consider Sun Rays in drop > in centres. > > Remember that this information is going to be visible to anyone walking > past the machine without them being a valid user. I am not sure that is the best example. Would you want a Face Browser in that sort of drop-in center to begin with? The Face Browser is more clearly designed for systems where the same users will tend to login. The Face Browser would be cumbersome to use in environments where the users will vary greatly. Further, since Sun Rays use Smart Cards and NSCM, I do not think the typical Sun Ray installation would want to ever enable the Face Browser since it is not designed to work with smart card PAM stacks. Instead users would typically use their Smart Card to self-identify. If we can think of better examples, that would help to encourage adding this sort of feature. I will discuss this with the upstream community and file a bug so the issue can be further considered. That said, I intend to only add the Include, Exclude, and IncludeAll configuration options with the initial GDM rewrite integration. These are non-controversial with upstream. > I'm happy enough with the proposal to bring back the admin level control. Thanks. >> If this is needed, then we could add a new field to the $HOME/.dmrc file >> (e.g. ShowInFaceBrowser=true), which the user could change to false if >> they >> no longer wish to show up in the face browser. > > That would be be very nice, but isn't dmrc a file controlled by a > freedesktop.org spec ? Or is that just the .desktop files ? The dmrc file is shared between GNOME and KDE, but there is no reason why it could not support a GDM specific extension. KDM could also adopt it if it is useful to them. Though, as you suggest, such an opt-out mechanism could probably be implemented in different ways. So, it is probably best to file a bug with upstream and let the community consider whether this is a feature that should be added and the best way to address this. If the dmrc file is the best way, then we should discuss and coordinate with the KDM project. It is probably not a good idea to rush ahead and try to implement this sort of new interface at the end of the 2.28 release cycle. Brian From Brian.Cameron@sun.com Wed Aug 19 16:51:00 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7JNoxGi010718 for ; Wed, 19 Aug 2009 16:50:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7JNouad013639 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 20 Aug 2009 07:50:58 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KON00H0DE8W6K00@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Wed, 19 Aug 2009 17:50:56 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KON009NOE8VR740@brm-avmta-1.central.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Wed, 19 Aug 2009 17:50:55 -0600 (MDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7JNotxG019074 for ; Wed, 19 Aug 2009 23:50:55 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KON00E00E5FVL00@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Wed, 19 Aug 2009 17:50:55 -0600 (MDT) Received: from [192.168.1.67] ([unknown] [69.213.24.197]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KON0012ME8UQCC0@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Wed, 19 Aug 2009 17:50:55 -0600 (MDT) Date: Wed, 19 Aug 2009 18:51:20 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] Sender: Brian.Cameron@sun.com To: LSARC-ext@sun.com Cc: Desktop Discuss Message-id: <4A8C8FF8.7030505@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 9299 This case is set to time-out tomorrow as a FastTrack. If there are no issues raised, then it will be approved as a fasttrack. If people think there are any remaining issues that require further discussion, then I have made arrangements for this case to be converted to a full-case and we can have the inception review next Tuesday. Here is an update of the issues raised and the proposed solutions. This is updated to reflect the discussion since I last sent out a similar update on the 17th. Assuming the case closes tomorrow, then I will update the case materials with the following proposed changes before closing it. What do people think? Issues discussed & proposed solutions: - Although nobody has raised this issue, I feel obligated to remind people of the issue discussed in section 4.1.14. The last time that GDM proposed to be the default login program (LSARC 2005/417), it was derailed because GDM lacks a "drop to console" feature like CDE login has. When graphical VT support is integrated in build 122, it will be possible for people to use VT switching to drop to console. However, in my recent discussions with the VT team, they plan to not enable the vtdaemon service by default until a later build. There are still some remaining bugs with vtdaemon which are unlikely to be fixed by the time that this case integrates. It is not yet clear when these issues will be resolved and which build the service will be enabled by default. Once the vtdaemon is enabled by default, or if the user enables it, then GDM will work with graphical VT. So, in the meantime, users who need a drop to console feature will need to enable the vtdaemon service to use this. Since users have lived without a "drop to console" feature in OpenSolaris from day one, this case does not make the situation any worse. - Several people (Joerg Barfurth, Darren Moffat, Nicolas Williams) have highlighted that GDM should not touch the user's $HOME directory before the user authenticates. Currently GDM accesses the user's face image ($HOME/.face) and the user's session/language defaults ($HOME/.dmrc) before pam_setcred. Touching the user's $HOME directory before pam_setcred causes problems for kerberos, for example. Proposed solution: - The SUNWgnome-display-mgr-root package would install a directory /var/cache/gdm. This directory will be owned by root:gdm with 640 permissions. - At run-time GDM would create a directory /var/cache/gdm/user-$uid when a user logs in, if the directory does not already exist. In this directory will be placed two files: dmrc and face. - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then GDM will log the user into the default session/language or whichever ones they selected in the GUI. Then it will save the dmrc file to the cache with the default settings. On next login, the defaults will be read from the cache. - On first login the /var/cache/gdm/user-$uid/face file will not exist so the user will see a generic user icon for their face. After authentication, GDM will check if the user has a defined face and copy it to the cached file. Also, on logout, GDM will check again if the user has a defined face and copy it to the cached file. Updating the cache on logout ensures the face image will be available on next login if the user defined it during their session. Obviously the face image will only be copied to the cache if one is not already in the cache or if the cached file is older. - A configuration option will be added to GDM that will make it behave much like the old GDM where the default language/session choice is "Last Selected". When this configuration option is turned on, then GDM will copy the user's $HOME/.dmrc file into the cache after pam_setcred and just log into whatever session the user has defined there. This will be useful in Sun Ray environments where there is a cluster of servers and there is a desire to avoid the situation where the caches on different machines can get out-of-sync, and you really want to use whatever defaults the user has defined in their $HOME directory. - Darren Moffat and Nicolas Williams say that the Face Browser should not use any heuristics to determine if users should be displayed in the Face Browser or not. For example, GDM should not assume that only users in /etc/passwd with a valid shell should be included. Darren Moffat further suggests that users must opt-in to be visible in the Face Browser. Otherwise Darren feels there is a privacy issue. Proposed solution: To support this, the IncludeAll configuration option from the old GDM will be added back. When IncludeAll is false, GDM will call ck-history and present only those users who have logged in previously. When IncludeAll is true, the existing fgetpwent() heuristics will be used. On Solaris, the default for IncludeAll will be false so that the heuristics are not used. However, users who want the heuristics can change the GDM configuration to make GDM work that way if desired. To support opt-in/opt-out, the Include and Exclude configuration options from the old GDM will also be added back. These contain lists of users separated by commas. With these, the sysadmin can define which users should be included in the face browser even if they have not previously logged in and which users should be always excluded. - There are many concerns about the Face Browser and whether it should be turned on by default. - Glenn Faden suggested it not be the default because it is a potential security vulnerability to expose usernames before authentication. Proposed Solution: Turn off the Face Browser by default. This will make OpenSolaris different than everybody else, but our users love us because we are such curmudgeons about these things, I guess. - Joerg Barfurth highlighted that Sun Ray kiosk mode needs the greeter to not display when the PAM stack requires no user interaction. GDM provides an Automatic Login feature which works mostly as desired. However, some work will be needed to make it work as needed by Sun Ray. The new GDM only allows you to hardcode a single username to work with AutomaticLogin, while Sun Ray needs the ability to specify this username per-display. Proposed Solution: The old GDM had a feature where you could specify the username as a script which is passed the DISPLAY environment variable and which returns the username to be used with AutomaticLogin. Adding back this feature should provide Sun Ray kiosk mode with the feature they need. - Joerg Barfurth highlighted that since the "gdm" user only has a single GConf directory that any configuration change on one seat will affect all the others. For example, if you turn on a greeter accessibility feature on one seat, then that feature will turn on for all displays that are showing the greeter. Proposed Solution: Make use of the new GCONF_DEFAULT_SOURCE_PATH environment variable so that each seat can specify its own GConf settings directory. Then the settings would be sticky per-seat, which would likely be reasonable. Other issues which were discussed, which I think were addressed in the email discussion, include: - Alan Coopersmith raised the issue that we need a follow-up case to EOL CDE Login. Lin Ma from the Sun Desktop team has agreed to be responsible for this follow-up case. Alan Coopersmith is travelling to Beijing soon and will assist Lin with preparing this. - Glenn Faden had a concern that the "Shutdown" and "Reboot" buttons should not appear in the GDM login GUI by default. This is not a problem since they only appear if the "gdm" user has the solaris.system.shutdown authority, which it does not have by default. - Darren Moffat suggested that we offer an xterm.desktop file so that users can have access to a terminal session. The project team agreed and has already integrated this into our GDM development build. - Joerg Barfurth highlighted that the new GDM does not provide a true "failsafe session". While the xterm.desktop does allow people to login without starting the full GNOME stack, it does source the user's .profile, etc. So, if the user needs to fix an error in this sort of configuration file, then they would need to use some other mechanism, such as VT switching to the console. - Nicolas Williams wanted clarification that the session should be started by the process that did the PAM and audit work, or by its progeny, after pam_open_session(3PAM) is called, and before pam_close_session(3PAM) is called. I verified that this is the case. - Nicolas Williams wanted verification that Xserver a11y is available when GDM is used. I verified that it is available. - Also note the regressions in section 4.1.15. I do not think these are cause for much concern, nor have they generated much discussion but I recommend that people look over them if they have not already. --- Brian From Darren.Moffat@Sun.COM Thu Aug 20 01:25:12 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7K8PCvc001496 for ; Thu, 20 Aug 2009 01:25:12 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n7K8PCJi030794 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Thu, 20 Aug 2009 02:25:12 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOO00H0J21Y5700@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 20 Aug 2009 01:25:10 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOO0045021WVHC0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 20 Aug 2009 01:25:09 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n7K8P7pW011329 for ; Thu, 20 Aug 2009 08:25:08 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOO0020012AV800@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 20 Aug 2009 09:24:43 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOO007YO215Y8A0@fe-emea-09.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Thu, 20 Aug 2009 09:24:41 +0100 (BST) Date: Thu, 20 Aug 2009 09:24:41 +0100 From: Darren J Moffat Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8C5087.20100@sun.com> Sender: Darren.Moffat@Sun.COM To: Brian Cameron Cc: LSARC-ext@Sun.COM, desktop-discuss@opensolaris.org Message-id: <4A8D0849.9030403@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200908112121.n7BLLVai025358@sac.sfbay.sun.com> <4A8A01CE.5070708@sun.com> <4A8B2EDB.1000608@sun.com> <4A8BC104.4040001@Sun.COM> <4A8C5087.20100@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090623) Status: RO Content-Length: 923 Brian Cameron wrote: > The dmrc file is shared between GNOME and KDE, but there is no reason > why it could not support a GDM specific extension. KDM could also adopt > it if it is useful to them. Though, as you suggest, such an opt-out > mechanism could probably be implemented in different ways. So, it is > probably best to file a bug with upstream and let the community > consider whether this is a feature that should be added and the best > way to address this. If the dmrc file is the best way, then we > should discuss and coordinate with the KDM project. It is probably > not a good idea to rush ahead and try to implement this sort of new > interface at the end of the 2.28 release cycle. Agreed compeltely, if KDM doesn't agree then I don't think doing this in dmrc is a good idea. I believe my issues have all been addressed now and I'm happy with the updates that have been made. -- Darren J Moffat From Brian.Cameron@sun.com Fri Aug 21 11:32:42 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7LIWfPC008245 for ; Fri, 21 Aug 2009 11:32:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n7LIWSa4009140 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 21 Aug 2009 19:32:40 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOQ00A0LOUF4F00@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Fri, 21 Aug 2009 11:32:39 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOQ00H9MOUENLC0@nwk-avmta-1.sfbay.Sun.COM> for LSARC-ext@sun.com (ORCPT LSARC-ext@Sun.Com); Fri, 21 Aug 2009 11:32:39 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n7LIWcGB001773 for ; Fri, 21 Aug 2009 18:32:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KOQ00300O9V1100@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Fri, 21 Aug 2009 12:32:38 -0600 (MDT) Received: from [129.153.250.167] ([unknown] [129.153.250.167]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KOQ002Z7OUD9640@mail-amer.sun.com> for LSARC-ext@Sun.Com (ORCPT LSARC-ext@Sun.Com); Fri, 21 Aug 2009 12:32:38 -0600 (MDT) Date: Fri, 21 Aug 2009 13:33:04 -0500 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8C8FF8.7030505@sun.com> Sender: Brian.Cameron@sun.com To: Brian Cameron Cc: LSARC-ext@sun.com, Desktop Discuss Message-id: <4A8EE860.60303@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_pEgNxLKTVNvwY6jlBJurwA)" X-PMX-Version: 5.4.1.325704 References: <4A8C8FF8.7030505@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.1) Gecko/20090804 Thunderbird/3.0b3 Status: RO Content-Length: 31082 This is a multi-part message in MIME format. --Boundary_(ID_pEgNxLKTVNvwY6jlBJurwA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT The timeout for this case has passed, and no further unresolved issues were raised. I have marked the case as "closed approved" I have attached a diff file which shows all the differences to the onepager since it was first submitted, which reflects the discussion and agreements made in this review. Brian --Boundary_(ID_pEgNxLKTVNvwY6jlBJurwA) Content-type: text/plain; name=gdm.diff Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=gdm.diff --- onepager-gdm-rewrite-old.txt 2009-08-21 13:29:07.094674000 -0500 +++ onepager-gdm-rewrite.txt 2009-08-21 13:28:15.399223000 -0500 @@ -48,18 +48,23 @@ ConsoleKit will be integrated into Solaris with the new GDM rewrite. The Desktop team intends to integrate GDM 2.28 into Solaris. - Today, Solaris does not support graphical VT sessions. However, - the virtual console team is currently targeting build 124 to add - this feature. Refer to PSARC 2006/591 Virtual Console. VT support - is not needed to use GDM, but GDM will support it as soon as it is - available. + Today, Solaris does not support graphical VT sessions. The virtual + console team is currently targeting build 122 to add VT support for the + Xserver. It is unclear when the "vtdaemon" service will be enabled by + default on Solaris, but after build 122 systems can be easily + configured to enable the "vtdaemon" SMF service if there is a wish to + use graphical VT sessions. + + Refer to PSARC 2006/591 Virtual Console and PSRAC 2008/515 Virtual + Console Update. VT support is not needed to use GDM, but GDM will + support it as soon as it is available. 4. Technical Description: 4.1. Details: The GDM rewrite provides a login experience that is similar to the gdmlogin GUI provided by the older GDM. The usability has been much - improved with a more usable face browser and a panel which displays a + improved with a more usable Face Browser and a panel which displays a number of new options. GDM uses the GTK+ widget set and supports accessibility. @@ -84,21 +89,26 @@ for shutting down and restarting the machine. Refer to section 4.1.9 for more information. - 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 + The user can select the username from the Face Browser list and 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. 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. + interface. If the user starts typing, it will automatically scroll down + to the users that match that search prefix. The Face Browser also + 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), or to login as a NIS/LDAP user. 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. + + If GDM is configured to not display the Face Browser, then the user + must click a "Log In" button on the GUI to start the PAM conversation + and enter the username and password. Once the user has entered their username, or selected it via the - face browser, the panel shows interfaces for selecting the session to + Face Browser, the panel shows interfaces for selecting the session to log into and 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 @@ -106,7 +116,7 @@ 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. + default value for that user in subsequent logins. The new GDM also makes use of the GNOME infrastructure by using gnome-session, the gnome-settings-daemon, and the metacity window @@ -156,7 +166,8 @@ 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. + with ConsoleKit, this will be removed. New users should use the + new ck-seat-tool program. - /usr/bin/gdmflexiserver [--version] [--debug] @@ -207,6 +218,9 @@ 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. + The gdm-session-worker process also launches the /etc/gdm/Xsession + script after successful login, which starts the user session (e.g. + gnome-session for a GNOME user session). - /usr/lib/gdm-simple-greeter @@ -216,10 +230,10 @@ - /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 while gdm-host-chooser is an - application which can be launched with the user runs the Xserver with - the -indirect flag. + The XDMCP chooser GUI program. gdm-simple-chooser is intended to be + launched from the login GUI 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 @@ -227,15 +241,35 @@ 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. + this feature may not be useful with some PAM stacks. For example, + it would not be useful with a fingerprint reader PAM stack which + would not need username entry. This, and other files associated with this applet will only be - delivered after VT integrates into Solaris. Such other files + delivered after VT fully integrates into Solaris. Such other files include: - /usr/share/gnome-2.0/ui/GNOME_FastUserSwitchApplet.xml - /usr/lib/bonobo/servers/GNOME_FastUserSwitchApplet.server + Session migration works as follows. When you switch to another VT + when you have an existing user session running, then the screenlock + program is automatically launched so that the VT you just switched + away from will be locked. If the user switches back to it, then they + need to re-authenticate with the lockscreen program to get back into + their session. + + If the user switches to a VT where there is not an existing user + session running, then the user will be presented with the GDM login + program. If the user tries to log into a user who already has a + session running, then migration is done. + + GDM will do a chvt() call on the Xserver running the existing + session. This switches the current active VT to where the user's + session is running. In this case it will also unlock the screensaver + since the user doesn't need to re-authenticate after logging in via + the GDM greeter. + - /usr/lib/gdm-xdmcp-chooser-slave The slave to be used when a user is running the XDMCP chooser. @@ -287,17 +321,22 @@ - 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. + key is set for the "gdm" user, then GOK will be autolaunched. - 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. + is set for the "gdm" user, then orca will be autolaunched. 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. + Also note that GDM has a bug that all GDM login GUI's share the same + GConf settings, so that changing a setting (such as enabling an a11y + feature) will affect logins on all systems. Until this bug is fixed, + it is best to disable GDM a11y in multi-user environments. + 4.1.3 Detail About GDM Server Configuration The GDM rewrite uses different configuration mechanisms than the old @@ -323,7 +362,15 @@ daemon/AutomaticLoginEnable - Set to "true" or "false". If true, then Automatic login is enabled. The value is "false" by default. - daemon/AutomaticLogin - Set to automatic login user. + daemon/AutomaticLogin - Set to automatic login user. This can + be set to a script with the syntax + "|scriptname". If the script returns a + valid user, this will be used as the + user, otherwise AutomaticLogin will be + considered off for this display. The + script is passed $DISPLAY so that the + username can be specified differently in + a per-display manner. daemon/TimedLoginEnable - Set to "true" or "false". If true, then Timed login is enabled. The value is "false" by default. @@ -425,13 +472,15 @@ Boolean value. Controls whether to show the restart and shutdown buttons in the login window. Even if true, GDM checks to see if the "gdm" user (or the user specified in the daemon/User - configuration option) has RBAC privileges for - solaris.system.shutdown. If not, the buttons are not displayed - regardless of this configuration setting. Default value is false. + configuration option) has authorization for the + solaris.system.shutdown key (the system default is that the "gdm" + user does not have such authorization). If not, the buttons are not + displayed regardless of this configuration setting. Default value is + false. - /apps/gdm/simple-greeter/disable_user_list - Boolean value. If true, then the face browser with known users is + Boolean value. If true, then the Face Browser with known users is not shown. In this case, normal PAM prompting is used. - /apps/gdm/simple-greeter/logo_icon_name @@ -474,7 +523,51 @@ Boolean value. If true, compiz is used as the window manager instead of metacity. Default is false. - + + - /apps/gdm/simple-greeter/show_last + + Boolean value. If true, then the language and session choices + will default to "Last Selected", and GDM will use whatever choices + are defined in the user's $HOME/.dmrc file, which will be accessed + after pam_setcred has comleted. Refer to the description of how + /var/cache/gdm works in section 4.1.6 for more information. Default + is false. + + - /apps/gdm/simple-greeter/include_all + + Boolean value. If true, then GDM will use heuristics to determine + which users to display in the Face Browser. In this case, it will + call fgetpwent(3C) to get the list of local users and to avoid + accessing users via nsswitch.conf). The Face Browser also will + display any users that have previously logged in on the system (for + example NIS/LDAP users). It gets this list via calling the + ck-history ConsoleKit interface. It will also filter out any users + which do not have a valid shell (valid shells are any shell that + getusershell() returns. /sbin/nologin or /bin/false are considered + invalid shells even if getusershell() returns them), + + If false, then GDM more simply only displays users that have + previously logged in on the system (local or NIS/LDAP users) by + calling the ck-history ConsoleKit interface. + + In both cases, GDM filters out any users with a UID less than 100 + and which are in the following list: bin, root, daemon, adm, lp, + sync, shutdown, halt, mail, news, uucp, operator, nobody, nobody4, + noaccess, GDM_USERNAME (normally the "gdm" user), postgres, pvm, rpm, + nfsnobody, pcap. + + - /apps/gdm/simple-greeter/include + + String value. This can be set to a list of usernames separated by + commas. Any valid username is automatically added to the Face + Browser, regardless of the above include_all setting. + + - /apps/gdm/simple-greeter/exclude + + String value. This can be set to a list of usernames separated by + commas. Any valid username is automatically filtered out of the Face + Browser, regardless of the include_all or include settings. + 4.1.5 Detail About GDM Script Interfaces GDM supports the following script interfaces @@ -530,12 +623,19 @@ does not bother to show the user a dialog to select the session and assumes to start the only available session. + GDM delivers a /usr/share/xsessions/xterm.desktop to allow users + to log into an xterm window, much like the Failsafe option in the + older GDM. + + - /var/cache/gdm - $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. + - $HOME/.face + + The $HOME/.dmrc 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: @@ -544,6 +644,47 @@ Session=gnome Language=cs_CZ.UTF-8 + The $HOME/.face file contains the user's default image to be used + in the face browser. + + So that GDM does not access the user's $HOME directory before + pam_setcred, the above $HOME/.dmrc and $HOME/.face files are + accessed via a cache in /var/cache/gdm. It is necessary for GDM + to not access the $HOME directory before pam_setcred because this + causes problems for certain configurations, such as kerberos. The + cache works as follows: + + - The SUNWgnome-display-mgr-root package would install a directory + /var/cache/gdm. This directory will be owned by root:gdm with + 640 permissions. + - At run-time GDM would create a directory /var/cache/gdm/user-$uid + when a user logs in, if the directory does not already exist. In + this directory will be placed two files: dmrc and face. + - If the /var/cache/gdm/user-$uid/dmrc file does not exist, then GDM + will log the user into the default session/language or whichever + ones they selected in the GUI. Then it will save the dmrc file to + the cache with the default settings. On next login, the defaults + will be read from the cache. + - On first login the /var/cache/gdm/user-$uid/face file will not + exist so the user will see a generic user icon for their face. + After authentication, GDM will check if the user has a defined face + and copy it to the cached file. Also, on logout, GDM will check + again if the user has a defined face and copy it to the cached + file. Updating the cache on logout ensures the face image will be + available on next login if the user defined it during their + session. Obviously the face image will only be copied to the cache + if one is not already in the cache or if the cached file is older. + - The show_last configuration option is also available to make GDM + behave much like the old GDM where the default language/session + choice is "Last Selected". When this configuration option is set + to true, then GDM will copy the user's $HOME/.dmrc file into the + cache after pam_setcred and just log into whatever session the user + has defined there. This will be useful in Sun Ray environments + where there is a cluster of servers and there is a desire to avoid + the situation where the caches on different machines can get + out-of-sync, and you really want to use whatever defaults the user + has defined in their $HOME directory. + - /var/lib/gdm /var/lib/gdm/.gconf.path /var/lib/gdm/.gconf.mandatory/%gconf-tree.xml @@ -565,6 +706,11 @@ showing. For example, keybindings are disabled so the user can not use normal keybindings to launch applications. + GDM will use the GCONF_DEFAULT_SOURCE_PATH environment variable to + ensure that each display uses it's own GConf configuration. This + way changes in GConf will only affect the greeter in a per-seat + manner. + - /var/run/gdm This directory is used for storing Xauth keys for all active @@ -669,6 +815,11 @@ (/var/dt/sdtlogin) is used to drop the Xserver to user permissions after authentication for added security. + GDM supports all Xserver a11y features (sticky keys, slow keys, etc.). + The GDM Accessibility dialog also allows users to turn on these + features via a checkbutton, but the normal keybindings for launching + these a11y features will also work. + 4.1.9 ConsoleKit Integration GDM uses ConsoleKit to keep track of information about each running @@ -678,10 +829,11 @@ GDM provides Shutdown and Reboot buttons for shutting down and restarting the system. These buttons are only available if enabled - in the configuration, and if the "gdm" user has permissions for - the solaris.system.shutdown RBAC key. GDM does not do the actual - shutdown/restart operation, but sends a message to ConsoleKit which - does the work. Note that ConsoleKit also will only allow these + in the configuration, and if the "gdm" user has authorization for + the solaris.system.shutdown RBAC key (the system default is that the + "gdm" user does not have such authorization). GDM does not do the + actual shutdown/restart operation, but sends a message to ConsoleKit + which does the work. Note that ConsoleKit also will only allow these operations if the requesting user (the "gdm" user in the situation where the user presses the button on the GDM login GUI) has RBAC permissions for the solaris.system.shutdown RBAC key. @@ -690,7 +842,7 @@ associated TTY value of the Xserver on a given display after starting the Xserver. - GDM calls /usr/bin/ck-history when using the face browser to show + GDM calls /usr/bin/ck-history when using the Face Browser to show the most frequently logged in users first, making it easier for such users to log in quickly. @@ -724,6 +876,11 @@ 4.1.13 GDM Xsession Script + The GDM Xsession script starts the user session. The user session is + started by the process that does the PAM and audit work after + pam_open_session(3PAM) is called, and before pam_close_session(3PAM) + is called. + The GDM Xsession script sources /etc/profile, /etc/xprofile, and $HOME/.profile before starting the user session. If the file does not exist on the system, it is not sourced. @@ -778,10 +935,6 @@ - GDM no longer provides the ability to start the chooser program from the login greeter GUI program. - - GDM no longer provides a "Failsafe Session". Since the new GDM - assumes that console users have access to VT, the VT mechanism - should be used for failsafe purposes. - - GDM no longer provides the "gdmsetup" program, so there is no longer a GUI interface for configuring GDM. In some ways this is a good thing since the old gdmsetup could only be run with root privileges. @@ -804,16 +957,25 @@ However, this is obviously only useful to users who can navigate the GUI. + - While GDM does provide a /usr/share/xsessions/xterm.desktop file + so that users can log into a terminal window, this is not a true + "Failsafe Session". This xterm.desktop file will start a user + session that still runs the /etc/gdm/Xsession script and that + sources the user's $HOME/.profile. So, this cannot be used to + correct configuration errors in the user's $HOME/.profile. Users + will need to use an alternative mechanism, such as VT switching, + to do this sort of thing. + 4.2. Interfaces: Exported Interfaces Stability Comments --------------------------------------- ----------- ------------- SUNWgnome-display-mgr Uncommitted Package name. SUNWgnome-display-mgr-root Uncommitted Package name. + svc:/application/graphical-login/gdm:default Uncommitted GDM FMRI /var/svc/manifest/application/graphical-login/gdm.xml - Uncommitted SMF - integration - file. + Project SMF manifest + Private integration /lib/svc/method/svc-gdm Volatile SMF integration startup, @@ -822,7 +984,8 @@ script. /usr/bin/gdm-screenshot Volatile See 4.1.1. - /usr/bin/gdmdynamic Volatile See 4.1.1. + /usr/bin/gdmdynamic Obsolete See 4.1.1. + Volatile /usr/bin/gdmflexiserver Volatile See 4.1.1. /usr/sbin/gdm-binary Volatile See 4.1.1. /usr/sbin/gdm-stop Volatile See 4.1.1. @@ -865,6 +1028,11 @@ /etc/X11/xinit/xinitrc.d Uncommitted See 4.1.13. /usr/share/xsessions Uncommitted See 4.1.6 + /usr/share/xsessions/xterm.desktop Uncommitted See 4.1.6 + /var/cache/gdm Volatile Cached face + images and + dmrc files. + See 4.1.6. /var/lib/gdm Uncommitted $HOME directory for "gdm" @@ -872,8 +1040,9 @@ See 4.1.6. /var/lib/gdm/.gconf.mandatory/%gconf-tree.xml Uncommitted See 4.1.6 /var/lib/gdm/.gconf.path Uncommitted See 4.1.6 - $HOME/.dmrc Uncommitted See 4.1.6. + $HOME/.dmrc Volatile See 4.1.6. + $HOME/.face Volatile See 4.1.6 /usr/share/gdm/gdm-greeter-login-window.glade Volatile Glade file /usr/share/gnome-2.0/ui/GNOME_FastUserSwitchApplet.xml Volatile UI XML file. @@ -912,7 +1081,7 @@ GDM_KEYBOARD_LAYOUT Uncommitted See 4.1.7. - Obsolete Interfaces Stability Comments + Removed Interfaces Stability Comments ---------------------------- ----------------- ----------------------- Note section 4.1.15 which discusses regressions associated with these @@ -983,8 +1152,7 @@ /etc/X11/gdm/modules/factory-AccessKeyMouseEvents Obsolete Volatile Ditto. - GDM Configuration options Obsolete Volatile See defaults.conf file - [1]. + GDM Configuration options Obsolete Volatile Refer [1]. Imported Interfaces Stability Comments @@ -1009,15 +1177,16 @@ GNOME Base Libraries Committed LSARC 2006/202 D-Bus & dbus-glib Volatile LSARC 2006/368 Virtual Console Committed PSARC 2006/591 + PSARC 2008/515 GNOME Power Manager Volatile LSARC 2007/702 libwrap Committed PSARC 2000/488, PSARC 2008/164 GDM System user homedir Uncommitted PSARC 2008/662 - ConsoleKit Volatile ????? ????/??? + ConsoleKit Volatile LSARC 2009/432 /usr/lib/ck-get-x11-display-device - Volatile ????? ????/??? + Volatile LSARC 2009/432 See 4.1.13. - XDG_SESSION_COOKIE Volatile ????? ????/??? + XDG_SESSION_COOKIE Volatile LSARC 2009/432 solaris.system.shutdown key ? ????? ????/??? User environment variables Standard e.g. HOME, SHELL, etc. See 4.1.7. @@ -1036,14 +1205,21 @@ 4.5. Dependencies: + LSARC 2003/261 GDM2 - GNOME Display Manager + LSARC 2005/417 GDM2 as default Solaris Display Manager PSARC 2006/591 Virtual Console PSARC 2008/033 Removal of Xsun - PSARC 2008/662 GDM System user homedir - LSARC ????/??? ConsoleKit + PSARC 2008/515 Virtual Console Update + PSARC 2008/662 GDM System user home directory + LSARC 2009/432 ConsoleKit Since VT support requires driver support, user switching features will not work on systems where the graphics driver does not support VT. + Note that the GDM themes previously delivered to /usr/share/gdm/themes + by the SUNWgnome-themes package will no longer be delivered once the + new GDM is integrated, since they will no longer be used. + 4.6. L10N Impact: The Desktop team and the G11N team are working together to evaluate and @@ -1094,19 +1270,21 @@ are managed in the desktop. GDM makes use of RBAC so that the Shut Down and Reboot options are only - available if the "gdm" user has solaris.system.shutdown authority. + available if the "gdm" user has authorization for the + solaris.system.shutdown RBAC key. The system default is that the "gdm" + user does not have such authorization. The following cases relate to how Shut Down and Reboot functions work with the Desktop stack. - PSARC 2008/034 Defining Workstation Owner Infrastructure LSARC 2007/702 GNOME Power Manager PSARC 2008/021 HAL Power Management Support + PSARC 2008/034 Defining Workstation Owner Infrastructure LSARC 2008/262 GNOME shutdown dialog 5. Reference Documents: - [1] ./defaults.conf + [1] ./unsupported-defaults.conf File showing configuration options no longer supported. GDM Website: --Boundary_(ID_pEgNxLKTVNvwY6jlBJurwA)-- From Brian.Cameron@sun.com Fri Nov 6 16:31:47 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA70VlKj012329 for ; Fri, 6 Nov 2009 16:31:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nA70VivN016693 for <@sunmail2sca.sfbay.sun.com:LSARC-ext@sun.com>; Fri, 6 Nov 2009 17:31:47 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSP0060PQSYM900@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 06 Nov 2009 16:31:46 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSP006PBQSX6820@nwk-avmta-2.sfbay.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 06 Nov 2009 16:31:45 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id nA70VjbN021428 for ; Sat, 07 Nov 2009 00:31:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KSP00600QNICX00@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 06 Nov 2009 17:31:45 -0700 (MST) Received: from [129.153.250.167] ([unknown] [129.153.250.167]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KSP001YRQSNEG90@mail-amer.sun.com> for LSARC-ext@sun.com (ORCPT LSARC-ext@sun.com); Fri, 06 Nov 2009 17:31:36 -0700 (MST) Date: Fri, 06 Nov 2009 17:30:40 -0600 From: Brian Cameron Subject: Re: GNOME Display Manager (GDM) Rewrite [LSARC/2009/433 OnePager] In-reply-to: <4A8EE860.60303@sun.com> Sender: Brian.Cameron@sun.com To: Brian Cameron Cc: LSARC-ext@sun.com, Desktop Discuss Message-id: <4AF4B1A0.7080408@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A8C8FF8.7030505@sun.com> <4A8EE860.60303@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090929) Status: RO Content-Length: 1614 There have been some minor changes to GDM based on what was approved in the case, and I wanted to highlight these changs: - The ARC case suggested that these configuration options would be managed by the GDM greeter GConf configuration: - /apps/gdm/simple-greeter/show_last - /apps/gdm/simple-greeter/include_all - /apps/gdm/simple-greeter/include - /apps/gdm/simple-greeter/exclude After discussion with the upstream maintainers, it was decided that these options should be instead in the /etc/gdm/custom.conf file with the following keys: - greeter/ShowLast - greeter/IncludeAll - greeter/Include - greeter/Exclude This is a better choice since this makes the Include, Exclude, and IncludeAll configuration options the same as in the old GDM. The ShowLast option is a new configuration option. - The debug/Enable configuration option has been added to GDM, so it works the same way as it did in the old GDM. This causes GDM to send debug messages to the syslog, just like the old GDM did. I do not think any of these changes are controversial, or should affect this case being approved. I just wanted to document these changes in the case log for future reference. Brian > The timeout for this case has passed, and no further unresolved issues > were raised. I have marked the case as "closed approved" > > I have attached a diff file which shows all the differences to the > onepager since it was first submitted, which reflects the discussion > and agreements made in this review. > > Brian >