- Edited
igorka67 no prob, glad it worked for you too, now the fix can be safely applied to the package in the repos as long as it works:)
igorka67 no prob, glad it worked for you too, now the fix can be safely applied to the package in the repos as long as it works:)
Wat-now good, so the only needed commit is to patch that connman.conf
file.
Btw I have seen that it's the same change that's present in the official Debian package, though they don't use a policy for a network group:
https://salsa.debian.org/debian/connman/-/blob/debian/sid/src/connman-dbus.conf?ref_type=heads
@Wat-now my proposed configuration might work but is possibly incorrect. The debian configuration is not really theirs, it's simply the default upstream source configuration. Arch removed by purpose the allow send_destination
line (that I reintroduced) from the root policy block and replaced the policy at_console
block with a network group policy, the latter containing the allow send_interface
line. So it's not that straightforward as it seemed and the changes that I made might not really make sense. I even tried the default source configuration but it didn't work, so far the only working configuration is the one that I posted before...
wastelander ok I will change send_interface to send_destination in the connman rebuild, thanks for clarifying.
Wat-now no prob, thanks to you:) I don't know if the send_destination
line is necessary for the root policy section too, in my test I had put it in both the root
and network
sections.
UPDATE:it looks like your change is enough, I only added send_interface to the network section and connman works after reloading
@Wat-now just an update, I opened an issue on the connman Arch gitlab asking for an opinion on my "fix". The packager has told me that I'm on my own with this change because connman works fine with their settings, and that connman-gtk is an AUR unsupported package based on an old version of connman. Issue closed.
So the choice is keep connman-gtk with this unsupported patch or switch to networkmanager by default.
@Wat-now I went on with my research and I think that the actual change is indeed not the best one in terms of security. We are granting the network group total control over connman, a safer solution would be that one:
<policy group="network">
<allow send_destination="net.connman.Manager"/>
<allow send_interface="net.connman.Manager"/>
</policy>
Reference: https://www.reddit.com/r/voidlinux/comments/oyqr6i/cmstconnman_not_working_on_lxqt/
Tested and working on my side.
wastelander does it workk just as well with <allow send_interface="net.connman.Manager"/>
without <allow send_destination="net.connman.Manager"/>
or does it need both?
Wat-now as far as we're talking about wireless scan it looks like the line<allow send_destination="net.connman.Manager"/>
is enough. I don't know about other functions though, it's possible that the other line <allow send_interface="net.connman.Manager"/>
is useful for advanced options or Bluetooth or something. I have seen a line like that in different configurations, maybe it could be safe to keep it.
However, adding only <allow send_interface="net.connman.Manager"/>
doesn't work for me. So I'd keep both the lines.
wastelander I'm a minimalist, so I lean toward only adding the necessary line until I know for sure the allow send_interface is needed for bluetooth or etc..
Wat-now it's fine, I'm a minimalist as well:) I think that adding that ". Manager" should be fine to restrict the network group to this specific task.
@Wat-now I'm sorry but I'm afraid we'd revert the last commit. After booting today I had connman-gtk not showing anything. Changing "net.connman.Manager" to "net.connman" as before fixed the issue...
Thanks for the quick fix :) it looks like this thing has a really erratic behavior, let's leave the thread open and I'll let you know should there be any further issues.
Powered by Obarun