top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Why adb changes file permission?

0 votes

A piece of code in adb seems to manipulate the file permission intentionally by copying owner's permission to group'' and 'other''. This causes kernel module load problems if we make some changes to kernel modules, and do adb sync'' oradb push'' to the devices since mode 644 would become mode 666.

     /* copy user permission bits to "group" and "other" permissions */
 mode |= ((mode >> 3) 
 mode |= ((mode >> 3) 

Anyone knows why it is necessary to do this? Any side-affects if I ``correct'' (to keep original file permission) this?

zombie@zombie-linux:~/Temp$ ls -la err
-rwxr--r-- 1 zombie zombie 10036 2011-11-04 13:36 err
zombie@zombie-linux:~/Temp$ adb push ./err /system/bin
162 KB/s (10036 bytes in 0.060s)
zombie@zombie-linux:~/Temp$ adb shell ls /system/bin/err -la
-rwxrwxrwx root root 10036 2011-11-04 18:36 err

zombie@zombie-linux:~/Temp$ chmod 644 err
zombie@zombie-linux:~/Temp$ adb push ./err /system/bin 
213 KB/s (10036 bytes in 0.045s)
zombie@zombie-linux:~/Temp$ adb shell ls /system/bin/err -la
-rw-rw-rw- root root 10036 2011-11-04 18:36 err
posted May 17, 2013 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

0 votes

Ill take a very wild guess: this is probably done to match the way system.img is created by the build, so that files that get pushed or synced dont end up with different permissions.
As an example, if you sync an apk, it needs to be world-readable on the Android side, even if its not world-readable on your host machine.

answer May 17, 2013 by anonymous
0 votes

This does not explain yet IMO. If that is just to get read permission for all the world, it is over-kill. adb can simply add the bits, not copy all bits from owner. The source code does not explain why they decided to do so though comments indicate the code author knows, and intentionally does that.

zombie@zombie-linux:~/main-jb/out/debug/target/product/cardhu$ ls -la *.img
-rw-r--r-- 1 zombie zombie 5658624 2013-05-15 14:42 boot.img
-rw-r--r-- 1 zombie zombie 187537 2013-05-15 14:42 ramdisk.img
-rw-r--r-- 1 zombie zombie 697530 2013-05-15 14:42 ramdisk-recovery.img
-rw-r--r-- 1 zombie zombie 6168576 2013-05-15 14:42 recovery.img
-rw-r--r-- 1 zombie zombie 285208972 2013-05-15 14:54 system.img
-rw-r--r-- 1 zombie zombie 9 2013-05-15 14:07 tos.img
-rw-r--r-- 1 zombie zombie 6451396 2013-05-15 14:44 userdata.img
answer May 17, 2013 by anonymous
Similar Questions
+3 votes

how can install apk through ADB in android device.

+6 votes

In android generally when an app is installed, the PackageInstallerActivity and PackageManagerService make sure to assign the supplementary gid's to the app. This determines the level of access when an app is invoked everytime.

I just wanted to confirm if any verification process takes place in the runtime from packagemanager or any other service for that matter.

The app is granted the corresponding access from the gid's that should get it running technically and Packagemanager will only come into picture incase of updating the app.

Is my understanding correct?

+1 vote

I've a problem of not having enough permissions for setting a “persist.xxxxx” property from one of the applications. This application shares the User-id of the phone so I tried to hack in property_service.c and add an entry:

{“persist.”, AID_RADIO, 0} 
in property_perms structure. 

After this I was able to set the property but without this I get a “permission denied” error "> init: sys_prop: permission denied uid:1001 name:persist.xxxxx". Any clue...