Qu'est-ce que l'UID "u#_everybody" ?

Comme indiqué aquí :

Les interactions inter-utilisateurs sont bloquées à l'aide de l'option everybody GID.

Android réserve des UIDs / GIDs allant de 10000 a 19999 pour les applications. AID_EVERYBODY est un des groupes spéciaux, qui est utilisé pour contrôler la capacité de lecture/écriture de l'application sur le stockage externe ( /sdcard ). Ce groupe a GID 9997 pour le propriétaire de l'appareil. S'il existe des profils ou plusieurs utilisateurs, le GID prend la forme suivante XX09997 où XX ist ID utilisateur . Donc u11_everybody se résout en UID 1109997 y u11_a500 a 1110500 .

A partir d'Android 6, chaque application a sa propre vue de l'écran. /sdcard qui est contrôlé en exposant /data/media/[UserID] avec des permissions différentes. Pour ce faire, on utilise un système de fichiers émulé (précédemment connu sous le nom de FUSE Maintenant. sdcardfs ) et les espaces de noms de montage. Pour le propriétaire du dispositif, c'est-à-dire UserId 0 , /sdcard apparaît avec les éléments suivants trois VIEWs des ensembles d'autorisations :

1. Pour les processus s'exécutant dans l'espace de noms de montage Root, tels que init , netd , vold etc., les permissions apparaissent comme 0.1015 , 0771 .
2. Pour les processus ayant android.permission.READ_EXTERNAL_STORAGE les permissions apparaissent comme 0.9997 , 0750 .
3. Pour les processus ayant android.permission.WRITE_EXTERNAL_STORAGE les permissions apparaissent comme 0.9997 , 0770 .

La capture d'écran montre trois émules VIEWs avec différents gid y mask pour obtenir différents ensembles de permissions : * Les fichiers n'ont jamais la permission d'être exécutés, c'est-à-dire qu'ils n'ont pas le droit d'être exécutés. mask=6 devient mask=7 pour les fichiers.
* mask=23 semble erronée, peut-être un bug ? En réalité, c'est mask=27 .

En considérant trois VIEWs nous avons quatre situations :

1. Processus s'exécutant avec les privilèges Root, c'est-à-dire UID 0 ont toujours un accès R/W à /sdcard . Cependant, si un processus non privilégié s'exécutant dans l'espace de noms de montage Root veut un accès R/W à /sdcard qui seraient contrôlés par le groupe AID_SDCARD_RW (GID 1015 ). Un exemple est Démon ADB qui fonctionne avec UID / GID 2000 mais 1015 dans ses groupes de complémentarité.

Puisque chaque application fonctionne avec son UID unique dans un espace de nom de montage séparé :

2. Apps sans READ/WRITE_EXTERNAL_STORAGE ne pourront pas lire ou écrire sur le site de /sdcard .

Puisque chaque application est un membre de everybody (9997) groupe :

3. Apps avec READ_EXTERNAL_STORAGE l'autorisation pourra lire le /sdcard .
4. Apps avec WRITE_EXTERNAL_STORAGE l'autorisation pourra être écrite à /sdcard . Ainsi, l'application a un accès complet R/W aux données partagées / externes. Public Storage y compris d'autres applications Private Storage .

Il y a un exception aux règles ci-dessus pour les applications ; chaque application a toujours un accès R/W à sa propre application. Stockage privé externe . Prenons l'exemple d'une application com.xyz avec UID 10500 . En dehors du répertoire interne de données /data/data/com.xyz L'application a une Private Storage répertoire /sdcard/Android/data/com.xyz avec l'UID du propriétaire 10500 . Ce répertoire est donc toujours accessible en lecture et en écriture par l'application.
Veuillez noter que /sdcard/Android/data ist traversable pour toutes les applications, mais pas d'accès R/W.

De la même manière, cela fonctionne pour les autres comptes/profils d'utilisateurs.

Opaque Binary Blobs : (OBB)

Certaines applications ont besoin d'un espace de stockage supplémentaire pour sauvegarder des fichiers volumineux qui ne peuvent pas être inclus dans l'application. .apk en raison de la limite de 100MB limite de taille . Il y a deux possibilités obb les emplacements où ces fichiers sont enregistrés : /data/media/obb/ y /sdcard/Android/obb/ . Le premier a été introduit avant le concept de multi-utilisateurs, il n'est donc disponible que pour le propriétaire de l'appareil. Le second est disponible pour les applications dans les comptes/profils multi-utilisateurs également.
L'accès à l'ancien est contrôlé de la même manière que celui à l'ancien. /sdcard Le stockage externe privé est toujours accessible par une application, tout comme le stockage externe privé.

RELATION :

• Qu'est-ce que /storage/emulated/0/ ?
• Fichiers publics et privés sur le stockage externe
• Pourquoi le répertoire 'storage/emulated/' est-il inaccessible ?
• Comment fonctionne le mappage des permissions d'Android avec les UID/GID ?
• Les utilisateurs multiples sont-ils protégés les uns des autres différemment des applications ?
• Comment l'espace disque est utilisé sur un appareil Android ? (voir les répertoires occupés par une application sous APPS SPACE USAGE ).