Re: Inconsistent behaviour for non-admin users when creating new connections


On Wed, 2020-04-22 at 17:55 +0200, Michael Biebl wrote:

for a bit of backstory: in Debian we traditionally ship a strict
PolicyKit configuration for NetworkManager, which doesn't allow
non-admin users to edit system wide connections (we build NM with
--disable-modify-system, i.e. we use auth_admin_keep instead of yes)

The reason for that is, that we want to be able to ship a default
which is reasonably secure on a wide variety of setups and we didn't
want to give unprivileged users the ability to read/write/modify
connections that were not created by themselves.
At the same time, unprivileged users should be able to connect to new
WiFi networks without too much fuss (i.e. without having to enter an
admin password). This was the main motivation for the Debian patch
to nm-applet back in the days. Nowadays, we have a lot more
NetworkManager clients: Cinnamon, GNOME, KDE (plasma-nm) etc all have
native NM support.

I did a series of tests with an unprivileged users named "test" under
Debian trying to connect to a new WiFi network. Here are the results

a) GNOME Shell
admin prompt, credentials system wide, permissions=

b) gnome-control-center
no admin prompt, credentials system wide, permissions=user:test:;

c) Cinnamon
no admin prompt, credentials user wide, permissions=user:test:;

d) cinnamon-control-center
no admin prompt, credentials system wide, permissions=user:test:;

e) nm-applet 1.16.0
no admin prompt, credentials system wide, permissions=user:test:;

f) nm-connection-editor 1.16.0
admin prompt, credentials system wide, permissions=

g) nm-applet 1.8.24 (with Debian patch [1])
no admin prompt, credentials user wide, permissions=user:test:;

To my understanding, nm-applet and nm-connection-editor don't directly
run a polkit agent. Possibly they should, like nmcli does. But that
means, they cannot ask for permission, instead they rely on your
desktop environment to run a session agent which would prompt you.

Possibly that makes sense. Should really every application run its own
polkit agent?

h) nm-connection-editor 1.8.24 (with Debian patch [1])
no admin prompt, credentials system wide, permissions=user:test:;

Most interesting would also be the behaviors for nmcli and nmtui.

I think the current situation is unfortunate. Ideally, NM Clients
behave more consistently and provide a better ootb experience for
unprivileged users. I find especially a) very unfriendly for users.
In a
multi-user setup it's unlikely they have an admin password and I
NM clients should just create user-owned connections in that case.

I agree. I see you dropped patch [1] now? Possibly this should be

For nm-connection-editor and gnome-control-center, when you create a
new profile it offers you the choice. So in this case it's only
important to clear "All users may connect to this network" checkbox, if
the user has no permissions. I mean, since the GUI gives you a dialog
where you could clear setting yourself, it's less severe (but still

Whether to store credentials system wide or make them agent owned is
another topic. I guess for WiFi connections it makes sense to store
system wide, for VPN connections I would (always) default to make
agent owned.

How secret agents store the secret in the keyring is unfortunately also
not consistent and every client reimplements it (differently). e.g.
nmcli/nmtui don't support a keyring at all, while plasma-nm and
Gnome/GTK GUIs use different wallet backends. Optimally that would be
unified too (possibly by moving the functionality to a shared library).

Which credential store one wants less tied to the user's permission,

  - what kind of secret is this? E.g. I may be fine to put the
Company's Wi-Fi secret to the company notebook, but want to encrypt my
personal VPN that I setup on such a notebook. But even the distinction
Wi-Fi vs. VPN may not be enough. The GUI simply doesn't know.

  - if you configure the keyring, then autoconnect only works after the
user is available to unlock the keyring. That seems quite a
restriction, which people might not understand. On the other hand, they
users may also dislike to store passwords in plain text, and it may not
be obvious to them that that happens.

Point is, both values make sense sometimes. It's not clear to me that
the default would depend on the policy kit permissions, nor that one
default is clearly preferable over the other.

For that reason, I would like your feedback as NetworkManager

If you write on this list, *you* are upstream!!

Maybe we can come up with a set of recommendations how clients should
behave for unprivileged users in a variety of use cases (WiFi, VPN,
etc). Once we have that set of rules/recommendations, it would be
for me to contact the various upstream projects like GNOME, Cinnamon,

Sounds like a very good idea to me. Thank you for looking into this.

I would also be interested how other distros handle this situation
what there default policy is.
I know that Fedora uses --enable-modify-system, which is probably ok
your target audience is a single-user desktop system.

... or if you want that things work well out of the box :)

Regarding "single-user"... Which is probably also the common case for
debian. I mean, if a user installs Debian for him/herself, then very
often it's a single-user machine.
Sure there are companies that deployes Debian on thousands of ther
their employees notebooks, but these thousands of machines is basically
one setup, and the admin can be expected to adjust the configuration.
What I mean is, if you take the number of running Debian systems, then
maybe many of them are multi user systems. But if you look at how many
distinct installations there are (like, a manual installation on my
personal notebook or a deloymnet of 1000 company notebooks), I would
guess that the majority of installations is for single-user.

Anyway, I don't really mind.

Shouldn't we have a PolicyKit setup so that certain group get
permission (e.g. "wheel", "sudo"), while the rest requires a root

This email is already pretty long, so I'll stop here.

Looking forward to read your thoughts,


Attachment: signature.asc
Description: This is a digitally signed message part

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