Nicolas: > On Mon, Aug 17, 2009 at 08:20:14PM -0500, Brian Cameron wrote: >> - Several people (Joerg Barfurth, Darren Moffat, Nicolas Williams) have >> highlighted that GDM should not touch the user's $HOME directory >> before the user authenticates. Currently GDM accesses the user's >> face image ($HOME/.face) and the user's session/language defaults >> ($HOME/.dmrc) before pam_setcred. Touching the user's $HOME >> directory before pam_setcred causes problems for kerberos, for >> example. >> >> Proposed solution: >> >> - The SUNWgnome-display-mgr-root package would install a directory >> /var/cache/gdm. > > What will be the permissions on this and the files in it?
root:gdm 640 seems to make the most sense. >> [...] > > Looks good to me. > >> - 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. In addition to that >> solution, one of the two following approaches could be used to >> address these concerns: > > I'd even say that /var/cache/gdm is sufficient because the installer can > touch(1) the initial user's cached and $HOME/.face files, and so can the > Users and Groups and useradd(1M) utilities. That means that local users > will appear in the face browser, but with no local user heuristics. > > Opt-in can be a checkbox in the installer, Users and Groups, and > useradd(1M) utilities. But that's probably not necessary: just opt-in > all such users in the installer/useradd tools (no checkbox, just do it). > If users/admins don't like that they can disable the face browser > altogether. We can file enhancement requests against the installer, Users and Groups, and useradd(1M) projects to provide deeper integration with GDM if desired. In talking with the upstream GDM co-maintainers, they disagreed with the idea of the existance of the user's face image to control the user's opt-in/opt-out state. Instead they would prefer to add back the Include/Exclude options that the old GDM supported. I just sent a separate email where I go into more detail about this. But, this should not be a problem. As long as GDM exposes interfaces that the installer, Users and Groups, and useradd(1M) interfaces can use to configure GDM to show the right users in the Face Browser, this sort of deeper integration should be possible. >> 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. > > How would you determine (1) without looing in $HOME? GDM would look into $HOME after the user has passed pam_setcred and copy the face image from the $HOME directory into the cache. GDM will also copy the face image from the $HOME directory into the cache on logout. This way, if the user defines their face during the session, it will be copied into the cache for next login. This does mean that the user's face image won't show up in the face browser until the second login, when the image is in the cache. Instead the user will see the generic "face" image GDM uses when it can not determine the user's specific image file to use. On subsequent logins after the image file has moved to the cache, the user's defined image will appear properly in the Face Browser. In most situations, this would not be an issue since users would not have a face defined until after they login the first time. There are some situations where this wouldn't be true (like when the user has an NFS mounted $HOME directory), but not seeing their chosen image on first login shouldn't cause any real problems. > If root is not a role, then why not put root in the face browser? Currently the code filters out UID's under 100. If someone thinks it is important for GDM not to do this, then an ARC member will need to say it would otherwise be a TCR. >> 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. > > My comments to (1) apply here too. But also, one way to opt-out might > be to rm $HOME/.face, yet (2) would seemingly not allow that (since it > seems to clash with the idea that /var/cache/gdm/user-$uid/face is > updated at logout time to be a copy of $HOME/.face). The cache will be kept in sync. If the user removes their $HOME/.face, then the version in the cache would be removed and they would no longer see their image in the face browser. That said, in talking with the upstream GDM co-maintainers, we decided it would be better to manage opt-in/opt-out via adding back the Include/Exclude configuration options which were supported in the old GDM. Again, see my other email for more details on how this will work. >> - There are many concerns about the Face Browser and whether it should >> be turned on by default. >> >> - Glenn Faden suggested it not be the default because it is a >> potential security vulnerability to expose usernames before >> authentication. >> >> Proposed Solution: >> >> Turn off the Face Browser by default. This will make OpenSolaris >> different than everybody else, but our users love us because we are >> such curmudgeons about these things, I guess. > > IMO: > > This is an issue, but it's an installer issue, not really a GDM > issue. AI should almost certainly disable it by default, while the > OpenSolaris installer should probably enable it by default. To > force the matter GDM could have this feature disabled by default (a > "safe" default), such that the OpenSolaris installer project team > would have to do the enabling. It makes sense to me to file an enhancement request with the installer so that the user can select whether they want the Face Browser turned on or off by default. Or to just assume that if the user installs via the graphical installer that they wish to have it on seems fine with me. Brian
