About Android Permissions

Android is running on the Linux kernel, Android and Linux have their own set of strict security and permissions mechanism, here is a brief introduction to the Linux file system permissions and how to get system permissions in Android.

(i) Permissions on the Linux file system

The following is a typical Linux file system permission Description:
　　　　-rwxr-x--x System System 4156 2012-06-30 16:12 test.apk.

About permission descriptions for "-rwxr-x--x"

• The first character represents the type of the file (such as a directory, file, or linked file, and so on):

1. When [d] is the directory;
2. When [-] is the document;
3. If [l] is indicated as a link file (link file);
4. If [b] is indicated as the device file inside the storage interface device (can be random access device);
5. If [C] is indicated as a serial port device in the appliance file, such as a keyboard, mouse (disposable reading device)

• In the next character, the combination of three parameters with three and all "rwx" < [R] for readable (read), [W] for writable (write), [x] for executable (execute) Note that the location of these three permissions does not change if there is no permission , there will be a minus sign [-] only >

1. The first group is "the corresponding user's permission", take "test.apk" that file as an example, the owner of the file can be read and writable executable;
2. The second group is "permission of the corresponding user group", unreadable and non-writable executable;
3. The third group is "other people's rights" unreadable and non-writable executable.

Notes on "System system"

The first represents the corresponding user, that is, test.apk is the file belonging to the system user;

The second represents the corresponding user group.

Notes on "4156"

File size

Notes on "2012-06-30 16:12"

File Latest modification Time

These permission descriptions represent the appropriate user/user group and other people's access to the file, which is completely unrelated to the permissions that the file has to run . For example, the above example can only show that the system user has read and write permissions to the file, the system group's users have read and execute permissions on the file, and others have only execute permissions on the file. And what test.apk can do when it runs up is irrelevant. Do not look at the APK file system belonging to the System/system users and user groups, or root/root users and user groups, it is assumed that the APK has system or root permissions. APK program is run on the virtual machine, corresponding to the unique Android permissions mechanism, only to reflect the file system on the use of Linux permissions settings.

(ii) Android's permission rules

(1) The APK in Android must be signed
This signature is not based on an authoritative certificate, and does not determine whether an app is allowed to install, but a self-signed certificate. It is important that the permissions on theAndroid system are based on signatures . For example: The system level of permissions have a specific signature, the signature is not correct, the permissions will not be obtained. The default generated APK file is the debug signature. The signature used to get the system permission is described later.

(2) UserID-based process-level security mechanisms
Process has a separate address space, the process and process by default is not accessible to each other, Android by assigning a unique Linux userid for each apk to implement, the name "App_" plus a number, such as app_43 different userid, run in different processes, So the APK is not accessible to each other by default.

Android offers one of the following mechanisms that allows two apk to break the aforementioned barrier.
Using the Shareduserid attribute in Androidmanifest.xml to assign the same userid to different packages, by doing so, two packages can be treated as the same program, and the system assigns the same userid to two programs. Of course, for security reasons, two APK requires the same signature, otherwise there is no point in verifying it.

(3) The default APK generated data is not visible to outsiders
By doing this,Android assigns the program's userid to the data stored by the program. with Linux's strict access to the file system, there is no mechanism for the APK to have access to each other like data.
Example: A file created by my app with the default permissions as follows, you can see that only a program with UserID App_21 is able to read and write to the file.
-RW-------app_21 app_21 87650 2000-01-01 09:48 test.txt

So how to open it up?

• use the mode_world_readable and/or mode_world_writeable tag . When creating a new file with Getsharedpreferences (string, int), Openfileoutput (string, int), or openorcreatedatabase (Str ing, int, sqlitedatabase.cursorfactory), you can use the mode_world_readable and/or mode_world_writeable Y other package to read/write the file. When setting these flags, the file was still owned by your application and its global read and/or write permissions had B Een set appropriately so any other application can see it.

(4) explicit permission declaration in Androidmanifest.xml
The Android default app does not have any permissions to manipulate other apps or system-related features, and the app needs to explicitly apply the appropriate permissions when doing certain things. when the app is installed, package installer detects the permissions requested by the app, depending on the app's signature or prompting the user to assign the appropriate permissions. The permission is not detected during the run of the program. If permission acquisition fails during installation, execution will go wrong and the user will not be prompted for insufficient permissions. In most cases, a failure caused by insufficient permissions will cause a SecurityException to be logged in the System log.

(5) Permission inheritance/userid inheritance
When we encounter an APK with insufficient permissions, we sometimes consider writing a Linux program, and then the APK calls it to complete something that it does not have permission to complete, unfortunately, this method is not feasible. As mentioned earlier, Android permissions are at the process level, that is, an APK app starts a child process permissions can not exceed the permissions of its parent process (that is, the rights of the APK), even if running an app alone has permission to do something, but if it is called by an APK, then the permissions will be limited. In fact, Android implements this mechanism by assigning the userid of the parent process to the child process.

(iii) Analysis of the problem of common authority insufficiency

The first thing to know is that the normal APK program is run on a non-root, non-system level, that is, to see the permissions of the file to be accessed, looking at the last three bits. In addition, the permissions of the APK installed through System/app are generally higher than the permissions of the APK installed directly or adb install.
To get to the problem, running an Android application is not a sufficient privilege to run, generally in two situations:
(1) Log can clearly see the prompt for insufficient permissions.
This situation is generally missing the appropriate permission settings in the Androidmanifest.xml, well find a list of permissions, should be resolved, is the most easy to handle the situation. Sometimes the permissions are added, but still reported insufficient authority, what is the situation? The Android system has some APIs and permissions that require the APK to have a certain level to run. such as Systemclock.setcurrenttimemillis () modify the system time, write_secure_settings permissions seem to need to have system-level permissions, that is, UserID is System.

( 2) Log does not report the lack of authority, but some other exception hints, this may also be due to insufficient permissions.
For example: we often want to read/write a configuration file or some other files that are not created by ourselves, often reported java.io.FileNotFoundException errors. The system thinks that the more important file general permission settings will be more stringent, especially some very important (configuration) files or directories. such as
-r--r-----bluetooth bluetooth      935 2010-07-09 20:21 dbus.conf
Drwxrwx--x sys tem   system            2010-07-07 02:05 Data

Dbus.conf seems to be a Bluetooth configuration file, from the rights point of view, it is impossible to change, non-Bluetooth users even read the right to not. /data directory is the private data for all programs, By default, Android does not allow the normal apk to access the contents of the/data directory, the permissions set through the data directory, other users do not have Read permissions. So the ADB normal permissions under the data directory to knock the LS command, you will get Opendir failed, Permission denied error, through the code file.listfiles () can not get the contents of the data directory.

About Android Permissions