Documenting Problems That Were Difficult To Find The Answer To

Restoring SELinux Labels After Restoring From Data Backup To Android

So I made a major error of judgement and tried to put Marshmallow CyanogenMod 13 onto my LG G3 (d855). Sure, for a while it raced along nice and fast, but in the end turned into an utter disaster when, overnight, it decided to go into an endless CPU loop resulting in rebooting every 10 minutes or so back into another CPU loop. Making the phone very hot and essentially useless. Well enough of that long story. I tried to downgrade using a backup I made earlier back into Lollypop CyanogenMod 12.1.

But K-9 mail was not starting.

I ran:

# adb root
# adb shell
root@d855:/ # logcat |grep com.fsck.k9
W/com.fsck.k9(13997): type=1400 audit(0.0:2058): avc: denied { write } for name="preferences_storage" dev="mmcblk0p43" ino=530653 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
E/SQLiteDatabase(13997): Failed to open database '/data/data/com.fsck.k9/databases/preferences_storage'.
E/SQLiteDatabase(13997): 	at com.fsck.k9.preferences.Storage.openDB(
E/SQLiteDatabase(13997): 	at com.fsck.k9.preferences.Storage.loadValues(
E/SQLiteDatabase(13997): 	at com.fsck.k9.preferences.Storage.(
E/SQLiteDatabase(13997): 	at com.fsck.k9.preferences.Storage.getStorage(
E/SQLiteDatabase(13997): 	at com.fsck.k9.Preferences.(
E/SQLiteDatabase(13997): 	at com.fsck.k9.Preferences.getPreferences(
E/SQLiteDatabase(13997): 	at com.fsck.k9.K9.onCreate(
E/AndroidRuntime(13997): Process: com.fsck.k9, PID: 13997
E/AndroidRuntime(13997): java.lang.RuntimeException: Unable to create application com.fsck.k9.K9: android.database.sqlite.SQLiteException: not an error (code 0): Could not open the database in read/write mode.

Turns out that first line from the log there is SELinux denying write access to the file.

I discovered I needed to run the restorecon command which would apply the necessary labellings for the files in /data/data using the rules in /file_contexts.

# adb root
# adb shell
root@d855:/ # restorecon -Rv /data/data/com.fsck.k9

But there is another reason why an application may be unable to access its database. Wrong user. What user does an application run as? That is found in /data/system/packages.list:

root@d855:/ # grep com.fsck.k9 /data/system/packages.list
com.fsck.k9 10076 0 /data/data/com.fsck.k9 default 3003,1028,1015

So with that information I could set the owner of the data files to that required by the application:

root@d855:/ # chown -R 10076 /data/data/com.fsck.k9

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: