Preferences of a module cannot be read from different process on some devices running MM

[C3C0]

I have couple of reports from the users of my module that the preferences set in the settings part of a module don't stick. Unfortunately, I don't have any technical details about devices where that happens nor logs, but couple of users were the owners of Nexus 6P. I guess it has something to do with SeLinux or some other security restrictions. Could it be related to e.g. systemless rooting method? I run my module on couple of marshmallow nexus devices without any issues. My devices have modified kernel to allow classic SuperSU. I'm not using systemless root.

[theknut]

I can confirm that on a Nexus 5. I was no longer able to read or write
module settings from e.g. SystemUI context when I switched to M. I ended up
using a content provider instead.
Am 06.12.2015 11:27 schrieb "C3C0" notifications@github.com:

I have couple of reports from the users of my module that the preferences
set in the settings part of a module don't stick. Unfortunately, I don't
have any technical details about devices where that happens nor logs, but
couple of users were the owners of Nexus 6P. I guess it has something to do
with SeLinux or some other security restrictions. Could it be related to
e.g. systemless rooting method? I run my module on couple of marshmallow
nexus devices without any issues. Those devices have modified kernel to
allow classic SuperSU.

—
Reply to this email directly or view it on GitHub
#74.

[C3C0]

Then it would be interesting to know the difference between setup of my and your N5 since I don't have any problems reading preferences within SystemUI process on mine.

[rovo89]

I'm not near my PC right now, but this sounds like the known issue I mentioned in the Marshmallow release announcement. It's an SELinux restriction that I didn't find any solution for yet.

[C3C0]

I have some new information. Found out that devices which suffer from this are those with permissions of shared_prefs folder being drwx------
My N5X has permissions of this folder set as drwxrwx--x without me doing any manual changes.

What could be causing this difference?
One solution would be for my module to set proper permissions in boot completed receiver although it's too late. But at least it would prepare correct permissions for the next reboot cycle.

[wanam]

Why not setting the proper permission while closing the App (onpause or ondestroy)?

I have the same issue with my TW module on some LL FWs and i use this workaround.

[pbombnz]

@wanam like setReadble(true, false) on the SharedPrefs XML file in onPause and onDestroy or by using some sort of shell command?

Additonal Info I found: I have two devices, one kitkat which my module works fine on, while the marshmallow one always fails to read. Seems for the shared prefs XML file the Kitkat device has 'rw-rw-r--' (0664) while the marshmallow device has 'rw-rw----'(0660). And when changing it to 664 in root explorer it works, but will change back on restart.

EDIT: I put new File("/data/data/PACKAGE_NAME/shared_prefs/PACKAGE_NAME_preferences.xml").setReadable(true, false); in all activities's onPause and onDestroy. When you attempt to read the preferences in initZygote(...) it says its doesn't exist, and is not world- or file- readable but can still get data from the XML file, which can be shown by prefs.getAll.size(). When handleLoadPackage(..) is executed, it will be completely readable. Note, I also refresh/reload the preferences in each hook (to update settings on runtime). A dodgy workaround but still works.

[wanam]

@pbombnz Actually setReadble(true, false) is not enough on MM (at least on my case TW MM), as it just sets 660 permission, we need to set it to 664 to get a readable prefs on the module process.

The only way that seems to work properly for me is to set it through the PreferenceFragment:

getPreferenceManager().setSharedPreferencesMode(Context.MODE_WORLD_READABLE);
getPreferenceManager().setSharedPreferencesName(YourActivity.class.getSimpleName());
sharedPref = getActivity().getPreferences(Context.MODE_WORLD_READABLE);

I change the prefs file name to the activity's simple name because it's used on "getActivity().getPreferences" that seems the only method that still sets the required permission "664" for the flag "MODE_WORLD_READABLE".

[F-i-f]

Having the same problem with my Xposed module on a Nexus 5 running MM.
It seems like SELinux is kicking in as I found these AVCs:
system:ui: type=1400 audit(0.0:49): avc: denied { search } for name="com.fifsource.android.resolveractivitytweaks" dev="mmcblk0p23" ino=603480 scontext=u:r:system_app:s0 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0

Yep, the system UI cannot read data in packages.
Are there any solutions?

[liudongmiao]

@F-i-f Normally, if the hooked method is in system process, it's in system process; and the hooked method in app process, it's in app process. So, don't read app's files in system process. The hooked app can get rid of the xposed if it's in app's process. (I do this in my xposed module Prevent Running.)

For Prevent Running (not just a xposed module), I never read the file from system process (This works in below 4.4, but doesn't work in 5.0+). I use other android component to read/write files, like content provider and receiver.

[rovo89]

@F-i-f Yep, that's exactly the issue we're talking about here. There's no solution to this yet.

[liudongmiao]

@rovo89 but, why app can read /data/de.robv.android.xposed.installer/log/error.log?

[rovo89]

Which app? The issue is that system apps can't access data files from user apps. Xposed Installer can obviously read its own data files.

[liudongmiao]

The error.log is logged by xposed module, and by system process too.

And, of course, prevent running (http://repo.xposed.info/module/me.piebridge.forcestopgb) read /data/de.robv.android.xposed.installer/log/error.log directly when it's not activated in xposed installer.

https://github.com/liudongmiao/ForceStopGB/blob/master/src/me/piebridge/prevent/ui/util/ReportUtils.java#L48 I always received the error.log.