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
