external sd - What is the "u#_everybody" UID?

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)?

Answer

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: <sup>* 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.</sup>

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:

2. 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:

3. Apps with READ_EXTERNAL_STORAGE permission will be able to read the /sdcard.


4. 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: