Main user SELinux Context applied even on other users
ROM: unofficial build of Resurrection Remix 7.0.2 based on LineageOS 16.0 based on AOSP 9 oandbackup version: 0.3.5-universal (from F-Droid)
Problem
When restoring app data on a secodary device user or work profile (implemented as a special, seperated user account from androids point of view), oandbackup appears to be unable to apply the proper SELinux contexts, thus preventing the restored application from reading its data.
Expected behavior
- Add work profile or secondary user account
- Install oandbackup to work profile or secondary user account
- Grant root access to that instance of oandbackup one way or another (at least Magisk offers a setting for such cases)
- Back up any app
- Restore data to that app
- App should launch normally
Current behavior
After following the aforementioned steps, the restored app crashes upon launch. Using a terminal emulator, it is possible to reveal the following:
- oandbackup correctly restores data to the right folder, i.e.
/data/user/[id] - however, the effective SELinux context is always the one corresponding to the main user ("Device owner")
Example with app org.lineageos.eleven under "New user"
ls -Z /data/user/11before restoring data (excerpt)
u:object_r:app_data_file:s0:c523,c768 org.lineageos.audiofx
u:object_r:app_data_file:s0:c95,c256,c523,c768 org.lineageos.backgrounds
u:object_r:app_data_file:s0:c523,c768 org.lineageos.eleven
u:object_r:app_data_file:s0:c61,c256,c523,c768 org.lineageos.jelly
u:object_r:system_app_data_file:s0 org.lineageos.lineageparts
u:object_r:system_app_data_file:s0 org.lineageos.lineagesettings
u:object_r:app_data_file:s0:c523,c768 org.lineageos.lockclock
ls -Z /data/user/11after restoring data (excerpt)
u:object_r:app_data_file:s0:c523,c768 org.lineageos.audiofx
u:object_r:app_data_file:s0:c95,c256,c523,c768 org.lineageos.backgrounds
u:object_r:app_data_file:s0:c512,c768 org.lineageos.eleven
u:object_r:app_data_file:s0:c61,c256,c523,c768 org.lineageos.jelly
u:object_r:system_app_data_file:s0 org.lineageos.lineageparts
u:object_r:system_app_data_file:s0 org.lineageos.lineagesettings
u:object_r:app_data_file:s0:c523,c768 org.lineageos.lockclock
ls -Z /data/user/0for comparison (excerpt)
u:object_r:app_data_file:s0:c512,c768 /data/data/org.lineageos.audiofx
u:object_r:app_data_file:s0:c95,c256,c512,c768 /data/data/org.lineageos.backgrounds
u:object_r:app_data_file:s0:c512,c768 /data/data/org.lineageos.eleven
u:object_r:app_data_file:s0:c61,c256,c512,c768 /data/data/org.lineageos.jelly
u:object_r:system_app_data_file:s0 /data/data/org.lineageos.lineageparts
u:object_r:system_app_data_file:s0 /data/data/org.lineageos.lineagesettings
u:object_r:app_data_file:s0:c512,c768 /data/data/org.lineageos.lockclock
Notice that org.lineageos.eleven is in the context c512 after restore while c523 would be required to allow access if the app is launched with the "New user" logged into the android device.
Running restorecon -R /data/user/11/$packagename on any given app data folder sets the wrong context c512 in my case. As oandbackup probably uses this tool to restore contexts, this looks like the root of the problem. So, is this a bug in my ROM or is it simply incorrect to fully rely on restorecon in all cases?
I'm having the same user visible behavior on LineageOS for MicroG 15.1. Didn't yet check file contexts etc, but I'd imagine it's the same. Also trying to restore apps to a work profile.
@SebiderSushi did you find some manual way to fix up things after a restore?
For me the fix was
chcon c523,c768 /data/user/11/$packagename
Followed by a reboot
I don't have a rooted device at hand right now but i think i never tried anything other than restorecon -R "$DIR" to fix stuff (besides manually finding out the right context and calling chcon) so:
~~Does adding the -F option to the restorecon call help? I.E. restorecon -FR /data/user/11/$packagename~~
Edit: Okay nevermind i pulled out rooted adb on a LineageOS 15.1 and oh boy does running restorecon -DR /data/user/ nuke your secondary user data. I think restorecon only ever applies the default data context c512 all over the place.
One possible workaround i use in a shell script when i restore data in recovery:
This records the SELinux context prior to restoring data using ls -Z and re-applies it afterwards.
local ctx="$(ls -Zd "$pkgdir")" &&
ctx="${ctx%% *}" &&
# do restore
chcon -hR "$ctx" "$pkgdir"
(see here for the full app data restore shell script function)
For me the manual chcon is enough of a fix for now. Thanks for the shell script though, bookmarked it in case I need it later.