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