atom feed18 messages in org.gnome.networkmanager-list[RFC] Fast-user-switching plans
FromSent OnAttachments
Daniel GnoutcheffMay 20, 2010 1:09 am 
Ludwig NusselMay 20, 2010 11:53 pm 
José QueirozMay 24, 2010 8:29 pm 
Ludwig NusselMay 27, 2010 1:07 am 
José QueirozMay 27, 2010 7:26 am 
Marc HerbertMay 27, 2010 9:19 am 
Simon GeardMay 28, 2010 1:16 am 
Marc HerbertMay 28, 2010 6:46 am 
Martijn LievaartMay 28, 2010 9:23 am 
Graham LyonMay 28, 2010 10:13 am 
Martijn LievaartMay 28, 2010 1:41 pm 
Graham LyonMay 28, 2010 2:02 pm 
Dan WilliamsJun 2, 2010 12:45 am 
Simon GeardJun 2, 2010 4:42 am 
Dan WilliamsJun 4, 2010 7:24 pm 
Simon GeardJun 5, 2010 5:29 am 
Dan WilliamsJun 9, 2010 4:28 pm 
Simon GeardJun 10, 2010 1:58 am 
Subject:[RFC] Fast-user-switching plans
From:Daniel Gnoutcheff (
Date:May 20, 2010 1:09:46 am

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