Re: Turing the NM UI into an agent

[Dan Williams <dcbw redhat com>]

On Thu, 2008-03-27 at 19:33 +0100, Marcel Holtmann wrote:
> 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.
> >
> > This is true.
> >
> >>> 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.
> >
> > Since the connections/settings must be stored in the user's session,  
> > I'm
> > not sure how moving it back to the core daemon would work well.  We
> > don't want NM to have to poke around the user's home directory for
> > things (it should be well-confined with SELinux policy for example),  
> > and
> > we don't want NM itself to have to store each user's settings  
> > somewhere
> > either.  There's also the DE issue, on Gnome we use GConf, on KDE they
> > use something else, and people have talked about writing a CLI
> > client/settings service.
> 
> you call a method in the agent interface (running in user session) and  
> let it return the needed information. Preferably in form of a  
> dictionary.
> 
> >> 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.
> >
> > That's a goal, though I'm not sure how that would be implemented in
> > practice.  I don't really want NM itself storing all the configuration
> > information somewhere, I feel like it should be part of the _user's_
> > preferences since much of it is user data, not system data.
> 
> This really depends on. I can argue for or against it. It really  
> depends on what the user wants. In some cases I would say, yes, it is  
> user specific. In other cases I would say that the user acts as a  
> system administrator. I have no clean answer for this, but my goal is  
> to keep the UI as lightweight as possible.
> 
> Then of course you have these single user embedded system where you  
> have no real difference between system storage or user storage.
> 
> >>>> 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.
> >
> > At least EAP-TLS is used for the authentication, though some providers
> > will be using EAP-TTLS after the initial provisioning is done.  We're
> > going to have to get an OMA-DM client up and running for at least one
> > provider here in the US.  We'll also need to expose the certificates
> > that are stored on the EEPROM of some implementations to the OMA-DM
> > client and possibly to userspace as well.
> 
> I honestly hope that we can write an OMA-DM client that hides all of  
> this for us. Re-using an existing OMA-DM client seems not a good idea  
> at the moment. However I might be wrong on this part. WiMAX is still  
> changing a lot.

I can't personally _find_ any open-source OMA-DM _clients_.  There's the
funambol server, but I don't think they have clients.  The plan for this
was to have the OMA-DM server running unprivileged (since it would have
to listen on a port) and exposing a D-Bus interface so that other
programs could ask it for information and poke it to do stuff.

> > I don't have any setups that would use straight username/password,
> > though I'd be interested in learning about them so I can go buy one.
> 
> Don't look at me. I have non either ;)
> 
> >> 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.
> >
> > Right, I'm treating WiMAX more like cellular mostly because the setup
> > times are longer, and it's mostly licensed spectrum and therefore you
> > have to deal with service providers.  There are a lot fewer variables
> > than WiFi, and users also don't expect it to act the same way as WiFi.
> 
> Actually the number of variables is hugh. However OMA-DM suppose to  
> automate this for us. We will see how good that works out once this  
> hits the real market.

Well, the variables that the provider might push down via OMA-DM are
huge, but from a hardware perspective, it's a lot simpler than WiFi for
a few reasons:

1) There aren't as many tunables exposed by drivers/hardware yet
2) The authentication process is quite standardized and you have nowhere
near the # of permutations of encryption/auth that WiFi has
3) There only so many service providers a user can choose, they don't
expect to connect to the coffee shop down the street or their public
library, because WiMAX simply isn't used there

The non-user-visible variables are quite numerous, but yes, OMA-DM will
hide most of that for us, and hence neither NM or the user will have to
care much.

> >> 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).
> >
> > Yeah, scanning on-the-fly is definitely not going to happen for WiMAX,
> > just like it doesn't happen for cellular.  They are quite similar in
> > that way.
> >
> >> 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.
> >
> > I looked into the BT stuff in detail late last year; I put most of my
> > comments in the gnome.org bug report in which you also replied.   
> > Unless
> > something has changed with Bluez there, I think the general  
> > architecture
> > I advocated there is still the right way to go.
> 
> We are moving towards BlueZ 4.0 with a lot simplified D-Bus API.  
> However in the end you have to trust that BlueZ is doing the right  
> thing. For Network Manager 0.7 is should be quite easy to read the  
> configured access points from BlueZ and then add them to the applet  
> list. In a month or so, we should finally have the Bluetooth wizard in  
> place that allows you to setup Bluetooth access points (new 4.0 API  
> makes this finally possible).

Using the configuration stored in the user session, NetworkManager would
ask BlueZ what other bluetooth things were available (phones, PAN
networks, etc), and then tell BlueZ to set up the right connection.  The
interaction model will be essentially how wpa_supplicant is used now.
BlueZ will be the backend controller of the bluetooth hardware, and
allow NM to connect to networks/objects/etc using user-specified
parameters.  There shouldn't be any need for BlueZ configuration files,
as all of the necessary configuration for a specific DUN or PAN
connection would be sent to BlueZ by NetworkManager.

The bug about BT support is:

http://bugzilla.gnome.org/show_bug.cgi?id=432774

Comments #12 and #17 are somewhat relevant.  If my phone is on and
enabled, and I have paired my phone with my laptop, NM should show the
available connections through the phone in the menu.  When I choose
"Sprint" from the applet menu, for example, NM would then ask bluez to
connect to the phone, then create whatever serial device is required,
then NM starts up PPP on the serial device.  What would that look like
in the BlueZ API?

The diagram here:

http://wiki.bluez.org/attachment/wiki/Network/Network-CreateConnection.png?format=raw

looks more or less like what I'm thinking of, where the core
NetworkManager daemon is the "NetworkWizard" piece.

Dan

> >> 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.
> >
> > Yeah, I don't know enough about UWB yet.  Need to learn more before I
> > can say _anything_ about it.
> 
> The good thing is that IOGear and D-Link are now finally selling  
> products and the Inaky and the guys from INdT got the IOGear working.
> 
> >>> 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.
> >
> > Great.  Thanks for making it all D-Bus accessible :)
> 
> If you wanna have fun, then find my comment about D-Bus from 3 or 4  
> years ago. I did change my mind about D-Bus :)
> 
> Regards
> 
> Marcel
>