About the root permission of the adbd Process

The source code of adbd is located in the system/CORE/ADB/directory, and the executable file is located in/sbin/adbd. Run the ps command through ADB. The result is as follows:

User PID ppid vsize RSS wchan PC name

Root 1 0 296 212 c00b0124 unzip d9ec S/init

......

Shell 2183 1 3372 184 ffffffff effececa4 S/sbin/adbd

Root 2204 1859 832 336 00000000 afe0c7dc R PS

In the last row, the parent process of the adbd process is root and the user is shell. For a product in the release status, this is the most normal. However, when such a requirement is encountered during development, the product is already in the release state (the compilation mode has been changed to user), because BSP needs to process some kernel stuff, you must have the root permission after running the ADB shell on the PC. That is, the effect:

User PID ppid vsize RSS wchan PC name

Root 1 0 296 212 c00b0124 unzip d9ec S/init

......

Root 1911 1 3376 184 ffffffff effececa4 S/sbin/adbd

Root 2198 2197 828 332 00000000 afe0c7dc R PS

To achieve this effect, you must start adbd with the root user at startup. Then, let's take a look at how to start adbd in Android.

 

You can take a look at the/init. RC fragment in the root directory of the Android system:

......

# Adbd is controlled by the persist. Service. ADB. Enable System Property

Service adbd/sbin/adbd

Disabled

# Adbd on at boot in emulator

On Property: Ro. kernel. qemu = 1

Start adbd

On Property: persist. Service. ADB. Enable = 1

Start adbd

On Property: persist. Service. ADB. Enable = 0

Stop adbd

......

A trigger is defined here. As long as the persist. Service. ADB. Enable value is set to 1,/sbin/adbd will be started.

 

How to set the persist. Service. ADB. Enable value? An Attribute Service/system/CORE/init/property_service.c is involved here. Before reading the following, let's take a look at the stevguo document that I translated earlier. He described the Attribute Service carefully and methodically.

Http://blog.csdn.net/a345017062/archive/2010/12/17/6083026.aspx

Today, I found that N people on the internet translated this article, and it was a bit dizzy...

Let's continue...

By reading the above documents, we know that the property service loads four files at startup. You can set system attributes in these four files, and set system attributes through APK. However, all these methods have the same results. The adbd is started, the user is shell, and the root permission is still not available. It seems that the difference should be in the compilation mode. After the user compilation mode is changed, the system changes the permissions at adbd startup. Search in the build directory and find such code snippets in Main. mk.

# User/userdebug ##

 

User_variant: = $ (filter userdebug user, $ (target_build_variant ))

Enable_target_debugging: = true

Ifneq (, $ (user_variant ))

# Target is secure in user builds.

Additional_default_properties + = Ro. Secure = 1

 

Tags_to_install: = user

Ifeq ($ (user_variant), userdebug)

# Pick up some extra useful tools

Tags_to_install + = debug

Else

# Disable debugging in plain user builds.

Enable_target_debugging: =

Endif

 

# Todo: always set with_dexpreopt (for user builds) once it works on OSX.

# Also, remove the corresponding block in config/product_config.make.

Ifeq ($ (host_ OS)-$ (with_dexpreopt_buildbot), Linux-true)

With_dexpreopt: = true

Endif

 

# Disallow mock locations by default for user builds

Additional_default_properties + = Ro. Allow. Mock. Location = 0

 

Else #! User_variant

# Turn On checkjni for non-user builds.

Additional_build_properties + = Ro. kernel. Android. checkjni = 1

# Set device insecure for non-user builds.

Additional_default_properties + = Ro. Secure = 0

# Allow mock locations by default for non user builds

Additional_default_properties + = Ro. Allow. Mock. Location = 1

Endif #! User_variant

 

Ifeq (true, $ (Strip $ (enable_target_debugging )))

# Target is more debuggable and adbd is on by default

Additional_default_properties + = Ro. debuggable = 1 persist. Service. ADB. Enable = 1

# Include the debugging/testing OTA keys in this build.

Include_test_ota_keys: = true

Else #! Enable_target_debugging

# Target is less debuggable and adbd is off by default

Additional_default_properties + = Ro. debuggable = 0 persist. Service. ADB. Enable = 0

Endif #! Enable_target_debugging

I will give a general explanation of this Code:

It mainly assigns different values to several attributes by judging the current compilation mode, and then stores the attributes in the additional_default_properties variable. This variable will be written to/default under the root directory. in prop, which is loaded by the property service at system startup. That is to say, the values of the attributes we see in/Default. Prop are set here.

Only the Ro. Secure and persist. Service. ADB. Enable attributes are available. If the current user mode is used, the compilation system will. set secure to 1 and persist. service. ADB. enable is set to 0. that is to say, the system compiled in user mode runs in safe mode, and adbd is disabled by default. Even if the adbd process is opened by setting properties, the user of the adbd process is shell and does not have the root permission. In this way, when a common user or developer obtains a machine and runs the ADB shell through a PC, the user logs on to the machine as a shell user.

Okay. Now, set Ro. set secure to 0 and re-compile. You only need to set the attribute persist. service. ADB. if the value of enable is 1, The adbd process starts as the root user.