Darren:
>> Correct. The way the code works is that it calls fgetpwent() and if
>> /etc/passwd contains no value, then that account does not show up in the
>> Face Browser. So, users would need to avoid using the shorthand if they
>> want the user to show up in the GDM Face Browser.
>
> Which nameservice a user is in or not is not the correct way to
> determine wither or not the face browser should be used.
I disagree. The Face Browser was designed to be useful in one very
common use-case. The situation where a person has a laptop machine
with multiple users to provide a login experience similar to what one
gets with other popular operating systems. An easy-to-use click on
my name, type my password, and login process. All other distros
which ship GDM turn on this feature by default since this is their
most common use case. They do this with the understanding that
sysadmins who want to do more sophisticated things (e.g. use other
PAM stacks, use NIS/LDAP in ways that would make the list of users
shown cumbersome, have security issues with the Face Browser, etc.)
will turn it off. Whether we enable this feature by default or not
depends on whether Sun also wants to facilitate this common use-case
or not.
While I can also imagine that the Face Browser may be useful in some
terminal server or thin-client situations (e.g. when the number of
users is not cumbersome and the default PAM stack is used), or in some
situations where NIS/LDAP is used, these are not use cases that the
Face Browser is designed to support well.
If Sun wants to invest time and energy to make the Face Browser work
better or support more use cases, we can consider doing so. However,
I do not foresee such work being a part of this case unless we are
able to decide on a solution that is not very cumbersome to implement.
>> If that is inappropriate, then we could change the logic to work a
>> different way.
>
> Yes I think it is inappropriate. I think this needs to be specific to
> GDM config rather than derived based on assumptions about specific
> nameservice content. Maybe rather than specific to GDM there should be a
> freedesktop.org spec for faces images and optin/optout of face browsing
> in general. Since this doesn't apply just to GDM but ideally to
> screenlock and fast-user switching applets.
For its warts, the Face Browser seems to work fairly reasonably on
OpenSolaris today with the caveat that you need to make sure that
/etc/passwd has a defined shell for users you want to show up in it.
If we can come up with more intelligent heuristics that could make
GDM work better (e.g. so that users who are valid users but do not
have a shell defined can show up, etc.) then it would not be too
cumbersome to fix such issues before integration. However, defining
freedesktop.org specifications and an optin/optout infrastructure
that would be acceptable to the upstream GDM community is not
something that can be addressed in the timeframe of this case.
Note that the current GDM in OpenSolaris has a Face Browser that has
much worse warts, but it is off by default. There have been several
reasons provided why the Face Browser should not be turned on by
default on Solaris:
- Showing usernames before authentication is a security concern.
- It accesses the face images from the user's $HOME directory before
authentication.
- It does not work in some environments (as described above) and would
need to be turned off in those situations.
Since the Face Browser is not a particularly necessary feature, I
recommend that we either decide to do one of the following:
Option #1: Accept it as-is (or with a few minor enhancements to make it
work better) and make it the default.
Option #2: Accept it as-is (or with a few minor enhancements to make it
work better) and make it not the default (much like with the
current GDM).
Option #3: Completely disable the Face Browser so it cannot be used on
OpenSolaris.
If we go with Option #2 or #3 and want to discuss what work will be
necessary to make it Option #1 in a future ARC case, that's not a
problem. But first, I would like to decide what option we will take
for this case.
Brian
