Hello,
raingloom<raingloom@riseup.net> writes:
On Wed, 29 Dec 2021 11:04:39 +0000
Paul Jewell<paul@teulu.org> wrote:
On 29/12/2021 00:50, raingloom wrote:
On Tue, 28 Dec 2021 18:39:52 +0000
Paul Jewell<paul@teulu.org> wrote:
On 27/12/2021 23:20, Leo Famulari wrote:
On Mon, Dec 27, 2021 at 10:07:17PM +0000, Paul Jewell wrote:
Solved this - nmtui needs to be run as root; my script which
invoked the program didn't consider that. Changing it to run as
sudo gives me an opportunity to enter my password, and then
successfully setup the wifi interface details.
Another option is to add nmtui to the list of programs that are
setuid. That way, any user on your system could configure wifi,
which may be more ergonomic.
https://guix.gnu.org/manual/devel/en/html_node/Setuid-Programs.html
This option did work as expected. The only additional point for
anyone else coming across this post with the same issue: remember
to add the
#:use-module (gnu system setuid)
so the setuid record is known.
Thanks Leo!
Uhm, I'm pretty sure NetworkManager lets any user modify networking
settings as long as they are in a certain group?
https://wiki.archlinux.org/title/NetworkManager#Set_up_PolicyKit_permissions
At least that's how it is on postmarketOS and I'm also fairly
certain I never needed root access to set up WiFi under Guix
either, but I don't have a system at hand to verify that on.
I did also think this, but I couldn't identify which group would let
this happen. I thought it would be the netdev group, but my user
account is already a member of that group. The network group is
unknown to the system (as in I had an error when trying to add the
user to the supplementary group) so I added it, but it didn't have
any effect (after rebooting). If there is another group I should be
in, I am not sure how to find out. At the moment, the setuid approach
seems to work OK (although I would prefer a group solution!).
I am interested in anyone else's experience!
It might be that everyone else is including some default configuration
for NetworkManager and we aren't. At the very least it should be
documented how to set it up to use groups.
CC-ing bugs-guix
NetworkManager uses dbus to communicate with its root-run service, and
Polkit to check for permissions. By default, the NetworkManager actions
are pretty permissive, you can do most of them without reauthenticating,
except for a couple specific ones.
More in detail, Polkit works by looking up the PID of processes that
ask for specific actions, and then asking systemd-logind/elogind which
session that process is attached to. Then, there are three different
cases:
* the session is active (not locked, I think that means in logind
parlance). In this case, Polkit looks at the `allow_active` rule.
* the session is inactive (or locked). Then, Polkit looks at the
`allow_inactive`.
* there is no session attached to the process (possible for eg. system
services). Then, Polkit looks at the `allow_any` rule.
Now, if you look at network-manager's
/share/polkit-1/actions/org.freedesktop.NetworkManager.policy, you can
see that some actions are possible for active sessions, while impossible
for inactive sessions, or even processes not attached to the session.
So, I think the issue is that you are trying to do some actions outside
of a session, or in an inactive session, and Polkit refuses to let you
do that. I don't think there is a way to circumvent that, since there
is no `allow_any` rule for many actions, but I don't know what this
entails (if it is an implicit `no`, `auth_admin`, etc...).
Note that we have a catch-all rule defined at `polkit-wheel` in
gnu/services/desktop.scm that says that administrative users are exactly
the users in the group `wheel`. That means that when Polkit needs to
authenticate an administrative user, it will ask for your own password
if you're in the `wheel` group, but you still need to reauthenticate,
you cannot bypass that check.
I hope this clears up how Polkit works, and why the action is denied.