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
