Hey Ben. On Sun, 2012-08-19 at 19:32 +0100, Ben Hutchings wrote: > To allow users to connect to the NetworkManager daemon they have to be in the > group "netdev". Like Vincent already pointed out, CK allows it, too. In principle nothing speaks generally against either of the two, but I guess both of them are just intended towards "who is allowed to connect to networks"; either by being member of the group, or by being locally logged on (CK). But when I e.g. put WPA credentials into /e/n/interfaces and made the file specifically readable by root and user foo only, then it still exports that connection to all other users (e.g. being logged on locally; at least per default). > The capability to *use* credentials is separate from the capability to > *read* the credentials. Well nevertheless, both can be dangerous already, can't it? Even if it just allows me to use (i.e. connect to) some WLAN but not giving me the actual key, I might be able to access some resources there, that ought to be secure. > (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.) I don't exactly understand what you mean :) > > 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. Well... yes ^^ ... but actually I don't want to have this in Debian only. As said, I've opened bugs for most of the above, e.g. proper integration of /etc/vpnc/* config into NM's vpnc plugin. It may however be reasonable, if the ifupdown plugins was really managed by Debian (developers) and not by some upstream developers who may or may not have the in depth knowledge to the Debian way of life. > ifupdown *was* a good framework, but Linux moved on. ifupdown doesn't > know anything about interface state. What exactly do you mean by "state"? But anyway,.. it doesn't seem as if it would go away anytime soon,... and NM is AFAICS surely not a powerful enough replacement. > It doesn't know whether hooks > succeeded and it can't check for failures because that would be an > incompatible change (#547587). Sometimes one have to break compatibility ;-) > > 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. Ah is that the case? Didn't know. Nevertheless, it seems to not handle it correctly when I manually change things or stop/start NM and things like that. > I don't think this is the direction upstream is going in. Instead, it's > adding more support for advanced setups. Well even if they do,... to me it seems that every distro keeps it's own native way of controlling networking and canonical configuration for it. Trying to duplicate this in NM is IMHO a bad way. > 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.) If all that ever happens,... fine (though I like ifupdown and personally don't see the need for replacing it),... but it's surely a long road to it.... and has the big disadvantage that we (Debian) are then more or less bound to what NM (and other distros) do. Sometimes it's good of course, having homogeneous frameworks across distros,... but this can also be bad. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature