From unknown Tue Jun 17 22:27:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#52904: nmtui - user authorisation Resent-From: raingloom Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Thu, 30 Dec 2021 19:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 52904 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Paul Jewell Cc: 52904@debbugs.gnu.org, help-guix@gnu.org X-Debbugs-Original-Cc: Guix Bugs , help-guix@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.164089114228106 (code B ref -1); Thu, 30 Dec 2021 19:06:02 +0000 Received: (at submit) by debbugs.gnu.org; 30 Dec 2021 19:05:42 +0000 Received: from localhost ([127.0.0.1]:54484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n30k9-0007JF-EI for submit@debbugs.gnu.org; Thu, 30 Dec 2021 14:05:41 -0500 Received: from lists.gnu.org ([209.51.188.17]:60112) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n30k4-0007Iy-OE for submit@debbugs.gnu.org; Thu, 30 Dec 2021 14:05:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n30k1-00055a-GP; Thu, 30 Dec 2021 14:05:34 -0500 Received: from mx1.riseup.net ([198.252.153.129]:48168) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n30jy-0007zO-Nj; Thu, 30 Dec 2021 14:05:33 -0500 Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4JPyQb48KnzF4jc; Thu, 30 Dec 2021 11:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1640891127; bh=Av4G8I8Q9CNSkmQDdrnYYBiE2yUUVfNM5N2f84z+GPU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=JWcMDWDxvlfy/HH+5Cx1LGrbwdEHGaGpSY4NpbLPGpYXKpgNt4VmStCdMuft28QE5 nJ9GRhwiDhefT/FSwYta92c5F8IUWT16gsYkQUqQ2C6dw7JwVFrW+bYNJ9ovkaUzuY L/Vs/D7/ux2rCA9b9g0S62+NyzF47vnjgaVZCAUg= X-Riseup-User-ID: A1A6692171F8607A94E7F07214466A83644DE7BA318A86FF595B91F8367215A2 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4JPyQZ4hC3z1xmv; Thu, 30 Dec 2021 11:05:26 -0800 (PST) Date: Thu, 30 Dec 2021 20:00:23 +0100 From: raingloom Message-ID: <20211230200023.7aec38ae@riseup.net> In-Reply-To: References: <0f941db1-51a5-b579-7f2c-7333057cb402@teulu.org> <6404264d-e6c9-831c-9e5f-8327488201eb@teulu.org> <20211229015029.7f75bb7b@riseup.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=198.252.153.129; envelope-from=raingloom@riseup.net; helo=mx1.riseup.net X-Spam_score_int: -8 X-Spam_score: -0.9 X-Spam_bar: / X-Spam_report: (-0.9 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) On Wed, 29 Dec 2021 11:04:39 +0000 Paul Jewell wrote: > On 29/12/2021 00:50, raingloom wrote: > > On Tue, 28 Dec 2021 18:39:52 +0000 > > Paul Jewell 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 From unknown Tue Jun 17 22:27:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#52904: nmtui - user authorisation Resent-From: Josselin Poiret Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 31 Dec 2021 18:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52904 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: raingloom , Paul Jewell Cc: help-guix@gnu.org, 52904@debbugs.gnu.org Received: via spool by 52904-submit@debbugs.gnu.org id=B52904.16409761068536 (code B ref 52904); Fri, 31 Dec 2021 18:42:02 +0000 Received: (at 52904) by debbugs.gnu.org; 31 Dec 2021 18:41:46 +0000 Received: from localhost ([127.0.0.1]:57457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n3MqY-0002Dc-Bo for submit@debbugs.gnu.org; Fri, 31 Dec 2021 13:41:46 -0500 Received: from jpoiret.xyz ([206.189.101.64]:46320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n3MqW-0002DS-9Y for 52904@debbugs.gnu.org; Fri, 31 Dec 2021 13:41:44 -0500 Received: from authenticated-user (jpoiret.xyz [206.189.101.64]) by jpoiret.xyz (Postfix) with ESMTPA id DBADC184F27; Fri, 31 Dec 2021 18:41:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpoiret.xyz; s=dkim; t=1640976102; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=A+Y2Is+FZapC0USfgaEG+IAzRTb5FU/9kFUv15ks+fQ=; b=FJgoGmj40J88APbRlDZMt5n3cjgkagKt15CkZFK8ZaxOKz3PkYTpV0g1aS6IyoH/UDaO+L jhS6ortA8MpLrnbR3/BYPc4vIxY0QKQl1JYQYWYqgUKAVNOdIqisfEOVm+F9hVbIz9rPQu +XbUetgTIrnTJZqELPh3F9RjRrHFy+qMGC479uNIbMmAObgJRPcTuyP3Y0QIf0ghL6oqBJ ZheBOwDOcgknj4RROa8EJGCQUfJIgc9jaRkXVGrA8jt1iKOQyWrkyEWPJIX+vh44bsF8Rs eetKHe3sj0qJtGJXc3WBT1RF5MYRF/mYr8BRWYknKbl7LmobWLtopxqZdB1gkg== From: Josselin Poiret In-Reply-To: <20211230200023.7aec38ae@riseup.net> References: <0f941db1-51a5-b579-7f2c-7333057cb402@teulu.org> <6404264d-e6c9-831c-9e5f-8327488201eb@teulu.org> <20211229015029.7f75bb7b@riseup.net> <20211230200023.7aec38ae@riseup.net> Date: Fri, 31 Dec 2021 19:41:40 +0100 Message-ID: <878rw0fwgr.fsf@jpoiret.xyz> MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: / Authentication-Results: jpoiret.xyz; auth=pass smtp.auth=jpoiret@jpoiret.xyz smtp.mailfrom=dev@jpoiret.xyz X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello, raingloom writes: > On Wed, 29 Dec 2021 11:04:39 +0000 > Paul Jewell wrote: > >> On 29/12/2021 00:50, raingloom wrote: >> > On Tue, 28 Dec 2021 18:39:52 +0000 >> > Paul Jewell wrote: >> [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: jpoiret.xyz (xyz)] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello, raingloom writes: > On Wed, 29 Dec 2021 11:04:39 +0000 > Paul Jewell wrote: > >> On 29/12/2021 00:50, raingloom wrote: >> > On Tue, 28 Dec 2021 18:39:52 +0000 >> > Paul Jewell wrote: >> [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: jpoiret.xyz (xyz)] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Hello, raingloom writes: > On Wed, 29 Dec 2021 11:04:39 +0000 > Paul Jewell wrote: > >> On 29/12/2021 00:50, raingloom wrote: >> > On Tue, 28 Dec 2021 18:39:52 +0000 >> > Paul Jewell 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. -- Josselin Poiret From unknown Tue Jun 17 22:27:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#52904: nmtui - user authorisation Resent-From: Josselin Poiret Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sun, 02 Jan 2022 11:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52904 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Paul Jewell , raingloom Cc: help-guix@gnu.org, 52904@debbugs.gnu.org Received: via spool by 52904-submit@debbugs.gnu.org id=B52904.164112163119132 (code B ref 52904); Sun, 02 Jan 2022 11:08:01 +0000 Received: (at 52904) by debbugs.gnu.org; 2 Jan 2022 11:07:11 +0000 Received: from localhost ([127.0.0.1]:59961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n3yhj-0004yV-2I for submit@debbugs.gnu.org; Sun, 02 Jan 2022 06:07:11 -0500 Received: from jpoiret.xyz ([206.189.101.64]:40448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n3yhg-0004yL-PZ for 52904@debbugs.gnu.org; Sun, 02 Jan 2022 06:07:10 -0500 Received: from authenticated-user (jpoiret.xyz [206.189.101.64]) by jpoiret.xyz (Postfix) with ESMTPA id 895E1184F2B; Sun, 2 Jan 2022 11:07:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpoiret.xyz; s=dkim; t=1641121627; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CKm2gG1o+8dYl6zOydls8sm5fkDl0njUhpW3Ucwpaic=; b=sT3Js3OIoxaxJqlHKoBcVcL2ut8ffs5QZl1JQjUUMuy+vTaRxdM+jcy1OqarpmIATuYXJP I7nJUQ0bV7mEMlIa2bOV+NZsbBnT9Eud/cSVrtaWK9lYz9A3Qa0alRhEyAM4cXuSsl2rvF n75KsKiz0U879U5+/9kt6BTVgXN8AFrEiQtK/WEImdV3T9dJ443qK3VzYvtcsmWP3D/3iU e9EyKICC/WPTzX4WDoolznReOaT9SNU+VzshmFwLt8PSwehP5l/3CexeH5XHcWOKw1dsju FdzQFW/pPpIoUZDI9huWaS4RC/y+nY0dow7JhOAnmZUTJnvMXVfUT0TbS/I75A== From: Josselin Poiret In-Reply-To: References: <0f941db1-51a5-b579-7f2c-7333057cb402@teulu.org> <6404264d-e6c9-831c-9e5f-8327488201eb@teulu.org> <20211229015029.7f75bb7b@riseup.net> <20211230200023.7aec38ae@riseup.net> <878rw0fwgr.fsf@jpoiret.xyz> Date: Sun, 02 Jan 2022 12:07:05 +0100 Message-ID: <875yr2flba.fsf@jpoiret.xyz> MIME-Version: 1.0 Content-Type: text/plain X-Spamd-Bar: / Authentication-Results: jpoiret.xyz; auth=pass smtp.auth=jpoiret@jpoiret.xyz smtp.mailfrom=dev@jpoiret.xyz X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello again, > 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 runni [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: jpoiret.xyz (xyz)] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hello again, > 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 runni [...] Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 2.0 PDS_OTHER_BAD_TLD Untrustworthy TLDs [URI: jpoiret.xyz (xyz)] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD 1.0 BULK_RE_SUSP_NTLD Precedence bulk and RE: from a suspicious TLD -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Hello again, > 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. Some context is missing from the forwarded mail, so I have no idea what script you're trying to run or how, unfortunately. Here is some more information though: * there are generally two (or more) dbus daemons running. One for the system bus, launched through Shepherd (named `dbus-system`), and one for each session, for the session bus, started either manually or often through your DM (ie. GDM). elogind and NetworkManager both run on the system bus. * for Polkit to successfully reauthenticate you, it needs to have a registered agent running. A Polkit agent is a program that registers with Polkit via dbus, is associated with a session, and is used by Polkit to prompt the user for a password. There are many, see [1]. You can test whether the agent is properly set-up by simply running `pkexec echo "Hello"`, pkexec being roughly the equivalent of `sudo`, but using Polkit for permission checking. [1] https://wiki.archlinux.org/title/Polkit#Authentication_agents -- Josselin Poiret From unknown Tue Jun 17 22:27:52 2025 X-Loop: help-debbugs@gnu.org Subject: bug#52904: nmtui - user authorisation Resent-From: Paul Jewell Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 03 Jan 2022 08:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52904 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Josselin Poiret , raingloom Cc: help-guix@gnu.org, 52904@debbugs.gnu.org Received: via spool by 52904-submit@debbugs.gnu.org id=B52904.164119813727544 (code B ref 52904); Mon, 03 Jan 2022 08:23:02 +0000 Received: (at 52904) by debbugs.gnu.org; 3 Jan 2022 08:22:17 +0000 Received: from localhost ([127.0.0.1]:34068 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n4Ibe-0007AA-R6 for submit@debbugs.gnu.org; Mon, 03 Jan 2022 03:22:16 -0500 Received: from purple.birch.relay.mailchannels.net ([23.83.209.150]:28488) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n3xEj-0006Rh-PK for 52904@debbugs.gnu.org; Sun, 02 Jan 2022 04:33:11 -0500 X-Sender-Id: instrampxe0y3a|x-authuser|paul@teulu.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BEB5862237E; Sun, 2 Jan 2022 09:33:08 +0000 (UTC) Received: from cpanel-008-lon.hostingww.com (unknown [127.0.0.6]) (Authenticated sender: instrampxe0y3a) by relay.mailchannels.net (Postfix) with ESMTPA id 8D98362124C; Sun, 2 Jan 2022 09:33:07 +0000 (UTC) X-Sender-Id: instrampxe0y3a|x-authuser|paul@teulu.org Received: from cpanel-008-lon.hostingww.com (cpanel-008-lon.hostingww.com [35.177.91.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.97.65.167 (trex/6.4.3); Sun, 02 Jan 2022 09:33:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: instrampxe0y3a|x-authuser|paul@teulu.org X-MailChannels-Auth-Id: instrampxe0y3a X-Bitter-Supply: 4c41a56f03013acd_1641115988593_3070161023 X-MC-Loop-Signature: 1641115988593:748913456 X-MC-Ingress-Time: 1641115988593 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=teulu.org; s=default; h=In-Reply-To:Subject:From:References:Cc:To:MIME-Version:Date: Message-ID:Content-Type:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fSJCT/v/2ovCf2YoD3Nwdm7HsXHOk9K8u5BUtX+soBU=; b=LrEnS/jT9GSW67WdaKHtaKdzeG j0a5qKQmq48nNVjA9M/gTpp4oRduW59ELqTrGtf89iOOhL6SpWeLENKEyGeMXtmho7w8x8fkK6ck7 y3/P4ElYTERTTPRWYBfcu9BK9qjPxX3FL597w8sbt0oXKg1wuvlkC+jWk0kTw32XfkafbxxL8p9xv kua/yzlwVMAeBHau/dpAM+ZATbN38cB4u7Ffcbxj/LdKQTn5dHmPFcEy1wAXoFmqpDBwXlcwTL1ig FzOObsHb83lWrCZtsjSlz64nSlSK6mevUwPsR71EK27zU2zsFAjmwmrxrAoA9UdrGAIgOnD0PbVTg JDCZ7Hcg==; Received: from 67.26.169.217.in-addr.arpa ([217.169.26.67]:59864 helo=[192.168.1.161]) by cpanel-008-lon.hostingww.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1n3xEa-0004Cd-AV; Sun, 02 Jan 2022 20:33:05 +1100 Content-Type: multipart/alternative; boundary="------------FW0iflDrMRKwv3saKeM6hb7r" Message-ID: Date: Sun, 2 Jan 2022 09:32:58 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-GB References: <0f941db1-51a5-b579-7f2c-7333057cb402@teulu.org> <6404264d-e6c9-831c-9e5f-8327488201eb@teulu.org> <20211229015029.7f75bb7b@riseup.net> <20211230200023.7aec38ae@riseup.net> <878rw0fwgr.fsf@jpoiret.xyz> From: Paul Jewell In-Reply-To: <878rw0fwgr.fsf@jpoiret.xyz> X-OutGoing-Spam-Status: No, score=-1.0 X-AuthUser: paul@teulu.org X-Spam-Score: 0.9 (/) X-Mailman-Approved-At: Mon, 03 Jan 2022 03:22:13 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) This is a multi-part message in MIME format. --------------FW0iflDrMRKwv3saKeM6hb7r Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 31/12/2021 18:41, Josselin Poiret wrote: > Hello, > raingloom writes: > >> On Wed, 29 Dec 2021 11:04:39 +0000 >> Paul Jewell wrote: >> >>> On 29/12/2021 00:50, raingloom wrote: >>>> On Tue, 28 Dec 2021 18:39:52 +0000 >>>> Paul Jewell 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. --------------FW0iflDrMRKwv3saKeM6hb7r Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 31/12/2021 18:41, Josselin Poiret wrote:
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.

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.


--------------FW0iflDrMRKwv3saKeM6hb7r--