On Sun, 2012-08-19 at 19:26 +0200, Christoph Anton Mitterer wrote: [...] > 1) In parts it has some security issues. > - At least the default setting seems to be that any user can connect to > any network. [...] According to README.Debian: To allow users to connect to the NetworkManager daemon they have to be in the group "netdev". > - At least the network connections from /etc/network/interfaces are > exported to the normal user, even if that user cannot read that file. > A typical example is that I put in network connections that the normal > user should not be able to enable, or even connections that require > credentials in /etc/network/interfaces. > So NM should only export a connection, if the user would be able to read > the necessary config files. The capability to *use* credentials is separate from the capability to *read* the credentials. (Also, the design choice to read credentials from a file that is world- readable by default is incredibly stupid, and you may wish to report bugs on the packages that do that.) > 2) NM's design seems to be wrong. > AFAIU (I didn't look into too much depth, though), NM is based on the > design idea, that it replaces all network management and configuration > from the respective distros. I don't think that was the original intent at all. However it is gradually being extended to manage more types of device. [...] > In my opinion, NM should: > - export any connections from the real canonical places > (e.g. /etc/network/interfaces, /etc/vpnc/*, /etc/ppp/peers/* > and /etc/chatscripts/*, /etc/ipsec.conf and /etc/ipsec.d/*, etc. pp.) > - only if a user doesn't find something there, a per user connection > configuration should be set up. > - I know, NM supports system wide configuration, too, but IMHO that > should be dropped altogether and NM should also not try to edit the real > canonical configuration. > If someone want's a system wide IPsec connection, that should e.g. go to > strongswan's /etc/ipsec.conf. You seem to be asking for an awful lot of integration work within NM itself, which means divergence from upstream. > 3) ifupdown integration is really bad > ifupdown is really a good framework, it offers hooks and and is properly > integrated in many packages. ifupdown *was* a good framework, but Linux moved on. ifupdown doesn't know anything about interface state. It doesn't know whether hooks succeeded and it can't check for failures because that would be an incompatible change (#547587). Yes, we have a large investment in ifupdown. But the result is still not good, and we don't get much help with this from other distributions. [...] > d) when I disable wireless in NM it really blocks it, so I can't use it > with ifupdown. Now one can rfkill unblock then... but why? and even if > one does...NM seems to get confused again. If you say 'disable wireless', why are you surprised that it does what you say? I think it uses rfkill because that may save more power. > 4) upstream more or less doesn't want to support these scenarios... > Already many months ago, I've opened a Debian bug, that some /e/n/i > connections are simply not shown by NM. > Given that this is actually an upstream issue, I've reported this (and > most other problems I've mentioned before, especially the poor ifupdown > integration but also the ideas about adding support for all the > canonical configurations) upstream. > I guess the conclusion is: "this won't be implemented". > > It seems the "desired" scenario for NM is that /e/n/i is empty and I suspect so. > everything is handled Apple™ like: hide-everything, don't support > advanced setups. I don't think this is the direction upstream is going in. Instead, it's adding more support for advanced setups. [...] > So what are the opinions of the others? Will we continue to live with > the current disease? Are the alternatives better integrated? Could we > get discourage NMs use if necessary? > Or will we just mothball ifupdown silently and slowly (as it's replaced > by NM). I would really like to see Debian developers working to improve Network Manager so it can replace ifupdown. For example, improving the command line interface and support for various types of software devices. Unfortunately, I don't have the spare time to make much of a contribution to that myself. (I do install ifupdown hooks as part of ethtool, so I'll have to think about those.) Ben. -- Ben Hutchings I say we take off; nuke the site from orbit. It's the only way to be sure.
Attachment:
signature.asc
Description: This is a digitally signed message part