org.freedesktop.NetworkManager.Settings.PermissionDenied: uid 1000 has no permission to perform this operation

srevinsaju commented 4 years ago

Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/jarabe/desktop/meshbox.py", line 506, in _ap_props_changed_cb
    self._add_ap_to_network(ap)
  File "/usr/lib/python3.8/site-packages/jarabe/desktop/meshbox.py", line 471, in _add_ap_to_network
    icon = WirelessNetworkView(ap)
  File "/usr/lib/python3.8/site-packages/jarabe/desktop/networkviews.py", line 99, in __init__
    self._update_badge()
  File "/usr/lib/python3.8/site-packages/jarabe/desktop/networkviews.py", line 234, in _update_badge
    connection = network.find_connection_by_ssid(self._ssid)
  File "/usr/lib/python3.8/site-packages/jarabe/model/network.py", line 904, in find_connection_by_ssid
    for connection in get_connections().get_list():
  File "/usr/lib/python3.8/site-packages/jarabe/model/network.py", line 896, in get_connections
    _connections = Connections()
  File "/usr/lib/python3.8/site-packages/jarabe/model/network.py", line 857, in __init__
    self._monitor_connection(connection_o)
  File "/usr/lib/python3.8/site-packages/jarabe/model/network.py", line 863, in _monitor_connection
    connection = Connection(self._bus, connection_o)
  File "/usr/lib/python3.8/site-packages/jarabe/model/network.py", line 798, in __init__
    self._settings = self._connection.GetSettings(byte_arrays=True)
  File "/usr/lib/python3.8/site-packages/dbus/proxies.py", line 72, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/python3.8/site-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
  File "/usr/lib/python3.8/site-packages/dbus/connection.py", line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.NetworkManager.Settings.PermissionDenied: uid 1000 has no permission to perform this operation

While testing sugar before the release of 0.117, I found this bug. If its a problem with my system configuration. Please advise

chimosky commented 4 years ago

You said when testing, can you tell exactly what you did?

srevinsaju commented 4 years ago

@chimosky I just started and looked at the logs. I have recreated the bug on my adjacent PC too. It is in shell.log

SanketDG commented 4 years ago

What OS are you running? You should be part of a group that would allow your user to have administrator privileges.

Also what does $ groups output for you on the shell?

srevinsaju commented 4 years ago

sys network power lp audio wheel ss

It is not mentioned, that I need root permissions for running sugar. Someone please clarify

quozl commented 4 years ago

@srevinsaju. We have relied on the default configuration of Network Manager on Fedora and Ubuntu distributions. From other discussions, I understand you use Arch Linux. I suggest comparing the configurations of Network Manager between your Arch Linux system and those other systems. Arch Linux maintainers may have a very good reason for using a different configuration, so change the configuration with care. You might also try to reproduce the problem without using Sugar, instead by using the nmcli binary, across Arch Linux, Fedora, and Ubuntu. nmcli should be equally affected by any configuration that creates an access control limitation.

I note that you have network and wheel group membership as mentioned by Arch Linux Wiki - NetworkManager. If you are running Sugar under a different username, make sure that username has those permissions too.

@SanketDG wrote:

You should be part of a group that would allow your user to have administrator privileges.

No. Sugar is to be run as a normal user. A normal user is expected to have authority to configure network connections. If that is taken away by the distribution maintainers, then Sugar won't work properly.

SanketDG commented 4 years ago

I note that you have network and wheel group membership as mentioned by Arch Linux Wiki - NetworkManager

Right, I understand, Sugar is to be run as a normal user. But to run NetworkManager, you would need to be part of the wheel group, because a wheel groups gives root permissions to a normal user. Apologies, I basically meant what you said^

srevinsaju commented 4 years ago

Yes. I can run nmcli without any errors,

It was

/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules
----------------------------------------------------------------------------------
polkit.addRule(function(action, subject) {
  if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {
    return polkit.Result.YES;
  }
});

This was not configured by default in Arch I suppose. I remember, on Fedora. Sugar asks me for password to configure the network, which it doesn't. I am on KDE Plasma, and I do not have a gnome-keyring. Is it right that gnome-keyring is necessary?

quozl commented 4 years ago

@SanketDG wrote:

Right, I understand, Sugar is to be run as a normal user. But to run NetworkManager, you would need to be part of the wheel group, because a wheel groups gives root permissions to a normal user. Apologies, I basically meant what you said^

Sugar does not run NetworkManager. NetworkManager is assumed to have been started already. In modern systems if it is present it is started by systemd. Sugar uses D-Bus via NM.Client API to contact NetworkManager.

@srevinsaju wrote:

Yes. I can run nmcli without any errors,

Interesting, thanks.

It was

/etc/polkit-1/rules.d/50-org.freedesktop.NetworkManager.rules
----------------------------------------------------------------------------------
polkit.addRule(function(action, subject) {
  if (action.id.indexOf("org.freedesktop.NetworkManager.") == 0 && subject.isInGroup("network")) {
    return polkit.Result.YES;
  }
});

This was not configured by default in Arch I suppose.

Did it work when you added this?

On Ubuntu 20.04 they've said farewell to NetworkManager and are using systemd-networkd and netplan.io, and the NM.Client API still works. I don't know what the future holds for Arch Linux in this respect.

I remember, on Fedora. Sugar asks me for password to configure the network,

Interesting. I guess that is the Option 1 response in Set up PolicyKit permissions.

which it doesn't. I am on KDE Plasma, and I do not have a gnome-keyring. Is it right that gnome-keyring is necessary?

Based on that Wiki page, it would appear that the prompt you saw comes from Polkit, not from Sugar. So whether gnome-keyring is necessary or not depends on Polkit, not Sugar.

GNOME keyring is not a direct dependency of Sugar.

Sugar can prompt for a wireless network passphrase; this is a delegated responsibility negotiated via NM.Client.

srevinsaju commented 4 years ago

Did it work when you added this?

No

This might give some relevant information.

I do not have internet connection when I boot in Arch Linux Recovery mode, I do not have internet connection becuase NetworkManager.service is not started. But, in my previous installation, I had manually configured my network to use . I do not have a

/etc/udev/rules.d/10-network.rules

in my File system. Nor did I configure dhcpd on my system, becuause it was too much witchcraft terminal work, and KDE does all the hardwork with NetworkManager. On Manjaro Linux GNOME, (derivative of Arch Linux, with GNOME pre installed), I do not have this error, probably because all my network operations are carried over by DHCP, and NetworkManager does not exist.

These all might be the reason. But I am curious,

Why is sugar trying to use NetworkManager, if its not supposed to be used?
I have noticed that, after my recent testing on Kubuntu 19.04 fails with the same error of NetworkManager becuause, Kubuntu also features the same old NetworkManager alone
Ubuntu GNOME doesn't fail with the error, and nor does Debian. this might be because, all of them use some other network manager

These were my findings, I have started feeling that my findings might be incorrect after a relative number of reasons. I would like someone else to test sugar on KDE Plasma installed by default (Kubuntu, Fedora KDE, Manjaro KDE, etc) and sugar-runner

quozl commented 4 years ago

But I am curious,

Why is sugar trying to use NetworkManager, if its not supposed to be used?

Sugar does not run NetworkManager. i.e. it does not fork and exec, it does not start it.

Sugar does use NM.Client, an API provided through PyGObject, accessed through D-Bus, and implemented by various services, of which NetworkManager is one of them. The others include systemd-networkd and netplan.io. There may yet be others I've not learned of yet.

Sugar uses NM.Client, and therefore NetworkManager or whatever replaces it, in order to provide a wireless access point and ethernet interface management feature, in the Neighbourhood View and in the Frame.

That's why PermissionDenied is a problem that should be fixed, in order to make sure those features work. However, as far as I can see from the issue comments above, the problem is in your system software configuration, not in Sugar.

I have noticed that, after my recent testing on Kubuntu 19.04 fails with the same error of NetworkManager becuause, Kubuntu also features the same old NetworkManager alone

Good, that suggests the problem is with configuration of the service that is, or is pretending to be, NetworkManager. Not Sugar.

Ubuntu GNOME doesn't fail with the error, and nor does Debian. this might be because, all of them use some other network manager

Read the source code for GNOME.

These were my findings, I have started feeling that my findings might be incorrect after a relative number of reasons. I would like someone else to test sugar on KDE Plasma installed by default (Kubuntu, Fedora KDE, Manjaro KDE, etc) and sugar-runner

I won't. My interest is only to support Sugar as a desktop standing alone. sugar-runner has bitrotted and no longer does what is needed. The years of changes to GNOME and KDE since sugar-runner was written would have to be merged into sugar-runner. For reference, sugar-runner active development period was 2012 to 2014.

If this permission denied error is happening only with sugar-runner, then I'd like to close this issue as "not Sugar".

When using sugar-runner, the system D-Bus is being shared by two desktop in order to reach one service. The second desktop's use of the service would have to either share or conflict with the first. Permission denied looks like a conflict.

srevinsaju commented 3 years ago

Tested again. Fedora 32 Sugar as test system. Closing this as not-sugar

sugarlabs / sugar

org.freedesktop.NetworkManager.Settings.PermissionDenied: uid 1000 has no permission to perform this operation #915