unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Paul Jewell <paul@teulu.org>
To: Josselin Poiret <dev@jpoiret.xyz>, raingloom <raingloom@riseup.net>
Cc: help-guix@gnu.org, 52904@debbugs.gnu.org
Subject: Re: bug#52904: nmtui - user authorisation
Date: Sun, 2 Jan 2022 09:32:58 +0000	[thread overview]
Message-ID: <b1ca579e-9828-1ef9-bc2b-19a67f0c846d@teulu.org> (raw)
In-Reply-To: <878rw0fwgr.fsf@jpoiret.xyz>

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.


  reply	other threads:[~2022-01-02  9:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-27  7:33 nmtui - user authorisation Paul Jewell
2021-12-27 22:07 ` Paul Jewell
2021-12-27 23:20   ` Leo Famulari
2021-12-28 18:39     ` Paul Jewell
2021-12-29  0:50       ` raingloom
2021-12-29 11:04         ` Paul Jewell
2021-12-30 19:00           ` raingloom
2021-12-31 18:41             ` bug#52904: " Josselin Poiret via Bug reports for GNU Guix
2022-01-02  9:32               ` Paul Jewell [this message]
2022-01-02 11:07                 ` Josselin Poiret
2022-01-02 20:42                   ` Mekeor Melire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1ca579e-9828-1ef9-bc2b-19a67f0c846d@teulu.org \
    --to=paul@teulu.org \
    --cc=52904@debbugs.gnu.org \
    --cc=dev@jpoiret.xyz \
    --cc=help-guix@gnu.org \
    --cc=raingloom@riseup.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).