Re: settings daemon D-Bus interface proposal
On Mon, 2007-02-26 at 16:44 -0500, Dan Williams wrote: 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? Yeah, I agree. We should get 0.7 out as soon as possible. There are simple workarounds for the issues (vpn connections from other users, etc) David pointed out. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: settings daemon D-Bus interface proposal
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
Re: settings daemon D-Bus interface proposal
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,
Re: settings daemon D-Bus interface proposal
On Fri, 2007-02-23 at 12:03 -0500, David Zeuthen wrote: So, the ID is about identifying the connection and is a hint that a client should or should not reply to NeedInfo. The cookie (bad name probably) is a way to make sure they can't. s/connection/transaction/ fwiw. Perhaps it would be nicer to call them transaction_id transaction_secret as the word cookie is super overloaded as is. David ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: settings daemon D-Bus interface proposal
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
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
settings daemon D-Bus interface proposal
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?
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.
We can use the same D-Bus interfaces between the normal user-level
settings service (i.e., nm-applet) and the system settings service,
since the data they are passing is actually the same format.
Service: org.freedesktop.NetworkManager.Settings.System
Path:/org/freedesktop/NetworkManager/Settings/System
And for the user-level settings service run from the login session:
Service: org.freedesktop.NetworkManager.Settings.User
Path:/org/freedesktop/NetworkManager/Settings/User
One problem is that .Settings overlaps with the 'settings' object
described below, but using .Config or .Preferences just doesn't
sound right. I think .Settings is probably best. Thoughts?
m = method, s = signal
Base Object
-
interface: org.freedesktop.NetworkManager.Settings
m ListConnections(out connections 'ao')
- Returns the object paths of known connections
s NewConnection(out connections 'o')
- Signals that a new connection object has been created
Connection Object
-
interface: org.freedesktop.NetworkManager.Settings.Connection
path: /org/freedesktop/NetworkManager/Settings/Connection/id
(path can be arbitrarily defined by the settings daemon)
m GetID(out id 's')
- returns the connection id. If NM doesn't store the secrets
then we won't need this, but if NM does store the secrets,
NM will need some unique identifier for each connection that
it can use to find the secrets on the filesystem
m GetSettings(out settings 'a{sa{sv}}')
- returns a dict of settings dictionaries in the format
sort of described here:
http://live.gnome.org/NetworkManagerConfiguration
Note that the Conceptual Diagram shown there is not how
the data will actually be represented in the dict of dicts.
Each settings object will have a well-known name which
is used as its key in the outer dict, and the key names and
value types of each member of the settings object will also
be well-known. We will spec these well-known things out.
m GetSecret(in setting-name 's', out secret 'ay')
- NM calls this method to request the secret for a specific
settings dict from the settings daemon (either system or user)
Replaces getKeyForNetwork(). Different settings objects may
require different secrets, so we need the ability to request
settings from each secret individually as necessary.
s Updated(settings 'a{sa{sv}}')
- Signals that the connection object's settings have changed,
and passes the entire dict of settings dicts. It is NM's
responsibility to determine what's changed and take appropriate
action as necessary.
s Removed()
- Signals that the connection object has been deleted by the
settings daemon and that it is no longer valid. NM should
dispose of the connection object and associated memory
and no longer call any method of it. NM may also need to
disconnect if this connection is currently in-use.
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: settings daemon D-Bus interface proposal
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. 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). 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. 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? The API itself looks good to me. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: settings daemon D-Bus interface proposal
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
