Defender app update (harbour-defender) - my very own ‘Sailfish Devember’

:frowning:h, wow! :disappointed_face:

Looks like a lot of work after receiving my new Beauty.

But before we deep dive.

The bickering about cannnot read undefined items is negligible.

But heavily wondering about libselinux.so cannot be found!!!

This is under /usr/lib/ and definitely whitelisted.

So, which version are you testing?

I do hope latest from Chum (0.8.xx)? (Even that may not be compiled for 5.2, but would not explain above)

You may try to test the one from chum:testing, this is newer version with noarch and some more changes (v0.9.2 or v0.9.3?)

I was running the latest version from Chum, yes, and updating to the testing version doesn’t fix things.

However, I think things are probably not nearly as broken as my post made it seem. Here’s where my lack of Sailfish knowledge shows through. In order to produce the log output, I was running harbour-defender directly from the shell, not via sailjail, without realising that this was going to change the behaviour significantly.

Running via sailjail (I still don’t know what I’m doing, so I just stole the commandline by catching it as the UI was attempting to run Defender), gives the much less concerning following output:

Reading profile /etc/sailjail/permissions/harbour-defender.profile
Reading profile /etc/sailjail/permissions/Compatibility.permission
Reading profile /etc/sailjail/permissions/Connman.permission
Reading profile /etc/sailjail/permissions/Internet.permission
Reading profile /etc/sailjail/permissions/Connman.permission
Reading profile /etc/sailjail/permissions/PublicDir.permission
Reading profile /etc/sailjail/permissions/Internet.permission
Reading profile /etc/sailjail/permissions/Connman.permission
Reading profile /etc/sailjail/permissions/PublicDir.permission
Reading profile /etc/sailjail/permissions/Base.permission
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/whitelist-common.inc
Reading profile /etc/firejail/whitelist-common.local
Reading profile /etc/firejail/whitelist-usr-share-common.inc
Reading profile /etc/sailjail/permissions/Notifications.permission
Reading profile /etc/sailjail/permissions/Sharing.permission
firejail version 0.9.79

Parent pid 26009, child pid 26016
constructing /run/firejail/mnt/privileged:  ...
mounting /run/firejail/mnt/privileged @ /home/defaultuser/.local/share/system/privileged
hiding /run/firejail/mnt/privileged
Warning: /usr/bin/bwrap was not disabled
Warning: invalid private-bin path /usr/bin/bwrap
28 programs installed in 151.71 ms
Warning: An abstract unix socket for session D-BUS might still be available. Use --net or remove unix from --protocol set.
Warning: you are not allowed to change /etc/defender.conf to read-write
Warning: you are not allowed to change /etc/hosts.editable to read-write
Warning: you are not allowed to change /etc/hosts.editable to read-write
Base filesystem installed in 233.61 ms
Child process initialized in 1239.59 ms
[D] unknown:0 - Using Wayland-EGL
Could not open module param file '/sys/module/mali_kbase/parameters/large_page_conf'
[16521.103149] (sailfish-qml) [MEMPROF] Memory instrumentation via debugfs enabled
[D] unknown:0 - Got library name:  "/usr/lib64/qt5/qml/io/thp/pyotherside/libpyothersideplugin.so"
[W] unknown:24 - file:///usr/share/harbour-defender/qml/pages/components/CookiesMenuItem.qml:24: TypeError: Cannot read property 'cookies_count' of undefined
[W] unknown:29 - file:///usr/share/harbour-defender/qml/pages/components/CookiesMenuItem.qml:29: TypeError: Cannot read property 'domains_count' of undefined
[W] unknown:24 - file:///usr/share/harbour-defender/qml/pages/components/SourcesMenuItem.qml:24: TypeError: Cannot read property 'hosts_lines' of undefined
[W] unknown:29 - file:///usr/share/harbour-defender/qml/pages/components/SourcesMenuItem.qml:29: TypeError: Cannot read property 'sources_enabled_count' of undefined
library "mapper.mediatek.so" not found
gralloc-mapper is missing

Parent is shutting down, bye...

So if I’m guessing, the only actual problem there might be the lack of “mapper.mediatek.so”. My apologies for causing undue alarm!

Yes, you might be right.

I was struggling with Xperia10 devices a lot until we found the real cause.

And hoped with the new Jolla (mediatek) this would not be necessary.

Could you open the console and try

find / -name mapper.mediatek.so

I could narrow it down to guessed places but if you do not have thousands of pics/vids/music on it….

Just let it run, will take some time.

I’ll do ya one better…

[root@JollaPhone2026 defaultuser]# find / -name mapper.mediatek.so -exec ls -l {} \; 2>/dev/null
lrwxrwxrwx    1 root     root            25 Jul  7 09:57 /vendor/lib64/hw/mapper.mediatek.so -> mt6858/mapper.mediatek.so
-rw-r--r--    1 root     root        220208 Jul  7 09:57 /vendor/lib64/hw/mt6858/mapper.mediatek.so
2 Likes

Great! :slight_smile:

Would you like it the old long hard way?

a) so lib by lib? For the 10 III we fought quite a while as I did not have that device in my hands (at that time :wink:).

Or

b) I can just add all lib dirs of the 10III to the whiltelist of JP2602. But this could lead to loading times of over 30 seconds :frowning: .

I opt for a)

