The apk program runs on the virtual machine, which corresponds to the unique permission mechanism of Android. Only when it is embodied in the file system can the permissions of linux be set.

(permissions on the linux file system

-rwxr-x-x system4156 2010-04-3016:13test.apk.

Represents the access rights of the corresponding users/user groups and others to this file, regardless of the rights that the file has at runtime.

For example, the above example can only show that the system user has read and write execution permission for this file; Users in the system group have read and execute permissions for this file; Others have only execute permission for this file.

It doesn't matter what test.apk can do after it runs.

Just because apk belongs to system/system users and user groups, or root /root users and user groups on the apk file system, don't assume that apk has system or root permissions.

(Permission rules for Android

(1) apk in Android must be signed.

This signature is not based on an authoritative certificate, it does not decide whether to allow an application to be installed, but a self-signed certificate.

Importantly, some permissions of the android system are based on signatures. For example, system-level permissions have a special corresponding signature, and if the signature is wrong, permissions cannot be obtained.

By default, the generated APK file is signed by debug.

The signature used when obtaining system permissions, see: How to get Android applications to obtain system permissions.

(2) Process-level security mechanism based on user identification

As we all know, processes have independent address spaces. By default, processes cannot access each other, which is a very reliable protection mechanism.

Android is implemented by assigning a unique linux userID to each package (apk) installed on the device. The name is "app_" plus a number, such as app_43.

Different UserID run in different processes, so apk cannot access each other by default.

Android provides the following mechanism, which enables two apk to break the barriers mentioned above.

In AndroidManifest.xml, the sharedUserId attribute is used to assign the same UserId to different packages. By doing so, two packages can be regarded as the same program.

Both programs will be assigned the same user ID. Of course, for security reasons, two packages need to have the same signature, otherwise it is meaningless without verification.

(add a point here: it doesn't mean that the same UserID is assigned, and the two programs are running in the same process. The following is an excerpt from the PS instruction.

Obviously, the PID of the two processes corresponding to system and app_2 are different. I wonder how Android implements its mechanism? )

User PID PPID

System 953 883187340 55052 FFFFFFAFE0CBCC S System _ Server

app _ 2 1072 883 100264 19564 ffffffff AFE 0 DCC 4S com . Android . input method。

System10838831180823192fffffafe0dcc4s android.process.omsservi.

app _ 2 1088 883 156464 45720 ffffffff AFE 0 DCC 4S Android . process . acore

(3) The data generated by default apk is invisible to the outside world.

The implementation method is: Android will assign the UserID of the program to the data stored in the program.

With the strict file system access rights of Linux, the mechanism that apk can't access each other's seemingly data is realized.

Example: Files created by my application have the following default permissions. It can be seen that only programs with UserID of app_2 1 can read and write this file.

-rw-app _ 2 1 app _ 2 1 87650 2000-0 1-0 1 09:48 test . txt

How to open it?

& lt 1 & gt； Use mode _ world _ readable and/or mode _ world _ writable tags.

When you create a new file using getSharedPreferences(String, int), openFileOutput(String, int) or openOrCreateDatabase(String, int, SQLiteDatabase). CursorFactory), you can use the MODE_WORLD_READABLE and/or mode _ world _ writable flags to allow any other package to read/write the file. When these flags are set, the file is still owned by your application, but its global read and/or write permissions have been set appropriately, so it can be seen by any other application.

(4) Explicit permission declaration in 4)AndroidManifest.xml

The default application of Android does not have any authority to operate other applications or system-related functions, and the application needs to explicitly apply for the corresponding authority when doing some operations.

In general, you need to apply for appropriate permissions for the following operations:

During the running of the program, certain permissions may be enforced in many places:

When the system is called, the application is prevented from performing certain functions.

When starting an activity, prevent the application from starting the activity of other applications.

Send and receive broadcasts to control who can receive your broadcasts or who can send them to you.

When accessing and operating a content provider.

Bind or start a service.

When installing an application, the package installer will detect the permissions requested by the application and assign the corresponding permissions or prompt the user according to the signature of the application.

Permissions are not detected during program operation. If the permission acquisition fails during the installation, the execution will be wrong and the user will not be prompted that the permission is insufficient.

In most cases, a failure due to insufficient permissions will raise a SecurityException, which will be recorded in the system log.

(5) Permission inheritance/user identification inheritance

When we encounter the lack of authority of apk, we sometimes consider writing a linux program, and then apk calls it to do something that it has no authority to do. Unfortunately, this method doesn't work.

As mentioned above, android permissions are operated at the process level, which means that the permissions of the child process started by the apk application cannot exceed the permissions of its parent process (that is, the permissions of the apk).

Even if running an application alone has the right to do something, if it is called by apk, the right will be limited.

In fact, android implements this mechanism by assigning the UserID of the parent process to the child process.

(c) Analysis of common problems of insufficient power.

First of all, we should know that ordinary apk programs run at non-root and non-system level, that is to say, when we look at the permissions of files to be accessed, we look at the last three.

In addition, the authority of apk installed through system/app is generally higher than that of directly installed apk or adb.

Anyway, when you run an Android application, you encounter insufficient permissions, which are generally divided into two situations:

You can clearly see the prompt of insufficient authority in the (1) log.

This situation is generally due to the lack of corresponding permission settings in AndroidManifest.xml, which should be solved by looking up the permission list, which is the easiest situation to deal with.

Sometimes the permissions are increased, but the permissions are still not enough. What happened?

Android system has some APIs and permissions that require apk to have a certain level to run.

Such as a system clock. Setcurrenttimemillis () modifies the system time, and the WRITE_SECURE_SETTINGS permission seems to require system-level permission.

That is to say, UserID is system

(2) There is no report of insufficient authority in the log, but there are some other anomalies, which may also be caused by insufficient authority.

For example, we often want to read/write a configuration file or other files that we didn't create, and we often report an error java.io.FileNotFoundException.

The system thinks that the general permissions of more important files will be set more strictly, especially some very important (configuration) files or directories.

such as

-r-r-bluetooth bluetooth 935 2010-07-09 20: 21dbus.conf

Drwxrwx-x system system 20 10-07-07 02:05 data

Dbus.conf seems to be the configuration file of Bluetooth. From an authoritative point of view, it cannot be changed, and non-Bluetooth users have no right to read it.

Private data of all programs are stored in the /data directory. By default, android does not allow ordinary apk to access the contents in the /data directory. According to the permission settings of the data directory, other users have no read permission.

Therefore, if you type the ls command in the data directory under the general authority of adb, you will get the errors of Opendir failed and Permissiondenied, and you cannot get the contents of the data directory through the code file.listfiles ().

In both cases, you generally need to upgrade the permissions of apk. At present, the permission that apk can upgrade to is system (see: How to get system permission for Android applications).

As for whether there is a root level, how to upgrade to the root level is unknown. Friends who know, please tell us, thank you very much.

/hpyfei/blog/item/a 2730 122 c 1 CAC 7 eed 6 CAE 260 . html