Subject: bug#52904: nmtui - user authorisation

From: Paul Jewell <[email-masked]>
Date: Sun, 2 Jan 2022 09:32:58 +0000

On 31/12/2021 18:41, Josselin Poiret wrote:
> Hello,
> raingloom<[email-masked]>  writes:
>
>> On Wed, 29 Dec 2021 11:04:39 +0000
>> Paul Jewell<[email-masked]>  wrote:
>>
>>> On 29/12/2021 00:50, raingloom wrote:
>>>> On Tue, 28 Dec 2021 18:39:52 +0000
>>>> Paul Jewell<[email-masked]>   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.