After upgrading to F29 beta with Plasme 5.13.5 I got the reminder about the Browser integration. I installed the Firefox extension and started to test it. No problems there.... firefox-62.0-3.fc29.x86_64 plasma-browser-integration-5.13.5-1.fc29.x86_64 [this might also apply to Chromium, but I didn't activate the integration for it] ...but afterwards I had a look at "netstat -tp" and was surprised to see that the browser integration seems to create *outgoing* network connections on its own. Which is rather surprising when you read the statement from the Wiki https://community.kde.org/Plasma/Browser_Integration#Privacy: Everything is handled on your PC between the browser and your desktop, no additional data is sent via the web. Snapshot from my test system: $ netstat -tnp | fgrep -e plasma- -e firefox tcp 0 0 192.168.3.6:39846 xxxx:443 ESTABLISHED 1753/firefox tcp 0 0 192.168.3.6:33556 xxxx:443 ESTABLISHED 1753/firefox ... many more open connections from firefox .... tcp 2194537 0 192.168.3.6:49664 xxxx:443 ESTABLISHED 1753/firefox tcp 1 0 192.168.3.6:35696 104.16.111.25:443 CLOSE_WAIT 2686/plasma-browser tcp 32 0 192.168.3.6:57386 151.101.193.69:443 CLOSE_WAIT 2686/plasma-browser ... tcp 8692 0 192.168.3.6:50810 104.20.117.11:443 CLOSE_WAIT 2686/plasma-browser [NOTE: at other times I also saw ESTABLISHED connections. I tried to reverse look up the IPs but didn't get any usable information from them] $ ps -efw | fgrep 2686 stefanb 2686 1753 0 09:38 ? 00:00:00 /usr/bin/plasma-browser-integration-host /usr/lib64/mozilla/native-messaging-hosts/org.kde.plasma.browser_integration.json plasma-browser-integration@kde.org The above connections are not created by firefox, because firefox connections are associated with the firefox process. I haven't yet studied the source code for the messaging host binary to check for network connection creation, but I'll try to do so when I get the time.
It's a bug in firefox, it doesn't use O_CLOEXEC so the FDs get inherited by the host process. Nothing we can fix ourselves and all other native extensions are affected as well. Workaround: https://phabricator.kde.org/D15984
As recommended I filed a bug upstream https://bugzilla.mozilla.org/show_bug.cgi?id=1496991
After applying the workaround and restarting Firefox I do not see any "outgoing network connections" by plasma-browser-integration-host anymore. Thanks
Unfortunately the workaround has a nasty side-effect: firefox starts to busy-loop :-( I guess there are some FDs that firefox is using to communicate with the host binary and those should not be closed.
Created attachment 115453 [details] Patch with improved workaround I poked around in the workaround code and figured out that the only way to avoid Firefox to busy loop is to *only* close() sockets and leave the rest alone. Thus we still have leaked file descriptors lying around, but at least we're getting rid of all leaked network connections at start.
Hm, that might be because the leaked FD has some weird behaviour. Flags (like O_NONBLOCK) are shared with the parent, so it's not too unlikely that closing a pipe can cause some unexpected behaviour. The only correct behaviour here is not to close anything, really. I would prefer to not have any kind of workaround for this broken browser behaviour in our code, especially if that workaround has to contain hacks. It doesn't even change any kind of behaviour, it just makes the netstat output cleaner. Let's see what kbroulik thinks about this.
My Mozilla bug got marked as duplicate
*** Bug 418907 has been marked as a duplicate of this bug. ***