On Mon, 2012-08-20 at 02:07 +0200, Christoph Anton Mitterer wrote:
> 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.
Oops, yes, good point.
> 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?
Of course.
> 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.
This is also true if you can run a process on the machine while that
WLAN connection is up. Because the capability to use a network
connection that's already up is another thing again...
> > (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
I'm saying that reading credentials from /etc/network/interfaces is
probably a bug. In the 'bug' script for Linux kernel packages we have
this filter:
# Hide passwords/keys
awk '$1 ~ /key|pass|^wpa-(anonymous|identity|phase|pin|private|psk)/ { gsub(".", "*", $2); }
$1 == "ethtool-wol" { gsub(".", "*", $3); }
!/^[[:space:]]*#/ { print; }
' </etc/network/interfaces >&3
I can't remember quite how I came up with this list... I assume the
wpa-* fields were previously used by wpa_supplicant hooks, but that
doesn't seem to be the case any more. wireless-tools still uses
wireless-key{1,2,3,4}. For ethtool-wol (wake-on-LAN) there is an
optional 'SecureOn password' for Magic Packet mode. This is a little
bit different from the others but I probably should still add the option
to read it from a separate file.
[...]
> > ifupdown *was* a good framework, but Linux moved on. ifupdown doesn't
> > know anything about interface state.
> What exactly do you mean by "state"?
ifupdown records whether an interface has been brought up using a
particular configuration (referenced by name). If you change the state
using anything other tool, it has no idea. If the driver reports a
change of state, it doesn't react. If you change or remove the
configuration, it doesn't even know how to bring the interface down
again! (That last one should be fixable, by storing the configuration
along with the 'up' state file.)
Pretty much all it does is to run a pre-defined 'up' or 'down' sequence.
Even once it can reliably report failure, I suspect it won't know how to
roll back.
> But anyway,.. it doesn't seem as if it would go away anytime soon,...
> and NM is AFAICS surely not a powerful enough replacement.
Not yet, no.
> > 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 ;-)
Yes, and I absolutely support this change. It's just a shame that it's
taken such a long to be recognised as necessary.
[...]
> > 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.
By the same token, we should have our own kernel, C library, etc.
Ben.
--
Ben Hutchings
The most exhausting thing in life is being insincere. - Anne Morrow Lindberg
can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
