Can not run android apps that use realm (e.g. Element) after updating to 4.5

nas · 31 May 2023 14:42

Could you share the “magique” way to have notifications with fluffychat ?!

kaulian · 31 May 2023 15:59

I do nothing just installed fluffychat and ntfy

Launch ntfy
Launch fluffychat
In fluffychat go to settings notification, activate if not done and a subscription is done in nfty… Tada !!!

nas · 31 May 2023 16:31

Thank you for the instructions @kaulian, I tried it, I run ntfy, I saw there the fluffychat, I saw a link to ntfy.sh but after that no notification on the sailfish… In fluffychat notification all settings are on (no setting for ntfy.sh) . Should the notifications go through ntfy.sh ? ( I wouldn’t like the notification goes out of the phone) Do I have to enable / activate anything else to have notifications on sailfish - like receiving sms kinda?

Thank you in advance!

debeliu · 31 May 2023 17:54

If you use Element version from F-droid, there is no problem with notifications because it use there own pulling system, while the play store version relies on Google push service.

kaulian · 31 May 2023 18:48

Perhaps in old time i did that

Try old version with register in unifiedpush.org

debeliu · 1 June 2023 09:00

To add information to this ticket, I have this problem with apps that use realm on my new 10III, but not on my XA2 plus.
The 2 phones freshly flashed with 4.5.0.19 and no problem on the XA2.
@thigg, you noted you have this also on the XA2 ?

nekron · 14 June 2023 09:47

Here are my observations done so far:

Initialized Realm database on former Sailfish OS version (4.4) works fine after migration to current release (4.5)
Re-initialization or installation of a new Realm-based application crashes with “File not found” error

Now what’s crashing it and what file is not found?

I compiled Realm and added debug output to see where the “File not found” is located as the error message shown in logcat output is misleading in thinking a .cpp file could not be compiled JIT. It simply shows the source code line number where a std_io error (file not found) was excepted. (see realm-java/realm/realm-library/src/main/cpp/io_realm_internal_OsSharedRealm.cpp at main · realm/realm-java · GitHub)

This brings in the JNI runtime bindings used by Realm. If a new database is going to be initialized a shared access thread tries to read the database file located inside the appsupport container at

/data/user/0/<name of your APK package>/files/<name of the Realm database file> (this is the file not found by the initialization shared Realm thread)

This path can be found at the host filesystem here:

[root@Xperia10II-DualSIM user]# pwd
/home/.android/data/user
[root@Xperia10II-DualSIM user]# ls -la
total 20
drwx--x--x    3 501000   appsuppo      4096 Feb  2 16:05 .
drwxrwx--x   46 501000   appsuppo      4096 Jun 11 00:46 ..
drwx------    2 501000   appsuppo      4096 Feb  2 16:05 0

However the 0 directory is mounted inside the appsupport container from /data/data/ so the host folder shows an empty directory here.

# mount | grep /data
/dev/mapper/luks-d60ed9d4-4192-4fcd-af04-b8e9d6f14d0c on /data type ext4 (rw,seclabel,noatime,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user)
/dev/mapper/luks-d60ed9d4-4192-4fcd-af04-b8e9d6f14d0c on /data/media/0 type ext4 (rw,seclabel,noatime,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user)
/dev/mapper/luks-d60ed9d4-4192-4fcd-af04-b8e9d6f14d0c on /data/user/0 type ext4 (rw,seclabel,noatime,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user)

That being said it looks like the initialization thread started by Realm JNI is either missing permissions to access the database file or it uses the plain (unmounted) /data/user/0 folder where no files are located.

Why I’m saying this?

Compared to a working Sailfish OS 4.4 appsupport container you’ll see that the /data/user/0 is symlinked to /data/data.

(Appsupport XA2, SFOS 4.4)

# ls /data/user -la
total 8
drwx--x--x  2 system system 4096 2019-11-29 13:56 .
drwxrwx--x 45 system system 4096 2023-06-14 08:54 ..
lrwxrwxrwx  1 root   root     10 2019-11-29 13:56 0 -> /data/data

versus

(Appsupport 10II, SFOS 4.5)

# ls /data/user -la
total 24
drwx--x--x  3 system system 4096 2023-02-02 16:05 .
drwxrwx--x 46 system system 4096 2023-06-11 00:46 ..
drwxrwx--x 73 system system 4096 2023-06-14 08:37 0

I’ve also tried to give full permissions to group and world on the applications data folder but still the file is not found. So in my opinion it has something to do with the mount vs. symlink difference between the new and old appsupport setup.

Cheers,
Nek

thigg · 14 June 2023 12:46

thanks for that investigation, thats a very interesting analysis

remote · 14 June 2023 16:33

I’ve got Element working fine after update to 4.5.0 (installed way back on earlier version).
So currently:

$ sudo ls -la /home/.android/data/user
total 20
drwx--x--x    3 501000   appsuppo      4096 Feb 13 16:13 .
drwxrwx--x   46 501000   appsuppo      4096 Jun 13 22:03 ..
drwx------    2 501000   appsuppo      4096 Feb 13 16:13 0
defaultuser@Xperia10III ~]$ sudo ls -la /home/.android/data/user/0
total 12
drwx------    2 501000   appsuppo      4096 Feb 13 16:13 .
drwx--x--x    3 501000   appsuppo      4096 Feb 13 16:13 ..

thigg · 14 June 2023 22:20

I actually do have the same values, so either this is the wrong directory, there is something going on with access rights when mounting this in appsupport, or there are other values different than the plain access rights.

247 · 15 June 2023 10:51

Hello, not using element but wanted to have a try

This version opens up correctly and works on 4.5, maybe it will help someone

