[RFC] Fast-user-switching plans

[Daniel Gnoutcheff <daniel gnoutcheff name>]

I've been spending some time thinking about how to get N-M to work with
fast-user-switching. Here are some possible solutions that I have heard of or
thought of, presented for review.


----------------------------------
1: Multiple user settings services

This is my favorite idea so far.

Instead of attempting to claim a well-known bus name, user settings services
would use their unique bus names and "register" themselves with the N-M daemon.
The daemon would use ConsoleKit to determine which session each settings service
comes from, and it will permit up to one settings service per session.
ConsoleKit would also be used to determine which session(s) are active, and N-M
will only pay attention to the settings service(s) that represent the active
session(s).

In its most basic form, this approach would require the addition of just one
method somewhere in N-M's DBus interface, something like

  org.freedesktop.NetworkManager.RegisterUserSettingsService (
    in STRING bus_name,
    in OBJECT_PATH settings_root )

where 'bus_name' is the bus name of the new user settings service, and
'settings_root' is an implementation of org.freedesktop.NetworkManagerSettings
that lives under that name.

I wouldn't plan to worry about multiseat quite yet; for now, N-M would only pay
attention to the first seat. A good place to start I think, especially since I
hear that ConsoleKit doesn't actually do multiseat just yet. However, if/when we
do support multiseat, this API probably wouldn't need much (if any) adjustment.

Oh, and for backwards compatibility, if something claimed
'org.freedesktop.NetworkManagerUserSettings', we would treat that as equivalent
to the call
  RegisterUserSettingsService (
    "org.freedesktop.NetworkManagerUserSettings",
    "/org/freedesktop/NetworkManagerSettings" )


---------------------------------------------------
2. Move user settings management down to the daemon

Under this plan, the daemon would take on responsibility for storing and acting
on user settings data. It would use ConsoleKit to determine what user is at the
console, and it would act on the settings data from that user. It would provide
some kind of DBus interface that would allow users to edit only their own
settings data.

This approach is interesting in that it would address the fast-user-switching
and user-settings-editing-over-DBus problems at the same time. It would also
simplify NM clients considerably, which would be nice since where are multiple
client implementations and only one daemon implementation. Indeed, we would not
necessarily need to have an always-running client, which I imagine would be
convenient for cnetworkmanager. Nonetheless, as I discussed in my message about
security, I don't think we want to do this (lots of stuff in UID 0, no more
gnome-keyring, etc.).

As for duplicated functionality among N-M clients, that probably can be
mitigated by making a shared library for them to use, so I'm not too worried
about that.


------------------------------
3. Make N-M a pure "mechanism"

This idea has been proposed before, but just for completeness: this would take
the idea of "settings services" out of the N-M core daemon, and the system
settings service and N-M clients would only send settings when asking N-M to
actually connect to a network. N-M would use PolicyKit to determine who is
allowed to control network settings, so e.g. only users at an active console can
connect to a new network.

The nice thing about this is that it makes the daemon as simple as possible. It
wouldn't have to worry much at all about manging settings and tracking who's at
the active console. We would just use PolicyKit the way it was designed to be
used. This also might make it easier to do things like support fine-grained
policies.

However, the user settings service concept is useful enough that I think it's
worth keeping. For one, it implicitly enforces the policy of "one NM client per
session". Without that, I'm not sure what we'd do if someone ended up running
multiple NM clients. More importantly, there are cases were we want to update
settings data while the connection is up (e.g. the seen-bssids list for wifi
networks), so to a certain extent we do want to have a settings store that
exists for the life of the connection.


--------------------
4. Voluntary handoff

Have every NM client hold the 'org.freedesktop.NetworkManagerUserSettings' bus
name if and only if they are in the active session.

The big problem I have with this is that I just don't see how we can make it
robust. While DBus does have some nice mechanisms for bus name replacement, I
don't see a good way to prevent a buggy or malicious NM client from grabbing the
name and never letting go. The best I can think of would be to use SELinux or
something to ensure that only trusted NM clients could ever grab the
'NetworkManagerUserSettings' name, and then try to ensure that all of these
clients always use DBUS_NAME_FLAG_ALLOW_REPLACEMENT. But it still feels fragile.

Furthermore, I can't think of any way at all to adapt voluntary handoff to cope
with multseat setups. Even if we never really support multiseat, things would
break very ungracefully unless we had some complicated negotiation protocol
between clients.

I'm all ears if someone can think of good ways to deal with these problems, but
otherwise, I really don't think we should take this approach.


---------

Well, once again, thanks for reading all that! Comments, corrections, better
ideas?

Many thanks,
Daniel