3

I've build a custom android ROM. I've signed my application with platform signature and have added android:sharedUserId="android.uid.system" in the manifest file. My app is granted all "signature" and "system" level permission but access to system files are not granted.

    Log.w("PC", String.valueOf(checkCallingOrSelfPermission("android.permission.ACCESS_SURFACE_FLINGER")== PackageManager.PERMISSION_GRANTED)); // true
    Log.w("PC", String.valueOf(checkCallingOrSelfPermission("android.permission.READ_FRAME_BUFFER")== PackageManager.PERMISSION_GRANTED));      // true
    Log.w("PC", String.valueOf(checkCallingOrSelfPermission("android.permission.INJECT_EVENTS")== PackageManager.PERMISSION_GRANTED));          // true

    Log.w("PC", String.valueOf(new File("/dev/graphics/fb0").canRead()));                      // false
    Log.w("PC", String.valueOf(new File("/data/misc/wifi/wpa_supplicant.conf").canRead()));   // false

permissions of the files are:

ls -l /dev/graphics/fb0
crw-rw---- root     graphics  29,   0 2014-02-12 09:43 fb0

ls -l /data/misc/wifi/wpa_supplicant.conf
-rwxrwx--- wifi     wifi          282 2014-02-11 19:04 wpa_supplicant.conf

Is there any way to get the access to these files?

Charles
  • 50,943
  • 13
  • 104
  • 142
PC.
  • 6,870
  • 5
  • 36
  • 71

3 Answers3

5

I've found the solution to this. Along with the platform signature and android:sharedUserId="android.uid.system" you also need to add android:process="system" in the <application /> section of the manifest file.

PC.
  • 6,870
  • 5
  • 36
  • 71
  • It seem surprising that this would be the solution, as it is not the process but rather the user id which matters for unix-level permissions. – Chris Stratton Feb 12 '14 at 17:19
  • I agree with you Chris. Even I was surprised with this finding. I've verified it multiple times and surprisingly it works. – PC. Feb 13 '14 at 04:22
1

Android apps are each run with a unique Linux UID/GID. Obviously you are not the owner nor in the group for those files. The easiest thing to do would be to change the file permissions to world readable. Not sure what the security implications are for those files in that scenario. You should be able to do it via su in adb shell. The permanent way is to change the file permissions when doing a build. If your app is something that you are including with your custom rom, you may be able to set the GID. Take a look at system/core/include/ private/android_filesystem_config.h for default UID/GID permissions.

David C Adams
  • 1,953
  • 12
  • 12
  • but to change the permission which regular user do not have permission, afaik device must be rooted – N Sharma Feb 12 '14 at 04:58
  • I do not want to change the permissions to world readable! I'm not including my app in the custom ROM, I want the users to install my app if they want. I've read that adding `android:sharedUserId="android.uid.system"` to the manifest makes the application a member of the root group. But unfortunately it did not work. What else can I try? – PC. Feb 12 '14 at 05:04
  • 1
    I would try finding out what UID the app that owns those files is being run with and set your sharedUserId to that instead of relying on belonging to the root group. Also, really make sure that you are signing your app with the platform key. It sounds like you are; but if that isn't done right, nothing will work. – David C Adams Feb 12 '14 at 05:19
  • Another reason I want to be a root user is that I want to acquire ports < 1024. http://stackoverflow.com/a/2695160/925202 – PC. Feb 12 '14 at 06:29
  • Well, the android_filesystem_config.h file contains this: tatic const struct android_id_info android_ids[] = { ... ... { "root", { "system", { "radio", { "bluetooth", { "graphics", { "input", AID_ROOT, }, AID_SYSTEM, }, AID_RADIO, }, AID_BLUETOOTH, }, AID_GRAPHICS, }, AID_INPUT, }, have you tried android:sharedUserId="android.uid.root" ? – David C Adams Feb 12 '14 at 07:08
  • `android.uid.root` did not work. However I've found the solution by googling around your suggestions. thanks a lot. – PC. Feb 12 '14 at 16:01
  • You basically *cannot* run an android application as root (uid = 0) at least not without modifying the code which accomplishes application process creation. The more interesting question is if you are, or are not, succeeding in running as the privileged *but non-root* "system" uid, and if that uid has (either directly or through group membership) access to the files in question. – Chris Stratton Feb 12 '14 at 17:21
  • My Application is running as system user (not root user) - `$id -> uid=1000(system) gid=1000(system)` My requirement was actually to be able to read system files like `/dev/graphics/fb0`, `/data/misc/wifi/wpa_supplicant.conf` and open server sockets on port < 1024. I'm just using plain android valina build, and the solution I've posted works well in the environment. – PC. Feb 13 '14 at 04:30
1

Your system user is not does not have graphics/wifi group rights. System user is not a superuser, there are limitations.

I don't know what platform you are building, but in my platform I don't have the possibility to ask for wifi and graphics permissions by default. You need to create permissions.

In your android_filesystem_config.h you can see that AID_GRAPHICS and AID_WIFI are already defined, which means that half the work is already done (if you would like to create completely new permissions, you would have to add them to this file). The AID definition is also mapped to a "variable" in a struct in the same file. Here is a snippet of my code:

static const struct android_id_info android_ids[] = {
{ "root",          AID_ROOT, },

{ "system",        AID_SYSTEM, },

{ "radio",         AID_RADIO, },
{ "bluetooth",     AID_BLUETOOTH, },
{ "graphics",      AID_GRAPHICS, },

The second step is to add them to platform.xml. Could be platform dependent, but I can find my platform.xml in /frameworks/base/data/etc. Here is an example of what a permission definition would look like

<permission name="android.permission.GRAPHICS" >
    <group gid="graphics" />
</permission>

The android.permission.GRAPHICS is just an example, you can call it whatever you want. Inside of the permission resource, you define the gid that you want to give to whoever calls this permission. The gid that you use here needs to be identical to the one that is defined in the android_filesystem_config.h file.

Now that you have created a permission, you can call it in your applications AndroidManifest.xml

<uses-permission android:name="android.permission.GRAPHICS" />

You should now have graphics group permissions and be able to read /dev/graphics/fb0

GilCol
  • 391
  • 3
  • 14
  • In case anyone sees this answer in future, additional change needs to be done in frameworks/base/core/res/AndroidManifest.xml . Refer to my answer here https://stackoverflow.com/a/49565570/553094 – androidFan Mar 29 '18 at 21:54