Package: guix;
Reported by: raingloom <raingloom <at> riseup.net>
Date: Thu, 30 Dec 2021 19:06:02 UTC
Severity: normal
Message #14 received at 52904 <at> debbugs.gnu.org (full text, mbox):
From: Paul Jewell <paul <at> teulu.org> To: Josselin Poiret <dev <at> jpoiret.xyz>, raingloom <raingloom <at> riseup.net> Cc: help-guix <at> gnu.org, 52904 <at> debbugs.gnu.org Subject: Re: bug#52904: nmtui - user authorisation Date: Sun, 2 Jan 2022 09:32:58 +0000
[Message part 1 (text/plain, inline)]
On 31/12/2021 18:41, Josselin Poiret wrote: > Hello, > raingloom<raingloom <at> riseup.net> writes: > >> On Wed, 29 Dec 2021 11:04:39 +0000 >> Paul Jewell<paul <at> teulu.org> wrote: >> >>> On 29/12/2021 00:50, raingloom wrote: >>>> On Tue, 28 Dec 2021 18:39:52 +0000 >>>> Paul Jewell<paul <at> 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. > Good morning Josselin, and Happy New Year! Many thanks for taking the time to explain this in detail for us. If I have properly understood your explanation, it suggests I am running network-manager from outside of the dbus session. If I look at the processes running on my system at this moment, the dbus-launch process has an id of 881, while the network-manager session has an id of 463, suggesting that it was started before dbus. My system configuration is relatively standard (if there is such a thing) - I don't do anything to change how dbus or network manager are launched, but rely on the defaults provided by the the desktop-service. Is there any way to ensure network-manager is launched inside the dbus session? I am using slim rather than gdm, and as a desktop manager I am using dwm (with some local changes). Regarding the wheel group - my user is in this group, but I don't get any request for a password - nmtui simply informs me that I don't have the necessary authorisation.
[Message part 2 (text/html, inline)]
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.