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.