Crash on update check

[probablypablito]

I'm on GrapheneOS 14 and connecting over HTTP via a VPN to my update server.

There seems to be some permission denied error.

Custota log 6faa805cb0a6.txt

[chenxiaolong]

That's really strange. It's failing to create a file to save its logs. I'm not sure what would prevent Custota from writing to its own directory. I know GrapheneOS has some storage restrictions, like the storage scopes feature, but that shouldn't apply here.

To try and troubleshoot this, can you post the outputs of these commands?

adb shell su -c 'ls -lZd /data/media/0/Android/data/com.chiller3.custota/files /data/data/com.chiller3.custota'
adb shell pm dump com.chiller3.custota | grep 'uid=.*gids='

I just want to make sure this isn't just some filesystem permissions issue.

On my device, it looks like this:

drwx------ 6 u0_a281 u0_a281     u:object_r:app_data_file:s0:c25,c257,c512,c768       3452 2023-12-12 09:05 /data/data/com.chiller3.custota
                 ^^^     ^^^                              *********************
drwxrws--- 2 u0_a281 ext_data_rw u:object_r:media_rw_data_file:s0:c25,c257,c512,c768  3452 2023-12-30 10:51 /data/media/0/Android/data/com.chiller3.custota/files
                 ^^^                                           *********************
    uid=10281 gids=[] type=0 prot=signature
          ^^^

The highlighted parts (user ID ^^^ and SELinux MCS ***) should match.

[probablypablito]

PS C:\Users\Pablo> adb shell su -c 'ls -lZd /data/media/0/Android/data/com.chiller3.custota/files /data/data/com.chiller3.custota'
drwx------ 6 u0_a77 u0_a77      u:object_r:app_data_file:s0:c77,c256,c512,c768  3452 2024-03-03 14:41 /data/data/com.chiller3.custota
drwxrws--- 2 u0_a77 ext_data_rw u:object_r:media_rw_data_file:s0                3452 2024-02-18 16:49 /data/media/0/Android/data/com.chiller3.custota/files

PS C:\Users\Pablo> adb shell pm dump com.chiller3.custota | findstr.exe 'uid=.*gids='
    uid=10077 gids=[] type=0 prot=signature
    

[chenxiaolong]

Thanks. That u:object_r:media_rw_data_file:s0 definitely looks wrong. I would suggest deleting the entire /data/media/0/Android/data/com.chiller3.custota directory, rebooting, and seeing if that fixes the problem.

(I'm not sure how it ended up in that state though. That app directory is created by Android before the app launches the first time.)

[josevega96]

I'm getting a crash also in pixel stock with the march security patch , I could update from the February patch to the march patch without any issue , but after the update I began getting the error

[chenxiaolong]

@josevega96 Thanks. I've opened a new issue over at #40 for this as it's unrelated to this specific issue.

[probablypablito]

I followed the deletion instructions but now receive this error:

Failed to install OTA update

IOException (Failed to download update info)
-> SocketException (Binding socket to network
108 failed: EPERM (Operation not permitted)) ->
ErrnoException (Binding socket to network 108
failed: EPERM (Operation not permitted))

I've tried re-deleting the directory but to no avail.

EDIT: Updated to 3.1 and the issue is still there.

[chenxiaolong]

If I remember correctly, GrapheneOS has a permission toggle for each app for network access. Can you double check that it is enabled?

[probablypablito]

It is enabled. Do you need more logs or a screen recording? I'm unsure what could've caused this as I had Custota working before I updated to v3 / avbroot v3

[chenxiaolong]

Can you also grab the output of these?

• Run adb shell 'ps -efZ | grep custota' while Custota is running
• Run adb shell su -c 'dmesg -w | grep avc:' and while the command running, check for updates in Custota, and grab any new output that gets printed out

I'm really not sure why this would've just started happening with version 3. The permissions and SELinux logic have remained unchanged since the initial release (version 1).

[probablypablito]

C:\Users\Pablo>adb shell "ps -efZ | grep custota"
u:r:custota_app:s0:c77,c256,c512,c768 u0_a77 21180  922 11 13:37:26 ?    00:00:00 com.chiller3.custota
u:r:shell:s0                   shell        21220  1249 2 13:37:29 ?     00:00:00 sh -c ps -efZ | grep custota
u:r:shell:s0                   shell        21223 21220 7 13:37:29 ?     00:00:00 grep custota

No new output was printed for the second command.

[chenxiaolong]

Thanks. So everything SELinux-related is good. I really have no idea what else would cause the ErrnoException (Binding socket to network 108 failed: EPERM (Operation not permitted)).

The only thing left I could suggest is the brute force approach: maybe try uninstalling the Custota module completely and booting once without it installed (so that Android will delete all of Custota's data). It probably won't help, but I don't really have any more ideas for what the problem might be.

[probablypablito]

Tried to no avail :(

No idea what it is either, but this is definitely annoying. I'll miss using it! I'll open another issue / contact you if I find a solution.

[probablypablito]

Oh wow literally just now I found the issue: my WireGuard VPN running in root mode.

WireGuard on Android can be ran either in userspace or (with root) in kernel mode. The latter seems to make Custota unhappy. Turning off the VPN or setting it back to userspace seems to fix that specific issue.

[chenxiaolong]

Oh wow, nice find.

Custota (and also Android's underlying update_engine) use Android's special Network API for all connections. It's the standard way to handle things like only connecting if the user is on an unmetered network. I know Android's implementation of this API does a bunch of things behind the scenes, like setting up fwmark firewall rules. At least on desktop Linux, WireGuard also sets up its own fwmark firewall rules. If WireGuard does the same in kernel mode on Android, I wonder that's causing some sort of conflict. Userspace mode wouldn't be affected since that goes through Android's VPN APIs.