And will send you a file harbour-defender.profile to drop to the /etc/sailjail/permissions/ dir

Or you might just edit it and add that above found dir to it (quite at the very end)

whitelist /vendor/lib/hw/mt6858/*
whitelist /vendor/lib64/hw/mt6858/*

Let me know which way…

Adding the whitelists fixes the wrapper error. Now exiting with:

[D] unknown:0 - Using Wayland-EGL
couldn't find an OpenGL ES implementation, make sure one of persist.graphics.egl, ro.hardware.egl and ro.board.platform is set

Parent is shutting down, bye...

I don’t know how much you want to handhold here, given that I don’t really what I’m doing. (Fairly extensive Linux experience, quite limited Sailfish.) But I’m willing to keep poking as long as you want me to. :slight_smile:

1 Like

Hmm, I might as long as it needs… :wink:

But I sent you a file via PM. Just extract it and add (cat >>) it to the harbour-defender.profile.

if that does not work it will be ping pong again…..

But be patient, might take some time to load and start!

I’ve been playing around with this a bit, and not really made much progress. I’ve done a couple of different things that cause a couple of different failure modes.

First one, already addressed above, is if I whitelist /vendor/lib/hw/mt6858/*, Defender exits with the following error:

[D] unknown:0 - Using Wayland-EGL
couldn't find an OpenGL ES implementation, make sure one of persist.graphics.egl, ro.hardware.egl and ro.board.platform is set

The only previous reference to this error in the forum seems unrelated enough not to be useful here, although I did play around with setting QT_QPA_PLATFORM=hwcomposer, which gave me:

library "libged_kpi.so" not found
Can't create AidlComposerClient, fallback to HIDL

I imagine this was a dead end, and probably unrelated to the solution to this issue.

Second one, which is pretty curious to me, is when I was just poking around kind of randomly at this, if instead of whitelisting /vendor/lib/hw/mt6858/*, I just copy /vendor/lib64/hw/mt6858/mapper.mediatek.so to /vendor/lib64, I end up with this very different error message:

[W] unknown:0 - QObject::moveToThread: Current thread (0x5dadc180c0) is not the object's thread (0x5dad1c7800).
Cannot move to target thread (0x5dad6e9eb0)

[W] unknown:0 - QObject::moveToThread: Current thread (0x5dadc180c0) is not the object's thread (0x5dad1c7800).
Cannot move to target thread (0x5dad6e9eb0)

[F] unknown:0 - Cannot make QOpenGLContext current in a different thread

I have no idea why forcing it to load the mediatek library from a different location would cause such a different output, but maybe this means something to someone. :slight_smile:

I am presently using the most recent version of Defender from Chum testing (0.9.3), but I get all the same behaviour from the release version.

1 Like

After a DM from @peterleinchen got me poking around with the whitelists, I found that Defender did work properly with a wide net whitelist, and then I narrowed it down to a logical minimal set. The following additions to /etc/sailjail/permissions/harbour-defender.profile successfully get Defender working on the new Jolla phone:

whitelist /etc/ld.so.preload
read-only /etc/ld.so.preload

whitelist /system/bin/zcat
read-only /system/bin/zcat
 
whitelist /vendor/lib64
read-only /vendor/lib64

:tada:

1 Like

And v0.9.4 is out.

Biggest changes:

  • Now real pure qml app, no binary built, noarch
  • Lots of small changes regarding directories used, whiyelisting, etc
  • Introduced X-HarbourBackup for easy backup of configurations
  • Added configuration for update schedule
  • Adapted DNS flushing to 5.1
  • Aaand: Sailjail profile compatibility for new Jolla Phone jp2601 by the tremendous help of @aos
8 Likes

I installed Defender on SFOS 5.2.0.17, but it doesn’t seem to work. When I start it, it tries to load and after a while closes.

Can confirm. Here the same.

1 Like

Do you happen to have another app open that uses the sailfish-qml-scene or whatever command? There is a known issue where only one app can be open at a time…

Please see:

from

Or:

from Jolla Phone : First Experiences, Pros and Cons - #850 by vishcompany

So it was tested and working on JP2601.
.
Maybe he had the problem over here: Implementing Privacy Features: block App tracker - hide geolocation - hide IP address - #9 by peterleinchen

1 Like

Just a dummie question: have i to run this app explicitly in the foreground or can i close it and it works like expected running in background?

Can confirm. When for example the forumviewer is running, you cant open defender. Closing forumviewer enables to run defender.

1 Like

The GUI is only for updating the /etc/hosts file. And it’s done via some background update. So the app doesn’t normally need to be running. It will also auto-update the list. So it’s basically set it and forget it.

3 Likes

Thank you for the reply!

@peterleinchen: thank you very very much for this great app!!!:heart:

2 Likes

Edited my very first post in this thread:

And edited the main thread.

3 Likes

I don’t think the cookies-manager works as intended. Deleting using black/whitelist clears the screen, but when going back and returning they’re intact. I could black/whitelist items and that was saved in memory. Buy the wifi-only setting was always stuck on even when set off.

I tried the locking feature (which is a great idea), the whole list cleared out and I was logged out of all services. It felt like the browser noticed the read-only state and overwrote a fresh one. Could be something different too.

Also some tracker lists 404’d and some caused a loading loop, but unfortunately as a new Jolla user my thumbs are still too clumsy to do debugging.