tags 642136 - patch
thanks
Unfortunately, things are a little more complicated, as Michael was so
kind to explain to me on IRC. I'm trying to sum up our conversation:
GENERAL PROBLEMS
- when changing the default for new connections in one client
(nm-applet), other clients should be changed accordingly. This means
at least gnome-shell (KDE may use different defaults anyway)
- in addition to wifi connections, also VPN and mobile broadband
connections should be user-administrateable
- a system-wide connection has advantages, and upstream changed the
default for a reason / in response to user feedback. E.g. it is not
unreasonable to expect to be able to ssh into a running laptop, even
when there's nobody logged in.
MY PATCH SPECIFICALLY
- in the interest of a minimal patch, marking the connection
user-private *and* all secrets agent-owned is unnecessary;
user-private is enough. The two are orthogonal really: marking secrets
agent-owned determines whether the wifi password is stored in the
/etc/NetworkManager/system-connections/<ssid> file or handled by the
user's polkit authentication agent, whereas the user-private setting
determines whether NetworkManager.settings.modify.system privileges
are necessary and anybody but the current user can see the connection.
OPTIONS FOR A SOLUTION OF #642136
- do not change the default for new connections (system-wide), but add a
polkit rule allowing members of the netdev and sudo groups to modify
those connections. Group sudo can do everything anyway, and netdev is
specifically meant for that. In addition, the user created during
installation is automatically added to the netdev group, so that this
would solve the "annoying password prompt" issue for the
single-user-laptop case. The polkit rule would look like this:
[Adding or changing system-wide NetworkManager connections]
Identity=unix-group:netdev;unix-group:sudo
Action=org.freedesktop.NetworkManager.settings.modify.system
ResultAny=no
ResultInactive=no
ResultActive=yes
- this leaves open multi-user machines, where ordinary users should be
able to e.g. add their home wifi, without being given the additional
privileges that come with group membership (e.g., seeing the other
guy's home wifi password). Think managed laptop repeatedly borrowed to
students. Here, the system administrator could install a
gsettings-override (provided in examples) that would make user-private
connections the default. The gsetting would have to be added, as well
as code to check it and switch to user-private when configured.
- personally, I'd prefer if things would "just work", that is: a
user-private connection is created automatically if the user is not
entitled to create a system-wide one, without the need to find out
about a gsetting and install the override. Unfortunately, it is
unclear if there is a way to query polkit whether the user would need
to be asked for a password in order to execute an action with the
NetworkManager.settings.modify.system privilege, without actually
doing so.¹ An alternative would be to assume the existence of the above
polkit rule and check the user's group memberships (getgid), but that
approach is ugly because it hard-codes what is really just a default
policy, and it may require the user to re-login in order for changes
in group membership to take effect.
¹ there is a flag to polkit_authority_check_authorization to
AllowUserInteraction, which is meant e.g. to decide whether a UI
element should be displayed in an inactive style. This is exposed in
nm_auth_chain_add_call.
Would the above polkit rule plus an automatic switch to user-private
connections solve this issue for all conceiveable use cases? What about
users who would have to type the root password, but are able and in fact
expect to do so? There's always nm-connection-editor to turn a
user-private connection into a system-wide one...
too tired to not be confused,
Florian
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
