NetworkManager "forget" user network configurations: bug or feature?

[Dan Williams]

On Wed, 2014-03-26 at 16:57 -0300, Sergio Belkin wrote:
> El 26/03/14 12:45, Stephen John Smoogen escribió:
> >
> >
> >
> > On 25 March 2014 13:53, Sergio Belkin <sebelk at gmail.com 
> > <mailto:sebelk at gmail.com>> wrote:
> >
> >
> >
> >     Adam,
> >
> >     I've found that by default when I create a user, the checkbox in
> >     NetworkManager that says
> >
> >     "All users may connect to this network" is checked!
> >
> >     If I uncheck anyway the network configuration files are in
> >     /etc/sysconfig/network-scripts/
> >
> >     Really I don't understand this behavior (using mate-desktop on F20)
> >
> >
> >
> > I believe the reason for this is due to various users who have their 
> > home directories on network mounted systems (even if only the user is 
> > the only one to set up the network connection.) If the data was stored 
> > in the home directory then the network could not start to thus mount 
> > the home directory to get the account. A similar problem occurs if the 
> > /home is encrypted separately from the root partition.
> >
> > In general, I just make sure that /root /etc and /home are backed up 
> > when I move from OS version to OS version so that I don't lose stuff I 
> > might need later.
> > -- 
> > Stephen J Smoogen.
> >
> >
> >
> 
> Hmmm... but NetworkManager should think in desktop users (ok, somewhat 
> power desktop users) that install a new release/distro and a user 
> configuration should be completely independent. Or at least give the 
> chance to save either systemwide or "userwide". Anyway thanks for your 
> answers and ideas, I understand that all of this is somewhat Off-Topic :)

TLDR; there used to be user-session config, there isn't any more, the
reasons for that are mostly security-related, and network connections
are most global anyway (until network namespaces hits for user
sessions).  NM defaults to user-session *password* storage though, and
VPNs always default to per-user visibility.
---

NM used to have system-wide and user-wide data years ago, and it stopped
doing that for a few reasons:

1) Every single Desktop Environment (KDE, GNOME, etc) had to implement
the user data store themselves in their preferred location (gconf/dconf,
kconfig, etc); it's a massive duplication of code that's pretty
pointless.

2) User connections are not available before that user logs in, for
obvious reasons; this prevents things like network mounted user home
directories which require the user's credentials to access (because the
user session is required to ask the user for those credentials, and that
requires that the user already be logged in)

3) When the user logs out, the network connection goes away, because the
connection is private to that user and the user is no longer logged in

4) You cannot easily control access to the user data store; any
malicious program running in the user's context can manipulate
connection data which a root-level system service needs to eventually
read; this is Not Good (TM).  Things are now well-protected via
PolicyKit permissions.

5) And the Big One, which is that network connections are global to the
machine anyway, at least if you're not using network namespaces, which
nobody is using yet to isolate user login sessions.  That may be the
future, but once you've connected your "private" network connection, any
application on the machine, or any other logged in user (including Fast
User Switching users) can access those network resources.

The network connection itself is not really private, but the
*credentials* to start it are, and that's what NetworkManager lets each
user session manage.  If you choose to, you can store your passwords in
the user session's keyring, protected by your login password or keyring
unlock password.  This prevents other users from being able to start
that network connection (since they don't have the password), but also
prevents using this connection before login, of course.  User password
storage is the default for VPN, 802.1x, and WiFi connections.

Second, you can restrict NetworkManager connections to specific users,
so that your VPN connection is only ever
connectable/disconnectable/editable by your user alone.  This is the
default for VPN connections.

These two mechanisms, in concert with PolicyKit permissions, allow
administrators to lock down or open up the machine in a very flexible
manner.  By default, most users are allowed to do whatever they want,
but the ability to lock things down is a couple clicks/vims/emacs away
if that's what they desire.

To ask another question: why should most network configuration be
*private* to specific users, when the network like ethernet or wifi is a
shared network with shared passwords?

In any case, thanks for the feedback, it's always welcome, and
discussion like this is always useful!

Dan