GNOME.org
 

Re: Turing the NM UI into an agent

Hi Dan,
since you are re-working most of the D-Bus APIs based around Network Manager, I like to propose a radical change on how you handle the UI 
part. Personally I think that the current UI inside Network Manager
(even with 0.7) has too much tasks to fulfill. I prefer having a
"stupid" UI.

So my main concern is that replacing the current UI is too
complicated. One reason is that you need a well known bus name for
the
UI on the system bus. This makes it impossible to install two UI
components or split tasks between two applications. We did the same
in
the early days of BlueZ and I think it is not a good design to hard- 
code a well known bus name into the daemon and have the UI use the
same one. So for BlueZ we came up with the D-Bus agent concept. So
let
me try to explain it.

So the UI only gets a unique name (no need for a D-Bus security
file).
Then it registers itself a object path (the actual path value is
unimportant). After that it calls a RegisterAgent(object path) method 
inside the daemon. Now the daemon knows where to find an agent
(object
path and the unique name from the message sender value) and can call 
into this object for additional information. It really serves as a
callback interface and the only things to agree on is the interface
description. The bus name and object path are kept random.
This concept allows an easy way of monitoring agents. So you know the 
case when you have no agent (meaning no UI is running) or when an
agent dies. No unneeded D-Bus calls that might fails etc. The other
advantage is that in theory you can stack agents and call them in
order. This is useful if you have a wizard or some small cases where the UI should look different from the general case. Or unregister and 
then re-register agents. For example for multi user scenarios.


There's already a split between the UI bits and the configuration
bits;
I think what you'd like to see is the User Settings service grab
unique
bus names so that each user could provide their own user settings at
the
same time to NetworkManager. I'd like to go there in the future, but then we need to figure out things that ConsoleKit will help with, but 
which are still very much undefined, stuff like:

- If user A has activated a connection on eth0, is user B allowed to
control eth0 and potentially tear down user A's connection?

- If user A has activated eth0, is user B allowed to start a VPN
connection on eth0?

Stuff like that.  There might be uses for this sort of thing in
virtualization actually, but it's kind of hard to see networking as
the
same sort of thing as Multi-User X, for example, where different users get exclusive access to individual mice, keyboards, displays, and USB 
flash drives.


I wasn't talking on these kind of things. They are totally different.


Right now the only thing that acquires a well-known bus name is the
settings service, which doesn't have to have an UI at all.  Up until
NM
0.5 it actually was a completely separate process from the applet.
If
your user has permissions to do so at the D-Bus level (ie,
at_console or
whatever), then any process can call
ActivateConnection/DeactivateConnection right now. But only 1 process 
can provide the configuration data, which limits the set of what
ActivateConnection can actually connect to.


I meant the settings service. Still need to get deeper into the
Network Manager terminology. So having a "static" settings service is
a bad design (from my perspective). Turning the settings service into
agent would be a good thing. From the logical point of view it is not
really different, but from a technical point of view it makes all the
difference.


Well, the point of having only one settings service was security.  You
don't want any service providing connections to NM, because then
anything can send "allowed" networks to NM. This is made somewhat less 
of an issue by PolicyKit, but still an issue.

