* bug#52904: nmtui - user authorisation
2021-12-30 19:00 ` nmtui - user authorisation raingloom
@ 2021-12-31 18:41 ` Josselin Poiret via Bug reports for GNU Guix
0 siblings, 0 replies; 2+ messages in thread
From: Josselin Poiret via Bug reports for GNU Guix @ 2021-12-31 18:41 UTC (permalink / raw)
To: raingloom, Paul Jewell; +Cc: help-guix, 52904
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
^ permalink raw reply [flat|nested] 2+ messages in thread