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

Ok, nothing against this approach, but there are still problems not
addressed:

1) How would NM know to deny a particular transaction if that connection
is not allowed by system policy?

2) What provides that system policy and how would NM interact with it?

Basically, if we don't run a system-level "trusted" policy/info daemon
all the time, we cannot deny user-level requests because there's nothing
to base that denial off of unless NM starts parsing random files, which
I don't really want to do in NM.

If we do run a system-level policy/info daemon that stores administrator
approved settings, would NM pass transaction requests off to it for
approval?  If not, then NM still has to pull information from the
system-level daemon to be able to allow/deny requests from user-level
daemons, leading to policy in NetworkManager.

There's nothing wrong with having some random user-level process push
info or make arbitrary connection requests of NetworkManager, but we
have to have allow/deny those requests based on administrator policy (if
any).  We also need something to push system-wide settings down to,
because we cannot trust a user-level client to reliably report those to
NM.

There fundamentally needs to be a two-level hierarchy.  There are
user-level bits on top that can make requests to activate/deactivate
particular connections, and there is a system-level policy thing beneath
that allows/denies those requests, and can also impose policy of its
own.

However, for the near-term (ie, 0.7) we need to get something off the
ground fast, which means not redoing the whole infrastructure right now.
I agree in principle that we should be going in the less-policy-in-NM
direction.

The more I think about it, the more I believe we should stick with my
proposal for 0.7 and then move in the direction you've advocated for the
next major release.  The reason being that we want to do 0.7 fairly
quickly, and we don't want to take on more than we've already got.  Does
that sound OK?

Dan

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