[Xposed General] rovo89:
Thanks a lot for your detailed reply!

Yes, it has always been like this. Only /system/bin/app_process needs to be replaced on the system partition, everything else is in /data.

Whenever I set app_process to the original zygote context, this fails:

access("/data/data/de.robv.android.xposed.installer/bin/XposedBridge.jar", R_OK)

And I get such audit messages:

type=1400 msg=audit(1402425979.373:155): avc: denied { search } for pid=22027 comm="zygote" name="data" dev="mmcblk0p28" ino=1490945 scontext=u:r:zygote:s0 tcontext=u:object_r:app_data_file:s0 tclass=dir
type=1400 msg=audit(1402425979.373:156): avc: denied { search } for pid=22027 comm="zygote" name="data" dev="mmcblk0p28" ino=1490945 scontext=u:r:zygote:s0 tcontext=u:object_r:app_data_file:s0 tclass=dir
type=1400 msg=audit(1402425979.373:157): avc: denied { read } for pid=22027 comm="zygote" name="input" dev="tmpfs" ino=6392 scontext=u:r:zygote:s0 tcontext=u:object_r:input_device:s0 tclass=dir
type=1400 msg=audit(1402425979.373:158): avc: denied { search } for pid=22027 comm="zygote" name="data" dev="mmcblk0p28" ino=1490945 scontext=u:r:zygote:s0 tcontext=u:object_r:app_data_file:s0 tclass=dir
type=1400 msg=audit(1402425979.373:159): avc: denied { search } for pid=22027 comm="zygote" name="data" dev="mmcblk0p28" ino=1490945 scontext=u:r:zygote:s0 tcontext=u:object_r:app_data_file:s0 tclass=dir
type=1400 msg=audit(1402425979.373:160): avc: denied { search } for pid=22027 comm="zygote" name="data" dev="mmcblk0p28" ino=1490945 scontext=u:r:zygote:s0 tcontext=u:object_r:app_data_file:s0 tclass=dir

Inode 1490945 = /data/data/, so it isn't even about the file itself, but it's cut off at the root (worse than I thought it would be).

Even if I ignore this error and add the JAR file with Xposed's Java classes to the classpath anyway, it can't continue because the VM can't access the JAR itself. That's the actual problem, no matter what I do to detect whether the file exists.

For the library, I had seen some other errors (dlopen couldn't map segment 2, audit log showed that the it would need "execute" permissions), but I can't reproduce them right now. In my current dev version, I load the library later, so maybe that solved it.

Ok, so it's not really an option for the masses, at least it's not something that several apps should handle each on their own...

You say "can be made read/writable" - what exactly do you mean with that? Are there any options for contexts? Or do you mean a file could be changed from "u:object_r:app_data_file:s0" to some other, more accessible context?

I expected that.. Pretty sure that this can't be done from the zygote context, but as it is running as root, couldn't I call "su" and change the file contexts as needed? Or do you expect that even with "su" and the context awareness that you introduced, this won't be possible?

Sure, the context would need to be set. Actually I currently have all the files in subdirectories of /data/data/de.robv.android.xposed.installer/, but I was wondering whether a custom subdirectory in /data might be less restricted than /data/data/, maybe had more sensible default contexts or things like that.

As system_server and all apps are forked from the Zygote process, would that change something? I thought of opening a pipe or shared mmap at the very beginning and let all the children use it. Or would restrictions also apply when the handle is already open?

Exactly those different subcontexts might be the problem, because config files need to be readable by zygote, system_server and all the apps. That's what I'm worried about. Otherwise, it sounds fine.

I can't switch back from e.g. system_server to zygote context, can I? So if I want to use some of the additional permissions that the system_server has, it would have to be in a new or forked process?