Nicolas: >> 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.
That is an interesting idea. Thanks for suggesting it. However, it is not quite that simple since the Face Browser is designed to work even if the user does not have a defined face image. So, the existence of a face image is not an indication that the user should be in the Face Browser or not. I suppose we could make it work that way on Solaris and require users to create a face image for their user to show up. Or, perhaps, we could assume that any user who logs in wants to be in the Face Browser and add an empty face file for that user on logout to indicate they want to show up in the Face Browser with the default face image. This sort of design is contrary to the way people want GDM to work on other distros, so I am unsure if the changes needed to make it work this way would go upstream. Most other distros want it to work with all local userids out-of-the-box as it does in other popular operating systems. But, as you say, we could use #ifdef's or perhaps add a configuration option to make it work any way we like. >> - 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. Fair enough. I think requirement (a) is probably a hard requirement and is likely going to be a TCR. Some questions, I think, remain: - Is requirement (b) a TCR or not? - If the new GDM does not meet requirement (b) then does this mean that we need to disable the Face Browser so it can't be used, or just be turned off by default? - Assuming we have time to meet both requirements, will the Face Browser be turned on or off by default? >>> 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. If the dmrc file is saved in /var/cache, then the defaults are machine specific. If we move the dmrc file to /var/cache, then there would be no $HOME configuration file to worry about. If you are suggesting that GDM try to sync the $HOME/.dmrc file with the one in /var/cache, then I don't think that is worth the bother. It seems more sensible to not assume that the user wants to use the same session type on every machine they log into. The same sessions and languages might not even be available on all the machines a person wants to use with a shared $HOME directory. Making it more machine specific seems to make more sense to me since sessions and languages are also machine specific. The only situation where a race condition would exist would be in the unlikely event if the user were to enter their username and password into two terminals connected to the same server and hit "Log In" at the same time on both. In that situation, I am not sure it would matter which settings got saved as the default if they happened to be different. > 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. Agreed for face images. >>> 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. As I say above, the Face Browser is designed to work even if the user doesn't have a face image. Unless we want to add that constraint. My suggestion that users who log in get an empty face image file that means the same as "use the default face image" could also work. The problem with making the user define a face image to show up in the Face Browser is that this makes the login user experience very different than the way it works on other popular operating systems. Though, we can be different if we think there is a lot of value in doing so. >>> 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 way GDM currently works: - You would see your local UID in the Face Browser initially - After logging into your name service account, it shows up too. The way you suggest it should work: - Nobody shows up initially - You log in n-number of times, and after you define a face image in your two accounts, they show up. I also suggest it could work: - Nobody shows up initially - The users show up in the face browser after you log into them the first time. Personally I think the way GDM already works is nicer, though it does use heuristics that you strongly object to. If requiring users to opt-in then the second choice is reasonable by forcing users to create an image to opt-in. The third choice is also reasonable if requiring users to opt-in is not really a requirement. > The whole notion of that GDM needs to care about whether a user is local > or not is broken. Please remove it. I guess the question for now is whether this means we have time to fix the Face Browser as described for initial integration. If not, I am guessing that "removing it" means removing the entire Face Browser for now. Brian