nekron · 15 June 2023 18:38

My bet on this: The former SFOS 4.4 installed RealmDB got its database config correctly installed and so after migration to SFOS 4.5 the database setup code opens an already completely initialized database file and starts working without issues.

The other case is when you install a new RealmDB application or re-install e.g. Element. The database needs to be fully initialized and this is where the shared database thread comes into play. That shared thread eventually is not needed on a completely initialized database so it won’t crash the RealmDB application at startup in contrast given an uninitialized database.

The bad thing here is that Elements RealmDB is encrypted with device specific keys so simply x-copying them from a working 4.4 device over to 4.5 will also crash the application (I tested that between my 4.4 and 4.5 device).

In a second I’ll repeat my x-copy test using a non-encrypted database file from one of the RealmDB examples and see if it will work on the 4.5 device.

nekron · 15 June 2023 20:38

So here are the results:

you can copy the RealmDB files from 4.4 to 4.5 BUT
need to re-create the pipes (fifo files) manually

The RCA of crashing RealmDBs is that Realm creates *.note and *.cv pipes used for IPC.
At initialization time of the database files - in a working system like 4.4 - the pipe files are created okay.
Appsupport 4.5 however has an issue creating the pipes and it can be resolved by manually creating them using mkfifo *.note|*.cv. You have to change pipe permissions afterwards matching your applications folders user and group.

However this trick is sadly not working for Element. After manually fixing the initial fifo’s you’re able to launch Elements authentication screen where inside the ./files folder a new random hexvalue subdir is created dynamically that is containing crypto, disk and auth databases. These folder and the DBs will be created just-in-time so you sadly have no chance of “mkfifo …” the missing pipes afterwards.

Pipes:

Dynamically created crypto databases (these can’t be fixed as they are created when the authentication against the homeserver is started):

For the kotlin-example from the realm-java github repository this was working fine to get the application running on 4.5 after a fresh APK installation and fixing the missing pipes.

In the end the File or Directory Not Found message from logcat means in reality “I’m not able to create the pipe”.

UPDATE: You can “see” this issue when you appsupport-attach into the Android runtime, change to your Element or any other installed application at /data/data/<package> and try to create a fifo! The mkfifo command will not complain with an error but nonetheless the named pipe is not created. On the other hand if you create the fifo file from the host OS devel-su and cd /home/.android/data/<package>; mkfifo this_is_not_lost.test it will be created.

nekron · 16 June 2023 07:33

And last but not least @thigg @jovirkku @zepher @str4el @nas @vige @kaulian and others who joined this club here is the final solution to get RealmDB-based applications working on 4.5 again

become root (devel-su)
make a backup of /etc/aas-seccomp-profile (cp /etc/aas-seccomp-profile ~/)
modify the /etc/aas-seccomp-profile and remove the following two lines
- mknodat errno 0
- mknod errno 0

Original aas-seccomp-profile:

2
blacklist
ioprio_set errno 0
sched_setscheduler errno 0
setpriority errno 0
[arm64]
syslog errno 0
mknodat errno 0
mknod errno 0
reboot errno 0
swapon errno 0
swapoff errno 0

Modified aas-seccomp-profile:

[root@Xperia10II-DualSIM de.spiritcroc.riotx]# cat /etc/aas-seccomp-profile
2
blacklist
ioprio_set errno 0
sched_setscheduler errno 0
setpriority errno 0
[arm64]
syslog errno 0
reboot errno 0
swapon errno 0
swapoff errno 0

restart the Android application support layer from SailfishOS settings

Now Element and all other applications using RealmDB (or creating some named pipes) will work inside the container.

Please note that removing mknod and mknodat can be used to compromise the lxc container. On the other hand without allowing this syscall many RealmDB based applications will break on setup where the named pipes will be created.

thigg · 16 June 2023 07:40

impressive! how did you figure this out?

Ahtisilli · 16 June 2023 08:35

Cool!

Fixes Argenta Bank, too.

remote · 16 June 2023 09:56

so I suppose on 4.4 seccomp profile didn’t have mknod* restrictions and they were added in 4.5?

direc85 · 16 June 2023 10:51

This also fixed Deezer not being able to save its cache on the SD card (the internal memory still works either way).

nas · 16 June 2023 17:56

thank you for your effort @nekron ! Amazing investigation and result!

After I run Element with success, made even video call I had the idea what will happen if I reverse the changes in /etc/aas-seccomp-profile file. I stopped Android support and undid the changes. I started Elements and it it still works just fine!

The only flaw I found but I don’t think it has anything to do with this bug was that I couldn’t join jitsi in the rooms.

nekron · 16 June 2023 19:06

@thigg: Well, I’m doing DevOp stuff as an IT professional and containers are everywhere so I remember that many container runtimes can filter specific dangerous syscalls (Google e.g. wrote the gVisor proxy for containers as a kind of syscall emu that firewalls your container between container and kernel for security reasons to prevent that any kernel bugs inside syscalls can be exploited to break out of the container jail). I did some research for lxc and had a look how the appsupport image was integrated into SailfishOS. The rest of the story is history…

@remote: I guess that the seccomp settings didn’t blacklist the mknod* syscalls, but didn’t investigate any further.

@nas: Yes, once the named pipes are created and if your application has no need to re-create databases it’s just fine to revert the change to have more protection inside the container. As for Element the problem is once you unassign the device from e.g. Element web your crypto/auth whatever database will be removed and re-created once you re-authenticate the client (which will break because of the mknod syscall filter).

I personally can live with the risk of mknod syscall pass-through to the devices kernel as old 4.4 aliendalvik did the same and my device didn’t get hacked by some Android application