3

In (multi-user) Android there are UIDs like these:

  • u0_everybody
  • u10_everybody
  • u11_everybody

Those seem different to the usual uXX_aYY UIDs used for the applications. What is their purpose? Is this a way to make files available to all applications (share between applications of a user account)?

Improve this question

1 Answer 1

Reset to default
6

As stated here:

Cross-user interactions are blocked using the everybody GID.

Android reserves UIDs / GIDs ranging from 10000 to 19999 for apps. AID_EVERYBODY is one of the special groups, which is used to control app's read / write ability to external storage (/sdcard). This group has GID 9997 for device owner. If there are profiles or multiple users, GID takes form XX09997, where XX is UserID. So u11_everybody resolves to UID 1109997 and u11_a500 to 1110500.

Starting with Android 6, every app has it's own view of /sdcard, which is controlled by exposing /data/media/[UserID] with different permissions. This is achieved by making use of an emulated filesystem (previously FUSE, now sdcardfs) and mount namespaces. For device owner i.e. UserId 0, /sdcard appears with following three VIEWs of permission sets:

  1. For processes running in root mount namespace such as init, netd, vold etc., permissions appear as 0.1015, 0771.
  2. For processes having android.permission.READ_EXTERNAL_STORAGE, permissions appear as 0.9997, 0750.
  3. For processes having android.permission.WRITE_EXTERNAL_STORAGE, permissions appear as 0.9997, 0770.

Screenshot shows three emulated VIEWs with different gid and mask values to get different permissions sets: enter image description here * Files never have executable permission i.e. mask=6 becomes mask=7 for files.
* mask=23 is appearing wrong, may be a bug? In actual it's mask=27.

Considering three distinct VIEWs, we come with four situations:

  1. Processes running with root privileges i.e. UID 0 have always R/W access to /sdcard. However if a non-privileged process running in root mount namespace wants R/W access to /sdcard, that would be controlled by group AID_SDCARD_RW (GID 1015). An example is ADB daemon which runs with UID / GID 2000 but 1015 in its supplementarry groups.

Since every app runs with its unique UID in a separate mount namespace:

  1. Apps without READ/WRITE_EXTERNAL_STORAGE permissions won't be able to read or write to /sdcard.

Since every app is a member of everybody (9997) group:

  1. Apps with READ_EXTERNAL_STORAGE permission will be able to read the /sdcard.
  2. Apps with WRITE_EXTERNAL_STORAGE permission will be able to write to /sdcard. So the app has full R/W access to shared / external Public Storage including other apps' Private Storage.

There's an exception to above rules for apps; every app has always R/W access to its own External Private Storage. Let's take example of app com.xyz with UID 10500. Apart from internal data directory /data/data/com.xyz, app has a Private Storage directory /sdcard/Android/data/com.xyz with owner UID 10500. So this directory is always readable / writable by the app.
Please note that /sdcard/Android/data is traversable for all apps, but no R/W access.

In the same way it works for other user accounts / profiles.

Opaque Binary Blobs: (OBB)

Some apps need additional storage to save large files which can't be included in .apk file due to 100MB maximum size limit. There are two possible obb locations where these files are saved: /data/media/obb/ and /sdcard/Android/obb/. The former was introduced before multi-users concept, so it's only available to device owner. Later is available to apps in multi-user accounts / profiles as well.
Access to former is controlled the same way as to /sdcard, while later is always accessible by an app as is the private external storage.

RELATED:

Improve this answer
3
  • considering the length you did go (i.e. reference parts of the source code) I can appreciate the effort put in this answer and thank you. Here as comment also some points it'd be great to get confirmed. 1) with Android 6 different users (multi-users) are better isolated, than just mere apps (using mount namespace), true? 2) the various types (i.e. per user) of the everybody (9997) GID serves the purpose to give access to /sdcard access to apps, allow apps to access a common place /sdcard and not only their "app private" /sdcard/Android/data/com.xyz, correct?
    – humanityANDpeace
    Commented Apr 10, 2019 at 7:09
  • there is(?? was ) this obb folder in Android, does this "share between users"-mechanism still work in combination with the mount namespace isolation?
    – humanityANDpeace
    Commented Apr 10, 2019 at 7:11
  • @humanityANDpeace 1) I have mentioned this in a comment on your previous question, can add as answer if needed. The only notable additional isolation between apps of different user accounts is the separate shared storage (i.e. /sdcard). 2) Yes, everybody group is only to control apps' access to shared public external storage (/sdcard) and other apps' private external storage (/sdcard/Android/data/*). An app has always R/W access to its own private external storage /sdcard/Android/data/com.xyz. OBB section is added to answer
    – Irfan Latif
    Commented Apr 10, 2019 at 11:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .