Nicolas:
> This could happen at install time (so the face pic is available on
> first login).
Yes, asking at install time for any users that are added to have a
face pic seems a good idea, though I think this is off-topic for this
case.
> Else it could happen on first login. I don't care so
> much about the details of how face pics are acquired (OT for this
> case) as I do about making sure that GDM:
>
> a) doesn't depend on heuristics to determine what users are to appear
> in the face browser,
> b) doesn't touch $HOME until after pam_setcred(h, PAM_ESTABLISH_CRED)
> is done[*].
>
> (a) means no surprises when some part of the system changes in a way
> that might interact badly with such heuristics. Also, an explicit
> list allows users to not necessarily be local, which is nice too --
> GDM could even have an option to display only the last few logged in
> users in the face browser, which could be useful in a corporate
> environment (if that's what people want).
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.
However, we could probably make changes to add configuration to make
GDM more flexible in how it uses or does not use heuristics. For
example, the following sorts of changes could probably get upstream:
- A configuration key to specify that the heuristics are not used,
but that users are added to the list of users after they have
logged in for the first time. This is the current default for NIS
users, but it could be the way it works for all users.
- Configuration keys to specify what users are to be included in
the list all the time, or never.
- Fixes to the existing heuristics so that they work better on Solaris.
Obviously we can patch GDM to work any way we want. However, I would
like to avoid adding Solaris-specific configuration. So we should
try to enhance GDM in ways that our improvements can go upstream.
If the Face Browser is too problematic on Solaris, we can also just
completely disable it in a way that users can't turn it on. This
would be my recommendation if this discussion gets too bogged down. It
is not a necessary feature.
> (b) means that users need not be local (see previous item), or may
> have special automounted home directories. And it means that GDM
> need not apply any heuristics to determine whether it would be bad
> for it to touch the user's $HOME prior to completing credential setup.
>
> [*] If a homedir is shared -o sec=krb5:sys and the local
> mount/automount doesn't set -o sec=krb5, and if the host lacks
> Kerberos credentials (laptops usually lack host creds), THEN
> touching the user's $HOME as euid == 0 or before acquiring the
> user's Kerberos credentials causes the homedir to be mounted
> with sec=sys. Not having this problem is very important for
> enabling Kerberos deployments to progress at non-instantaneous
> rates.
>
> Avoiding this problem is, I suspect, one of the reasons for the
> GDM local user heuristics, but you can see that those heuristics
> are not robust. Better avoid the heuristics and go with an
> explicit list of users + face pic caching.
This is a more serious issue with the new GDM. Actually the new GDM
accesses the user's $HOME directory in two situations before
pam_setcred.
1) After PAM_USER is specified (normally after the username entry),
the user's $HOME/.dmrc file is accessed to find out the user's
default session/language choices, which are shown in the GUI as
the defaults.
2) When the Face Browser is used, the $HOME/.face file is accessed
to get the user's face image to show in the Face Browser.
So, GDM needs some work to make it work properly with kerberos.
After talking with the upstream GDM developers, the following change
would be acceptable to go upstream:
- The SUNWgnome-display-mgr-root package would install a directory
/var/cache/gdm.
- At run-time GDM would create a directory /var/cache/gdm/user-$uid
when a user logs in, if the directory does not already exist. In
this file will be placed two files: dmrc and face.
- If the /var/cache/gdm/user-$uid/dmrc file does not exist, then
GDM will log the user into the default session/language or whichever
ones they selected in the GUI. Then it will save the dmrc file to
the cache with the default settings. On next login, the defaults
will be read from the cache and not the user's $HOME directory.
- On first login the /var/cache/gdm/user-$uid/face file will not
exist so the user will see a generic user icon for their face.
After authentication, GDM will check if the user has a defined
face and copy it to the cached file. Also, on logout, GDM will check
again if the user has a defined face and copy it to the cached file.
This way the face image will be available on next login if the user
defined it during their session. Obviously the face image will only
be copied to the cache if one is not already in the cache or if the
cached file is older. Using this technique, GDM would only access
the face images from the cache, and not the user's $HOME directory.
If it is a TCR requirement for GDM to work this way before it
integrates, then we can make it work this way.
Is that reasonable?
Brian
