Re: [gdm-list] Request for feedback: Proposed enhancements to GDM greeter interface

[Robert Ancell <robert ancell canonical com>]

> > 2. Move code / produce a greeter library to minimise the amount of 
> > code in the simple-greeter
> This sounds like a good idea.  Some real thought will need to go into
> item #2 above.  For example, should this library only include interfaces
> that are GUI-agnostic, such as how D-Bus works in the greeter?  Or
> should the library contain some GUI elements such as the panel or the
> face browser that might be shared across multiple greeters?
Ideally I'd like to see the standard d-bus interface provide as much of 
the common elements as possible.  Then I'd look at a libgreeter-gtk 
interface which provided GTK+ widgets and a gobject interface to the 
d-bus interface.

> > These changes will allow the following improvements:
> > - New greeters will be able to be developed without limitations - 
> > thus making GDM completely themeable
> There are some "limitations" that are imposed by accessibility.  So, we
> should think about how providing accessibility might affect the
> interfaces provided to write a greeter.  We should make it easy for
> users to write an accessible greeter.
Agreed.  The API needs to meet all the requirements for l10n, i18n, 
a11y, security.

> The old GDM 2.20 gdmgreeter technique of using libgnomecanvas was never
> very accessible.  Its GUI elements did not support ATK, and since it ran
> without a window manager it did not work well with struts based programs
> like GOK.  Hopefully any themed greeters that we develop in the future
> will have better accessibility support than gdmgreeter had.
But in saying that I don't think we have to worry too much about a11y 
for alternative greeters.  In the case of Ubuntu we'd always deliver a 
greeter that was fully accessible.  For those who want a fancy greeter 
(i.e. a minority of users who like to tinker) with all the bells a 
whistles (and thus may be hard to make accessible) we'd expect them to 
install "fancy-greeter" over "simple-greeter".

> Also, there are some "limitations" that are imposed by PAM.  For
> example, some people have suggested it would be nice to display both the
> username and password prompts together on the same dialog, but this
> would not be possible without significant enhancements to how PAM works.
And any default greeter would have to meet all these limitations.  
However "fancy-greeter" may have the requirement that the local PAM 
system is just username+password and thus be able to show both prompts 
at the same time.

> >   - A greeter can be developed which is easy for artists to them 
> > (e.g. by embedding webkit and using using CSS for theming)
> I encourage people to experiment and try new interfaces for the greeter.
>
> However, remember that the login greeter is a program that people with
> access to the machine can use without authentication, and the greeter is
> used to manage security sensitive information.  So, care should be taken
> to ensure that the greeter does not inadvertently give the user any
> unintended privileges or access to the machine.
> I am all for making GDM easier for artists to use, but we need to be
> careful to do this in a way that is also easy to keep maintainable and
> secure.
Again, we should provide a secure API and encourage best use but I don't 
think we need to be too careful here.  Replacing the greeter will always 
require root privileges and thus will be the responsibility of the 
sysadmin.  Any greeter(s) provided in the GDM source will absolutely be 
secure.

I don't see it a responsibility of the GDM project to provide all these 
greeters (in fact delivering one is probably enough).

> > - Other applications will be able to access GDM information (e.g. 
> > application switchers)
> Again, care needs to be taken to ensure that other applications do not
> gain access to information that is inappropriate.  Since the main GDM
> daemon runs as root, there are certain functionalities that greeters
> are allowed to do that normal user programs should not be able to do.
> Such as how Xauth keys are managed, for example.
>
> I believe GDM is already well integrated into the User Switch applet.
> ConsoleKit already provides programs like the User Switch applet far
> more useful information than the old GDM 2.20 supported via its
> private gdmflexiserver sockets interface.
>
> I would be interested to hear what specific interactions between the
> GDM daemon and login greeter you think would be useful to provide
> to other applications.  Do you have any use cases you are thinking
> about here?
The main case I am thinking of here is the user information as done in 
the patch I was working on:
https://bugzilla.gnome.org/show_bug.cgi?id=593996 (set to WONTFIX)
And this should probably be external to gdm anyway.

I haven't thought this part out completely yet.  I will bring it up 
again when I have a more concrete proposal.

> > - GDM will be usable by other desktops (KDE, XFCE)
> I am not sure I follow what you mean here.  Could you elaborate?
There was two suggestions that were raised when I proposed this at UDS:
1. XFCE developers were keen for it to work well for them (particularly 
in regards to theming)
2. It was suggested that KDM needed a lot of work and if they could use 
GDM with a QT interface that would work for them