Darren J Moffat schrieb: >> 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. >
In all desktop environments I know, there is no individual opt in/out for being listed in user lists. If listing any (real) users is a privacy problem, then userlist browsing should be turned off on the system. Note that, unless strong lockdown is configured, authenticated users will generally be able to browse user lists (e.g. 'getent passwd'). > 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). > Whether face browsing is on is a characteristic of the system, not of the user. All a user gets to control is the image associated with them, if they are listed. If listing the name in a list that is visible to unauthenticated users with access to a login screen is a legal problem in any relevant legislation, then face browsing should be turned off across the system. If Sun Ray servers are in a fail over group, you need to have local system config be as identical as possible to provide a true failover experience. If a set of Sun Rays has different security characteristics (e.g. is in a publically accessible location) to the rest, they should be on a different server (with different security config). We don't have logn-head specific PAM configuration either (today). There may be an exception, if a special seat offers a special environment instead of ordinary login (e.g. you currently can have Kiosk running on selected Sun Rays, but I wouldn't recommend that, if that main uses of the server are sensitive). >>> 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. > It seems the term is ambiguous. I think here the focus is on 'locally added', i.e. the user (account) was explicitly added to the specific system. This corresponds to 'local user' in the sense of 'in a local name service and authentication authority'. This has nothing to do with 'user having a local login (or session)' vs. 'remote login', which is another context in which the term 'local user' is sometimes used.. > 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. > In the sense that is relevant here, you are a local user of that workstation, if you (or whoever administers that workstation) has explicitly configured this machine to be used by you rather than you having access because the machine trusts a non-local user authority. The intent is that: - if this machine has been explicitly set up for *your* use, you show up in the list. - if you use a machine from a pool of machines that accepts you by reference to a non-local authority, then you become listed after first using the machine. > Am I a local user on the Sun Ray DTU in my office ? Yes ? and again no > local account or home dir is likely. > Similar, but here the 'configured explicitly for your use' case is less 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. > Yes. And thus it should show only you (or people you share your laptop with) in that list. > 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. > Again, if the association with you gets created explicitly (and most often by creation of a local 'files' account), you should be listed by virtue of that configuration step. If the association with you gets created by you starting to use the machine without anyone explicitly provisioning you as user of the machine, then you should be listed only by virtue of being in the history files. > So what is "normal" here ? > I think the two sets of scenarios: - Personal machine with individually configured local account (where the home dir is doesn't make a difference, really) - Shared/sharable machine, using a network user authority. .. are considered normal. Certainly these scenarios and a mix where there are both locally defined and network accounts are what seems to be addressed by the described heuristic. Deployments where local passwd files containing large user populations are copied from elsewhere are probably considered too 'un-normal' to get special consideration by this feature: either they live with showing all those accounts or else they should turn off the feature for the system. Sounds at least as reasonable as creating and maintaining configuration knobs for all remote possibilities. > 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 ? > I think it is the mere fact that the user has an explicit entry in the local passwd file that is supposed to trigger the 'include in list'. What I don't know is, if the currently implemented fgetpwent-based logic will handle all these cases properly. - J?rg -- Joerg Barfurth phone: +49 40 23646662 / x66662 Software Engineer mailto:joerg.barfurth at sun.com Desktop Technology http://reserv.ireland/twiki/bin/view/Argus/ Thin Client Software http://www.sun.com/software/sunray/ Sun Microsystems GmbH http://www.sun.com/software/javadesktopsystem/
