From: Josselin Poiret via Bug reports for GNU Guix <bug-guix@gnu.org>
To: raingloom <raingloom@riseup.net>, Paul Jewell <paul@teulu.org>
Cc: help-guix@gnu.org, 52904@debbugs.gnu.org
Subject: bug#52904: nmtui - user authorisation
Date: Fri, 31 Dec 2021 19:41:40 +0100 [thread overview]
Message-ID: <878rw0fwgr.fsf@jpoiret.xyz> (raw)
In-Reply-To: <20211230200023.7aec38ae@riseup.net>
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
next prev parent reply other threads:[~2021-12-31 18:43 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 ` Josselin Poiret via Bug reports for GNU Guix [this message]
2022-01-02 9:32 ` bug#52904: " Paul Jewell
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=878rw0fwgr.fsf@jpoiret.xyz \
--to=bug-guix@gnu.org \
--cc=52904@debbugs.gnu.org \
--cc=dev@jpoiret.xyz \
--cc=help-guix@gnu.org \
--cc=paul@teulu.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).