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 --
