This answer says:
Because of the way directory/file permissions are configured on Android, you need to have the
su
binary on your/system
partition in order for it to work. Putting elsewhere will not suffice, because it will not have the permissions it needs to actually allow processes to switch users.
What is the mechanism that causes binaries in /system
to have special privileges?
Specifically, if I moved /system/xbin/su
to /data/xbin/su
(and changed anything relevant to point to /data/xbin/su
instead of /system/xbin/su
), what would be different?
My guess is that these privileges are enforced by SELinux.
I searched Android's sources, and found in platform/system/sepolicy/private/file_contexts:
/system(/.*)? u:object_r:system_file:s0
and in platform/system/sepolicy/public/domain.te:
allow { appdomain coredomain } system_file:file { execute read open getattr map };
However, I also found in platform/system/sepolicy/private/file_contexts:
/system/xbin/su u:object_r:su_exec:s0
and in platform/system/sepolicy/public/domain.te:
# Nobody should be able to execute su on user builds.
# On userdebug/eng builds, only dumpstate, shell, and
# su itself execute su.
neverallow { domain userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
So I am confused.
No comments:
Post a Comment