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
