Re: settings daemon D-Bus interface proposal

[David Zeuthen <davidz redhat com>]

On Fri, 2007-02-23 at 11:38 -0500, Dan Williams wrote:
> Tambet had proposed a system where the client would push all its config
> info to NM when it started up.  I assume it would then push updates to
> NM when GConf changes (or whatever KDE uses) occurred, and would fetch
> and return secrets on request.  How then would NM tell the client to
> store the correct network info when a new successful connection
> occurred?  The secret _does_ get passed back to the client using a
> method call, and is not broadcast on the bus.  We would need some
> non-broadcasting way to communicate the successful secret back to the
> client, otherwise the client has to keep a ton of state information
> around.  The "transaction" idea you proposed could solve that I guess.

Yes, I'm inherently wary about proposals that makes the mechanism
(NetworkManager daemon) know a lot of stuff about session settings
(nm-applet NMInfo) because it has a chance of leaking into other
sessions. That's a security issue and exactly what we're seeing in
Fedora 7 today after enabling f-u-s by default.

(well, it's a mild security issue so I think we're fine with shipping
with the current NM in a few months)

>From a practical point of view it also seems like a lot of extra
bookkeeping in the NM daemon if you let it keep settings from clients;
NM really should only be a mechanism and as such

 - advertise the current state - this of course depends on the
   abstraction model you want. This probably needs to be richer
   than what UNIX/Linux gives you - e.g. it's way more than just a
   a list of interfaces with associated meta data {(eth0, is_up,
   type, carried_detected), ...} if you want to do rich stuff
   like ICS and so forth. 

   That's the *tough* problem, but once you have an abstraction model
   that works, NM should only advertise it's current state and changes
   to it.

 - provide mechanisms to change current state - these are the
   transactions I talked about

 - policy should belong entirely in the client, even things
   like deciding to connect to a wired network if that's all
   you got. Depending on your abstraction model, reauthing e.g.
   wireless networks may also be initiated by the client. But
   probably not. Really depends on your abstraction model and
   where you make the cut.

 - would probably be useful with a helper library for the clients
   so nm-applet, KDE client, system-wide client basically just becomes
   the UI frontend (I think you've proposed this too)

Anyway, these are just some thoughts - hope it's useful!

     David