Project

General

Profile

Issue #2229

/data/system/applications.xml corruption at boot ?

Added by Denis 'GNUtoo' Carikli 6 months ago. Updated 5 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Build system
Target version:
Start date:
03/11/2021
Due date:
% Done:

0%

Estimated time:
Resolution:
Device:
Not device specific
Grant:
Type of work:
Unknown
#1

Updated by Denis 'GNUtoo' Carikli 6 months ago

  • Subject changed from /data/system/applications.xml corruption at boot to /data/system/applications.xml corruption at boot ?

I was running Replicant 6.0 0004 RC3 on a Galaxy SIII (GT-I9300). The exact image version was retrieved with getprop.

I was doing some experiments to write some clean reboot and power off scripts as my power button got damaged. I may also have removed the battery at early boot (I've a tendency to do that).

But at some point it stopped booting.

I then reinstalled Replicant 6.0 0004 RC3 and it still didn't boot.

I then started removing some applications I installed lately with rm -rf in /data (find -iname "*com.application.something" + rm -rf the resulting directories), and nothing changed.

I then looked at /data/system/ and I had that:

root@m0:/data/system # ls
appops.xml               inputmethod                 packages.xml       
batterystats-checkin.bin install_sessions            packages.xmlNIfHGG 
batterystats-daily.xml   job                         procstats          
batterystats.bin         last-fstrim                 profiles.xml       
cache                    locksettings.db             recent_images      
called_pre_boots.dat     locksettings.db-shm         recent_tasks       
code_cache               locksettings.db-wal         seapp_hash         
device_policies.xml      ndebugsocket                shared_prefs       
dockbatterystats.bin     netpolicy.xml               storage.xml        
dropbox                  netstats                    sync               
entropy.dat              notification_log.db         theme              
framework_atlas.config   notification_log.db-journal uiderrors.txt      
hdcp2                    notification_policy.xml     usagestats         
heapdump                 package-usage.list          users              
ifw                      packages.list               

Bot packages.xmlNIfHGG and packages.xml were empty (in my previous test while developing the migration feature only one would be empty if something went wrong).

The issue is that I assumed that:
  • sed didn't write if nothing needed to be changed
  • It wound't change anything when reinstalling the same image.

If the corruption happened, something of my assumptions are wrong.

#2

Updated by Denis 'GNUtoo' Carikli 6 months ago

It seems that getting the keys for previous Replicant 6.0 releases is not an option.

So we need to make sure that it at least runs only once and covers all the situations.

If it could delete itself once it ran it would probably be good enough.

#3

Updated by Denis 'GNUtoo' Carikli 6 months ago

We also need to verify the key formats.

The short one might need == at the end.

#4

Updated by Denis 'GNUtoo' Carikli 5 months ago

I've some difficulties finding a very robust way to do the migration.

The idea would be to only run the script only once at the first boot right after the installation.

Unfortunately that might not be easy:
  • The script cannot be run in the recovery because if the user partition is encrypted, the installer or recovery cannot access /data/system/applications.xml
  • init configuration files (like the /*.rc) have to be system files, and if I use some include for non existing paths it doesn't fail but:
    • /etc/init.d/ scripts cannot delete system files (it ends up with selinux compilation issues due to neverallow)
    • init (with *.rc files) cannot delete system files either (it also ends up with neverallow)

I'd really prefer to have something simple (like delete the file) than write some code to write the version in a file and only run if it differs as it would be more fragile (we have -dev images too and I keep loosing my data on those) and continue to run at each boot.

#5

Updated by Denis 'GNUtoo' Carikli 5 months ago

It seems that using init .rc files would also be complicated.

In vendor/replicant with the following addition in prebuilt/common/etc/init.local.rc:

on post-fs
    import /system/key-migration.rc

And the following prebuilt/common/key-migration.rc:

service gnutoo-test /system/bin/log -p i -t Replicant "Test GNUtoo" 
    oneshot
    seclabel u:r:sudaemon:s0
    disabled

on post-fs-data
    start gnutoo-test

And the following (pseudo) patch:

diff --git a/config/common.mk b/config/common.mk
index 411a7567..3e56cb3c 100644
--- a/config/common.mk
+++ b/config/common.mk
@@ -236,6 +236,8 @@ endif
 # test-keys migration script
 PRODUCT_PACKAGES += \
     key-migration.sh
+PRODUCT_COPY_FILES += \
+    vendor/replicant/prebuilt/common/key-migration.rc:system/key-migration.rc

 DEVICE_PACKAGE_OVERLAYS += vendor/replicant/overlay/common

diff --git a/sepolicy/file_contexts b/sepolicy/file_contexts
index bcc9217c..f3a320d3 100644
--- a/sepolicy/file_contexts
+++ b/sepolicy/file_contexts
@@ -55,3 +55,6 @@

 # bash
 /system/xbin/bash                               u:object_r:shell_exec:s0
+
+#
+/system/key-migration.rc                        u:object_r:rootfs:s0

It doesn't boot anymore and init seems to kill process on its own.

So it's probably way easier to record the version data somehow but I really don't like that idea as it's way more error prone...

#6

Updated by Denis 'GNUtoo' Carikli 5 months ago

I think we could use another approach: keep the code as-is and do 2 releases.

The installation procedure would be as follow:
  • Users would backup their contacts and install the first release which will do the key migration at boot.
  • Then once done they can restore their contact and install the second release which will not do any automatic key migration anymore. The script will still be kept in case of issues.

Denis.

Also available in: Atom PDF