Brian Cameron wrote: > > Nicolas: > >> 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: > > - We want to avoid a sysadmin needing to configure GDM to specify what > users to include in the face browser. > - 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. > For example, how do users change their mind if they picked "No", but > then decide "Yes" later (or vice versa). Does GDM need new GUI > elements to allow users to change their setting, and if so, how to > properly integrate this into the overall desktop experience. Not > impossible to implement, but time consuming.
You need that optin/out and change of mind anyway. Not having it presents a privacy problem. Consider a multi national company that has facebrowsing on by default and users from all over the world (with different privacy jurisdictions and personal expectations). They all use a common set of Sun Ray or other multi seat systems. You need to have a per user method of optin and/or optout. This can not be done (and be safe legally) based on heuristics keyed off assumptions that local nameservice accounts are different. There maybe cases where it is acceptable for a user to be in the face-browser on some machines that share the same nameservice and home directory but not others. Though I'd regard that as a more advanced config. For example, wanting their face on their local workstation in their office but not if they use a Sun Ray server in a public area - same nameservice, same home dir (neither of which have a local account). >> 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. > Normally you only want the local users to show up in the Face Browser. Local user is a bogus requirement. Am I a local user on my workstation in my office ? Yes, but I may not have an account in /etc/passwd or a local home dir. Am I a local user on the Sun Ray DTU in my office ? Yes ? and again no local account or home dir is likely. Am I a local user on my laptop ? Yes and in this case I likely do have a local password entry and local home dir. Am I a local user on my at home workstation ? Yes and like the laptop case I may have a local password entry and I may or may not have a local home dir. So what is "normal" here ? I think we are actually pretty close with the caching proposal to having this be able to work by default. The one change I believe is necessary is not making assumptions based on nameservice location of a user. Partly because it really isn't as simple as looking in /etc/passwd - what about when compat mode is on ? What about accounts with local passwd but remote home dir ? -- Darren J Moffat
