Re: settings daemon D-Bus interface proposal

[Dan Williams <dcbw redhat com>]

On Tue, 2007-02-20 at 20:51 -0500, David Zeuthen wrote:
> 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

I don't really like this, because then there's _no_ continuity between
the NM key request and the reply; NM has no way of tracking whether a
reply is for a specific key request.  It also means that any program can
tell NM what key it should use, not just nm-applet.  At least D-Bus
guarantees that only one copy of nm-applet can be active at any time, so
only one process can send secrets back to NM.

>    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.

For continuity.  In this model, NM is just broadcasting an "I need
secrets!" signal, and letting _anything_ in the user session return that
information.  When the thing in the user session is a D-Bus service, it
at least guarantees that only one process can return the information,
not any process at all.  Obviously a malicious program can already
'killall -9 nm-applet' and launch itself as the info-daemon and send
malicious info to NM.

Configs are inherently per-user, with some that get pushed down to
system-wide.  Any time we store information in the user session, that
information must be treated as untrusted by a more-highly-privileged
process.  We deal with that by restricting the ability to communicate
with NM to at_console, group=netdev, or user=root.

So, do we just suck up the inherent untrustability of user-side
configuration details and make double-sure that system-wide config will
override any user config and leave it at that?

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.

Dan

>     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
> 
>