Re: settings daemon D-Bus interface proposal

[Dan Williams <dcbw redhat com>]

On Tue, 2007-02-20 at 16:44 +0200, Tambet Ingo wrote:
> On Tue, 2007-02-20 at 08:49 -0500, Dan Williams wrote:
> > 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?
> 
> It would be very nice if it weren't root. If nobody isn't trusted
> enough, maybe some other dedicated user, something that could be shared
> with hal policy daemon etc (which I know nothing about). Would make a
> lot of security-(paranoid-)people happy.

I feel somewhat uneasy about making it 'nobody', but it doesn't have to
be root if we can more or less guarantee that a user can't arbitrarily
overwrite the settings the the system settings daemon pushes to NM.  NM
runs with privileges, and if there is a way to subvert the system
settings daemon, then there is a way to subvert NetworkManager by making
it connect to hostile networks.  If the system settings daemon specifies
a connection, then the user cannot override that connection.

> > 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.
> 
> Why do we want to do this? Because of the GConf dependency? In my
> opinion the settings daemon belongs much more to the core NM than
> NM-gnome, there's no desktop specific bits in it at all (it doesn't even
> have any UI or regular user who'd ever log in).

Because the code to read GConf and push the settings to NM has to be in
the Gnome applet already, and it would be a shame to write that all over
again but differently for the system settings daemon.  Code re-use, plus
using GConf gives us live updates and a fairly nice structured method of
storage, in the same format as the user session (for consistency).

> I'd suggest using a simple GKeyFile-based configuration mechanism for
> the daemon for now. There are a lot of people interested in moving GConf
> down the stack, either below glib or maybe into glib, so it will happen
> sooner or later.

The system settings daemon could read from LDAP or somewhere else too,
and since the settings are already in GConf at the user level, why not
have them in GConf for the system settings daemon?  The only argument
against that is for servers that don't install GUI environments.  I'm
not trying to make the system settings daemon cross-DE at all, since
distros and DEs will probably do as they like regardless of what we do
upstream.

I personally think storing this stuff in text files in /etc is icky and
I don't really want to return to that for desktops.  That's fine for
servers with no UI though, and in that case people can install a
different system info daemon that's not the applet and
edit /etc/sysconfig/foo with their favorite text editor.

We're already storing user data in GConf, we'll have already written the
code to go from GConf -> NM, so why do it twice, especially for a
use-case that we are not going to support right now?  Eventually we want
to fully support the non-GUI server use-case, but that's not our target
right now.

> Does this new settings code mean that most of the backends (more
> precisely, the information reading from /etc/sysconfig part) is now
> deprecated? If no, which information does the NM prefer, the new daemon
> or the distro specific?

Yes.  Anything in src/backends that parses distro config files would go
away.  The point of the stuff in src/backends was to kludge some manner
of system-wide configuration into NM before we had a sane system-wide
configuration framework.

Most distro's textual config file formats can't deal with things like
WPA Enterprise, PEAP, TTLS, etc, anyway.  When you factor in other stuff
like PPP and Bluetooth DUN and GPRS, it's going to be completely
_insane_ to try and parse current distro config files in 50 different
places spread all over the file system.

Yes, this means that config tools will need to speak a different format
or at least know how to write config to the places that the system
settings daemon is pulling config from.  The settings daemon is
abstracted away from NM specifically for the purpose of making NM not
care what format the config info is stored in.

One consequence of this is that we need to take a look at how this
integrates into various distributions configuration schemes and how
those schemes will have to change.  It may be the case that distros will
end up patching the system settings daemon for better distro
integration, and that's fine.  Or, we figure out a more flexible way for
the system settings daemon to read config, or distros can make their own
settings daemon and not use upstreams, hence the effort at speccing this
out.

Furthermore, to publish system-wide config from the user session, there
will need to be some way for NM tools (or distro-specific ones) to
attain the right privileges to write the config and secrets to a place
readable by the system settings daemon.

Dan