Add plugin system

[Robert Ancell]

Support plugins so more complex displays can be managed. Move some code out of lightdm into plugins (XDMCP, user switcher)

Plugin types:
- Display type - i.e. this plugin is responsible for creating new displays
- Display servers - have an X server / Wayland plugin
- Authentication systems - move PAM into a plugin

libpeas may make sense, probably start with GModule [1] first at least.

http://library.gnome.org/devel/glib/unstable/glib-Dynamic-Loading-of-Modules.html

[Brian-cameron-oracle (brian-cameron-oracle)]

Some thoughts...

A plugin system for handling display type (e.g. console, XDMCP, Xnest, etc.) would be very useful because it would make it easy to enhance the display manager to support new types and would encourage more experimentation. For example, it would be interesting to use Xvfb to map displays in local memory and then attach the Xvfb to actual monitors to support VT-like switching on non-console displays. Such techniques are rather daunting to try to integrate into a display manager, but could become trivial to add if the display manager supported a flexible plugin system.

For many display types, the difference in how displays are managed are fairly trivial - how the display is started, how the display is torn down, and how switching is handled if switching is supported. By moving this code into plugins, the display manager engine should become more clean and abstract and easier to maintain.

One problem with many other display managers out there is that the code turns into spaghetti after it supports a few display types with a lot of odd code to handle state and different cases. Separating this logic into plugins and keeping the engine simple & consistent for all display types should make code management a lot more simple.

I am not sure that a plugin system for "display servers" is really needed. You could treat a different kind of server simply as a different display type. The engine should only be concerned about how to start, how to tear down, and how to handle switching if supported. In other words, the command to run (Xserver or Wayland) could just be handled by different plugins.

An authentication/audit system plugin would be useful since PAM could be moved into a plugin. Users might want to use different PAM modules on different displays (e.g. fingerprint reader on one and normal username/password entry on the other). So it is useful to be able to specify different PAM service names (the 1st argument passed to pam_start) in a per-display fashion. Also extracting authentication into plugins would make it easy to use the LightDM engine to handle different kinds of authentication - not just PAM. For example, it would be neat if LightDM also supported screen locking. To do this properly you really need a plugin system for authentication since the PAM and audit calls for login are different than for screen lock. If you wanted to use LightDM as an engine for handling password entry for other programs (such as gnome-keyring or PolicyKit), then you might want other non-PAM plugins to be used for these situations that pass the password input along to where it is needed in a secure fashion.

The advantage of the display manager providing a service to programs to handle such authentication is that it would make password entry more secure. One issue with password entry in the user's session is that anybody who is able to access your xauth key can snoop keypresses, for example. So password entry is only as secure as Xserver xauth security. Not that secure, really. However, if LightDM provided a service that a program could ask LightDM to VT switch to a new display, ask for the password and return back to the user ses...

[Brian-cameron-oracle (brian-cameron-oracle)]

Here is how I think the DisplayType plugin could work. The LightDM engine could provide the following D-Bus interfaces.

Init (char *display_type)
AddDisplay (char *display_type, char *display, char *auth_plugin, char *auth_plugin_data, char *user_data)
RemoveDisplay (char *display_type, char *display, char *user_data)
gboolean SupportsSwitching (char *display_type)
SwitchDisplay (char *display_type, char *from_display, char *to_display, char *user_data)

These D-Bus calls would then call interfaces in the per-display-type plugins. The AddDisplay and RemoveDisplay interface should only be accepted if they are called from a root-running process. The SwitchDisplay interface should be accepted from a user-session. I think the user_data should be a string since that would make it easy to pass in multiple values in a generic way that can be parsed.

As a suggestion, the AddDisplay interface could accept a NULL display and allow the plugin to just figure out the next available display. The SwitchDisplay function could accept a NULL from_display value if the type only manages a single seat (such as VT) and a NULL to_display value would mean to create a new display.

Each display type would be managed by a dynamically loaded plugin specific to that display type. The plugin would support these interfaces:

1) An Init interface. If displays of this type are started or killed on-demand, then the plugin could start a thread to listen for connection requests (e.g. XDMCP). If displays of this type should be started when the login manager starts up via configuration, then the init function could just go ahead and start them. When displays need to be started or stopped, the plugin would call the main daemon AddDisplay or RemoveDisplay D-Bus command, passing any user-data needed to start or stop the display.

2) An interface to start managing a display. This interface would be called when the main daemon receives an AddDisplay request. It would be passed the user-data so it knows any special information it needs to start the display. It would also be useful to have arguments to specify what Authentication plugin to use and any userdata. For example, it would be useful to be able to tell LightDM that I want to start a new display that is using the lock screen PAM stack, or that I want to use some other non-default PAM stack on a given display.

3) An interface to stop managing a display. This interface would be called when the main daemon receives a RemoveDisplay request. Also when GDM shuts down, the main daemon would loop over all running displays and call this interface for each one to shut them down cleanly.

4) An interface that returns whether or not the display type supports display switching.

5) An interface that switches the display to the specified one and is called when the main daemon receives a SwitchDisplay request. It obviously only works if the display type supports display switching.

It would probably make sense for such plug-ins to have a common base class. The base class could provide some common logic for handling things like generating the Xauth key that many (if not all) plugins would want to use in common. Also, if ...