[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning

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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: