[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#52904: nmtui - user authorisation
Re: bug#52904: nmtui - user authorisation
Fri, 31 Dec 2021 19:41:40 +0100
raingloom <email@example.com> writes:
> On Wed, 29 Dec 2021 11:04:39 +0000
> Paul Jewell <firstname.lastname@example.org> wrote:
>> On 29/12/2021 00:50, raingloom wrote:
>> > On Tue, 28 Dec 2021 18:39:52 +0000
>> > Paul Jewell<email@example.com> 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
* 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
* 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.