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@xxxxxxxxx > > <mailto:sebelk@xxxxxxxxx>> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
