An overview,

In the actual development often encounter a variety of ID, this is because in the development process of the computer, the need to perform each step of the program to mark, through the association of these marks for the unified management of the system. PID, UID, GID, EUID, etc., in fact, there is no need to memorize these ids. You only need to know the meaning of their names to understand their corresponding meanings.

Concept analysis in Linux

2.1 the UID

The concept of user in Linux is divided into: common user, root user, and system user. Common user: a common user. In Linux, you need to log in to the system using the user name and password to obtain the user’s permissions. The permissions include the restriction on adding, deleting, modifying, querying files in the system and executing commands. ROOT user: the ROOT user whose UID is 0 can add, delete, modify, query any file in the system and run any command. Therefore, the ROOT user is extremely dangerous. Improper operations will cause the system to crash. System user: a virtual user created by the system and not developed by users, whose UID ranges from 1 to 499. For example, when running the MySQL database service, system user MySQL is used to run the mysqld process.

2.2 GID

A GID encapsulates a UID, meaning it contains multiple Uids. In Linux, each UID has a GID. The GID is designed to facilitate unified management of the system. For example, when adding permissions to a file, only users in the admin group are allowed to access the GID. Therefore, when assigning permissions to a file, only users in the group need to be assigned the GID and all users in the group can obtain permissions. It is also convenient for unified operation when deleting.

In addition to uids and Gids, it also includes its extended valid users, groups (euid, eGID), file system users, groups (fsuid, fsgid), and saved Settings users, groups (suid, sgid).

2.3 the PID

When the program is running, the system will assign a unique process ID (PID) to each executable program. The direct function of PID is to show the file operation permission that the program has. Different executable programs run without affecting each other, and data access between each other is limited by permissions.

Iii. Concept analysis in Android

Since Android is based on Linux, the concepts of User Identifier (UID), Group Identifier (GID), and Process Identifier (PID) also come from Linux. But Android is a client-based system that has been stripped of Linux.

3.1 the UID and GID

In Android, a UID corresponds to an executable program. For a common program, its UID corresponds to a GID. During the retention period of the program in the Android system, its UID remains unchanged. In Android, the sandbox concept is used to manage applications. Different applications have unique UID and PID, which identify their “resources”, including file directories, database access, network, sensors, and logs. Like Linux, they don’t affect each other.

  • Full exposure: If an Activity, Service, or ContentProvider is declared in AndroidMaindfest. XML, setting this attribute to true indicates that the class allows external data access. If intentFilter is specified, the default exported is true, and fasle is mandatory. Exported /intentFilter The default exported is fasle if no other Settings are specified (export /intentFilter).
<activity android:name=".TestActivty" android:exported="true"/>
Copy the code
  • Androidmaindest. XML declares the Activity, Service, or ContentProvider with added permission, indicating that if other applications need access to the class, they need to add the same permissions as the application in the class declaration, as shown below. Declare private permissions.
<activity android:name=".TestActivty" android:permission="com.xiaohan.permission"/>
Copy the code

Add access permission description.

<uses-permission android:name="com.xiaohan.permission"/>
Copy the code
  • Private exposure: Different from the above two types of exposure, if you want to access any data between different applications, you need to use sharedUserId+ the same set of signatures. Only in this way can you run in the same process (in the same sandbox) to ensure the mutual access of data.
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.xiaohan.test"// Application package name Android :sharedUserId="com.xiaohan.sharedUID"// Expose unique identifier android:sharedUserLabel="@string/app_name"// It must be a string imported into the resource file android:versionCode="1"
    android:versionName="1.1.0"
    android:installLocation="internalOnly">// The installation location is in the internal directory by default, including auto and preferExternalCopy the code

3.2 the PID

In 3.1, the concept of PID has been constantly mentioned. Generally, a unique PID is allocated to prevent mutual interference between different applications. However, the same Android application can have multiple Pids and it is also convenient to add.

 <activity android:name=".TestActivty" android:process="com.xiaohan.test"/>
Copy the code

Add is very convenient, but can’t use, because in the same application (PID), between design and program the most is the communication between threads, once independent PID is involves the inter-process communication, similar to the two different applications, of course can also through the private exposure and permissions exposed way to implement the data communication, but the system overhead.

This article mainly describes the concepts of UID, GID and PID, and their application in Linux and Android. The following points need to be paid special attention to for The Android system:

  • Different applications have unique UUIds, and the same UID can have different Pids.
  • For the exposure of data between different PID can be private exposure and exposure of authority, for different UUIds can be fully exposed;
  • If an application is a system application, the application data can be directly accessed without other applications being exposed.