Re: settings daemon D-Bus interface proposal

[David Zeuthen <davidz redhat com>]

Hi,

So I have one beef with this proposal and that is that it builds upon
the same idea of a NetworkManagerInfo-ish service. As you might know,
one of the features we're doing for Fedora 7 is fast user switching;
it's basically done with what we have in Rawhide. There's one slight
problem with NetworkManager though - consider this screenshot where "Tom
Ripley" is a user I just created

 http://people.freedesktop.org/~david/nm-with-fus.png

In the background (on another VT) I have my normal desktop running as
user davidz and since this one was the first to start, the nm-applet
instance running for davidz gets to tell the system-wide NetworkManager
daemon what connections to use. This is somewhat broken (but still
probably good enough for Fedora 7).

So wouldn't it be a lot nicer to do this the traditional way where only
NetworkManager is the server / mechanism (doesn't specify any policy
whatsoever) and each client doesn't need to own any services? 

Notably, you wouldn't need NM to keep state like "these are the VPN
connections I can connect to" (or keep these for N users all logged in
at the same time); that would solely be in the client.

For things like secrets NM would emit signals whenever it need more
secrets when doing a transaction on behalf of a client. So it would look
like this

   client (e.g. nm-applet)                   server (NetworkManager)

    Decides to connect to a network

            ------ method: TransactionBegin (details) ------>
            <-- return: transaction id, transaction cookie --

                                                  does stuff; ugh need
                                                  some secret. Looks up
                                                  in system-wide secret
                                                  store (/var/blah);
                                                  if there continues;
                                                  otherwise:

               <-- signal: NeedInfo(id, details) -----

      Looks up gconf
      for stuff; asks
      user

            -- method: ProvideInfo (id, cookie, details) -->
                     <--- return: void ---

           <-- signal: TransactionComplete(id, success) -----


and so forth. NetworkManager would still maintain state such as what
interfaces are available, what state they are in and so forth. But it
wouldn't know *anything* about user settings such as what VPN
connections some user have or how he wants to obtain IP adresses. It
would be a pure mechanism. All the logic would be in the client (aka
policy manager, e.g. nm-applet and friends).

On Tue, 2007-02-20 at 08:49 -0500, Dan Williams wrote:
> Proposal:
> 
> The system settings service (what we were calling NMI) will run either
> as 'nobody' or 'root' (I'm not sure yet, thoughts?).  Something will
> have to start it, either NM or the startup scripts.  It provides the
> default/mandatory settings that users have published system-wide or that
> the sysadmin has set.  I'm somewhat afraid that if we run it as 'nobody'
> that we'll not be able to trust the information we get out of it because
> it's not root.
> 
> If we run the system settings service as 'root', then it can access the
> system-wide published secrets and then NM doesn't have to contain code
> to read the secrets in some lookaside directory.  If it's run as
> 'nobody' then NM would have to store them.  Your thoughts David?

I think NM should consult system-wide secrets somewhere in,
say, /var/lib/NetworkManager/secrets.d. These would be in a textual
format so it's easy for administrators to create RPM's or whatever for
distribution of e.g. corporate WEP/WAP keys or whatever.

In particular I don't see why it's useful to have this come from the
daemon since at least nm-applet will use gnome-keyring (or some other
store for secrets) exclusively to get these and this, by definition,
requires user interaction e.g. someone needs to unlock the keyring and
that will require human intervention e.g. password entry.

> This Gnome system settings daemon will be a copy of nm-applet and will
> be run with the '--system' argument, which tells the applet to present
> _no_ UI, not init GTK, and acquire the system settings service name
> rather than the user-level settings service name.

Right, I think recycling the policy manager is a good idea as we do need
some policy manager running when no-one is logged in / server use. 

Note that with ConsoleKit, NM can now identify the seat, session,
session_is_active [1] a call from a client originates from. Hence, doing
this is easy. When no-one is logged in we accept input from the system
policy manager; when there are sessions logged in NM can reject method
calls from policy managers in inactive sessions.

So all in all I think that NM needs this architectural change to cope
with f-u-s and other things. It might be a bit more work but I think a
much clearer separation between *mechanism* and *policy* is worth it in
the long run. In particular, to rehash, I don't see *why* NM needs to
query all the settings from the user session when the user session can
pass them when making the connection.

    David

[1] : session_is_active means "session is now visible". This is used in
HAL to deny service to inactive desktop sessions for fast-user-switching
since precisely one session can be active at one time. It's slight
harder for multi-seat (several active sessions on multiple physical
seats [2]).

[2] : a seat is roughly defined as a "monitor, keyboard, mouse" combo