nmtui - user authorisation

nmtui - user authorisation

[Paul Jewell]

Good morning,

I am using dwm with network-manager for wifi setup, but the nmtui app 
doesn't allow me to make changes with a user level account. How can I 
configure it to allow a user level account to make changes to the wifi 
setup?

Thanks all!

Paul

Re: nmtui - user authorisation

[Paul Jewell]

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.

--
Paul

On 27/12/2021 07:33, Paul Jewell wrote:
> Good morning,
>
> I am using dwm with network-manager for wifi setup, but the nmtui app 
> doesn't allow me to make changes with a user level account. How can I 
> configure it to allow a user level account to make changes to the wifi 
> setup?
>
> Thanks all!
>
> Paul

Re: nmtui - user authorisation

[Leo Famulari]

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

Re: nmtui - user authorisation

[Paul Jewell]

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!

Re: nmtui - user authorisation

[raingloom]

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.

Re: nmtui - user authorisation

[Paul Jewell]

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!

nmtui - user authorisation

[raingloom]

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 

bug#52904: nmtui - user authorisation

[Josselin Poiret via Bug reports for GNU Guix]

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.

-- 
Josselin Poiret

Re: bug#52904: nmtui - user authorisation

[Paul Jewell]

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.

Re: bug#52904: nmtui - user authorisation

[Josselin Poiret]

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

Re: bug#52904: nmtui - user authorisation

[Mekeor Melire]

2022-01-02 / 12:07 / dev@jpoiret.xyz:

> 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 
n>> 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

On #guix:libera.chat, I reported Josselin that I had a similar issue as
Paul reported. Namely, I could not use e.g. `nmcli device wifi connect
foo password bar` to connect to a wifi. Instead I got a permission
error.

Josselin suggested me to install polkit-gnome and to keep
~/.guix-profile/libexec/polkit-gnome-authentication-agent-1 running
afterwards. This worked for me.

(My user is member of the netdev group.)