Some trojan could start providing bogus networks to NetworkManager via
the settings service, which NM would then happily connect to. With one 
user settings service claiming the bus name, only one program can
provide those settings to NM, so the user is a lot more likely to notice that something is wrong (unless the trojan duplicates the look & feel of 
the user's expected applet).
actually having the applet/setting service use RegisterAgent method call to actually register an agent with the core daemon is more secure. You can block this method call via a D-Bus security policy or via PolicyKit. It is much simpler to integrate since it not simple starts up, it has to tell the core daemon it is there. Also the unregister can be protected by matching the unique name and so on. It has a bunch of advantages than simply assuming some other service claims a well known name. 


I guess I simply don't see a case for more than one settings service
_per_user_ providing network connection information to NetworkManager.
There's a case for more than one in a fast-user-switching system though.
Personally I don't see the need for having separate settings services at all. I understand why you have them, but for me all of this belongs into the core daemon and then the daemon would ask the applet/UI for information. And the requested information should be limited to passphrases, actions etc. Storing passphrases system wide or in the user keyring becomes then only an option.
For the per-user settings, this can then done behind the scenes without an extra process or code running as user. With D-Bus you can identify the unix user of a method call. With an agent concept it is even simpler since on the register call you can retrieve the unix user of the agent and store it.
My point here is really to move as much intelligence from the user session. If we keep that simple, we can replace the UI and keep a generic network daemon across platforms.
So I see the UI as something totally "stupid" that the daemon tells it 
what to do and the user can use it to influence settings inside the
daemon. Besides that both are loosely coupled.


The UI bits are somewhat decoupled already, it just happens that it's
convenient to have them in the same process right now.  When they were
split into nm-applet and NetworkManagerInfo, it wasn't very useful
abstraction.
As mentioned above, I still think too much stuff happens inside the user session. 


An example would be that the daemon needs a passphrase for a network.
So it calls a callback inside the UI agent. This call should always go 
to the logged in user and thus to the applet run by that user. Any
other callback into the UI (or settings service) should be like this.
Well, that assumes only one user is logged in :) Fast user switching is a bit different here. We need integration with ConsoleKit to figure out 
where this stuff should go.  Besides, the password information is
provided by the settings service, which needs to grab that password from 
the keyring.  No service _other_ than the settings service should be
providing information to NetworkManager, and NM should only be accepting 
passwords and such from the settings service that provided the
connection which is now being activated.
I think this will become really tricky if you can only have one settings service. So I would question the need of the settings service here. Is that a really good separation or should we better integrate it back into the core daemon and make use of what D-Bus provides us to implement per-user settings.
A small agent running in user session can handle keyring integration and UI. 


So big technical advantage here is that the daemon always knows if an
agent is present or not. And if not, it can do a proper fallback.
Calling a D-Bus method that fails is a bad thing. Also the fact that
you don't have to agree on a well known name and object path makes
this a lot cleaner. The D-Bus interface for the agent should be the
only contract between the UI and the daemon. The rest a variable
details.


I don't disagree in principle here.  Right now the UI and settings
service (which in the gnome applet are implemented in the nm-applet
process) are tied together for practical reasons, though it's not
extremely hard to split them.


Could you describe some of the scenarios that would involve stacking
UI
agents?  I'm not sure I follow the use-cases here.


So you have the applet handling all security request (passphrase
etc.), but then you wanna do a wizard to setup a new network
connection. In that case you could re-direct the passphrase request to 
the wizard (which is a different application from the applet). While
for WiFi this might be still limited in its usefulness. For all the
other wireless technologies like Bluetooth, WiMAX, UWB etc. it is
different.


I'm not sure I see the case for an external wizard; NM will be
controlling the network device itself and will be proxying the secrets
where necessary (for WiMAX, NM would be pushing the certificates to the 
OMA-DM client or to the driver for example, and for BT NM would be
pushing the necessary bits to Bluez). I'm not quite sure about UWB yet, and I know you've done a ton of work there, so maybe that's what you're 
thinking about.
The WiMAX part is a little bit trickier and to be quite honest, I don't have a full plan for it. I know for sure that we either need a username/password combination or a client certificate to authenticate the user. And of course the master CA and network certificates, but these come from somewhere else.
However the WiMAX case is really similar to the Bluetooth case. You have a cold setup and need to scan for your network and input your credentials. So you might need some kind of wizard to make this work. In case for the actual credentials you wanna have an input field inside the wizard and not having an extra dialog popup somewhere.
And forget about global scanning in the background for WiMAX. That is not gonna work out at all. The overall band is too big and would take you hours to fully scan it. So the only way to setup WiMAX is a wizard (or somekind of pre-configuration).
The Bluetooth part is pretty easy since we already have stacked agents. So if Network Manager wants to present an integrated UI, it can do that already.
UWB/Wireless USB is another story. We still have to figure out bits and pieces, but the most common thing will be that you have a cable connection first and then authorize this. Like the PS3 does with their controller. 


For Bluetooth, I had planned on having whatever configuration would be
required for DUN & PAN to be implemented in the applet, since the
configuration UI can be shared between the applet, the connection
editor, and any password request dialogs. I think it's fairly important to have a consistent UI for configuring these things, and I haven't yet seen the need for loadable modules on the applet/connection editor side, since any new device types will certainly need support added in both NM 
and the UI agents.  I'm not sure there's a big win by keeping the UI
bits for each device type separate at this time.
Integrating PAN should be fairly simple. We do have a network service for Bluetooth that does this all for you. You only have to mirror its information. It will give you a list of connections/access points and you can connect/disconnect them. All nicely over D-Bus. 

Regards

Marcel
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]