setuid setgid root 权限提升 android root su
http://hi.baidu.com/3444542/item/accca93819c7555880f1a764
关于chmod权限设置的讲解
来自: http://topic.csdn.net/t/20050707/10/4128418.html以前每次看鸟哥的书这一切都跳过，这回铁匠GOOGLE收集到的一看就明白，特此收藏
chmod xxxx四位数是标准写法，我们通常只写3位chmod xxx，系统会自己把你的xxx作为0xxx处理。
第一位是这样的：
suid的代表数字是4，比如4755的结果是-rwsr-xr-x
sgid的代表数字是2，比如6755的结果是-rwsr-sr-x
sticky位代表数字是1，比如7755的结果是-rwsr-sr-t
suid: 设置使文件在执行阶段具有文件所有者的权限. 典型的文件是 /usr/bin/passwd. 如果一般用户执行该文件, 则在执行过程中, 该文件可以获得root权限, 从而可以更改用户的密码（/etc/passwd）.
-r-s--x--x 1 root root /usr/bin/passwd
-rw-r--r-- 1 root root /etc/passwd
sgid: 与suid类似。文件运行时，运行者将具有所属组的特权。
sticky: 主要应用于目录，表示这个目录中建立的文件，只能由建立该文件的用户删除。
比如/tmp
drwxrwxrwt 16 root root tmp
所有用户都拥有该目录的rwx权限，设置sticky后显示为rwt。
如果一个用户在该目录中创建了一个临时文件，很可能被其它用户删除，设置sticky就可以避免这种情况。
按你的要求，你需要改变你的脚本的所有者为root。
但是：这样是非常危险的，因为这相当于所有人都具有root权限，如果有人恶意修改后再执行!!!!!!!
建议用 4755 -rwsr-xr-x
http://www.360doc.com/content/12/0602/16/10112111_215437761.shtml
1什么是SetUID
我们知道，在linux的命令行下执行“ps -aux”命令时，就会列出当前系统中
的所有进程，在其中可以看到每个进程都和用户的真实id关联，实际上，Linux中
的每个进程还跟一个称为有效用户id（set User id）紧密关联。/前者用于表示该
进程由那个用户控制，后者用于为新建立的文件分配所有权，检查文件访问许可等
操作，同时有效用户为该文件的所有者。/linux系统内核允许一个进程以调用一个
SetUID程序（或显示执行SetUID系统调用）的方式，来改变其自身的有效用户id。
2如何配置SetUID权限
在linux中，不管是Root用户还是普通用户，都可以使用“Password”命令来更
改自身的密码。但是，Linux中的密码通常是保存在“/etc/paswd”和“/etc/shadow”
文件中，这两个文件对系统安全至关重要，因此只有Root用户才能对其执行读写操
作。以管理员的身份登陆系统，在Linxu提示符下执行“ls /etc/passwd /etc
/shadow”命令，在返回信息中可以看到普通用户对上述这两个文件并没有写权限，
因此从文件属性的角度看，普通用户在更改自身密码时，是无法将密码信息写入到
上述文件中的，哪么用户是怎样成功的更改密码的呢？实际上，问题的关键不在于
密码文件本身，而在于密码更改命令“passwd”。在提示符下执行命令“ls
/usr/bin/passwd”,在返回信息中的文件所有者执行权限位上显示“S”字样，表示
“passwd”命令具有SetUID权限，其所有者为Root，这样普通用户在执行“passwd”命
令时，实际上以有效用户root的身份来执行的，并具有了相应的权限，从而将新的
密码写入到“/etc/passwd”和“/etc/shadow”文件中，当命令执行完毕，该用户的身
份立即消失。如何设置SetUID权限呢？使用“chmod”命令即可为指定文件设置
SetUID权限，例如“chmod 4xxx filename”命令，取消SetUID权限的命令为
“chmod xxx filename”。类似的，执行“chmod 2xxx filename”命令可以设置
SetUID权限，使用“chmod xxx filename”命令即可取消SetGID权限，如果执行
“chmod 6xxx filename”命令，即可同时为指定文件设置SetUID和SetGID，执行命
令“chmod 0xxx filename”，即可同时取消指定文件的SetUID和SetGID权限。例如
以Root用户登陆系统，执行“chmod 0511 /usr/bin/passwd”命令，就可以取消
“passwd”命令的SetUID权限，这样普通用户就无法修改自己的密码了。
3SetUID权限的安全性
使用SetUID可以灵活的调整所有文件所有者权限，但是也为系统的安全性带
来了隐患。如果Root用户为指定的程序文件配置过大的SetUID权限，那么就会为黑
客或者非法用户打开了侵入系统的大门。例如在Linux中可以使用“vi”命令来编辑
文件，但是，对于普通用户而言，当其试图使用命令“vi /etc/shadow”来修改密码
文件时，系统就会弹出“/etc/shadow : Permission Denied”的警告提示，从而禁
止其对密码文件的非法修改。但是，如果在Root用户环境中执行“which vi”命令，
就可以看到“vi”命令实际上是“vim”命令的别名，其真实路径为“/usr/bin/vim”，
这样执行命令"chmod 6755 /usr/bin/vim",就可以将“vi”命令的所有者更改为
Root，这样在普通的用户环境中，就可以使用“vi”命令来编辑任何文件（例如
“/etc/shadow”）,这样，即使是普通用户也可以将密码文件清空，从而实现无密码
登陆Linux，给系统的安全带来的威胁不言而喻。因此，对可能给系统安全带来危
害的程序来说，应该尽量不要随意为其配置SetUID权限。
4 如何禁用SetUID权限
对于存放在敏感数据的分区而言，有时可能希望禁用SetUID权限设置功能。
例如对"/home" 分区禁用SetUID权限，可以找到修改其配置文件“/etc/fstab”, 执
行命令“vi /rtc/fstab”,可以看到“LABEL=/home /home ext3 defaults 1 2”等数
据，我们只需在上述“default”关键字的后面添加“nosuid” 关键字即可，例如使用
“vi”命令将其修改为“LANBEL=/home /home ext3 default , nosuid 1 2”,之后执
行命令“mountoremount /home”,这样即使对“/home”分区上的任何可执行文件配置
了SetUID权限，也是无效的。这样就在很大程度上保护了系统的安全。
http://www.chinaunix.net/old_jh/24/381150.html
要了解 suid/sgid, 必需先了解 process 及 permission.
我們需知道: 每個 process 都有其 effective uid/gid , 以決定其在傳統 unix filesystem 中獲得的實際 permission .
再, process 是由 binary 產生的, 而 binary 是從 shell / shell script 載入執行.
在正常的情況下, process 的 effective uid/gid 是從 parent 繼承, 或簡單說是與 shell 的 uid/gid 一樣.
shell 的 uid/gid 則是跟據 /etc/passwd 的第 3 與 第 4 欄位決定.
當我們有了以上的概念之後, 再來看 suid 對 effective uid/gid 的影響:
若 binary file 帶有 suid/sgid 的時候,
其 effective id 就不是從 parent 那邊繼承, 而是以 binary file 本身的 user/group 為準.
舉例而言, 若一個 prog1 的 user/group 都是 root , 但沒設 suid/sgid ,
那當一個 uid(500)/gid(500) 的 parent process 執行這個 prog1 的話,
那 effective uid/gid 就是 500 ...
但若 prog1 設了 suid/sgid 後, 那其 effective uid/gid 就是 root !
一旦這個 process effective 是 root 的話, 那它對 file system 的 permission 就如脫繮野馬般任意奔騰而不受限制了.
因此我才在前面提到木馬程式與病毒的例子...
試想一下: 若病毒的 user/group 被設為 root, 然後被一般 user 執行時,
suid/sgid 的有與無將導致甚麼不同結果?
好了, 由於 suid/sgid 在系統上有其存在的必要性(舉 /usr/bin/passwd 與 /etc/shadow 為例),
但同時又有極大的殺傷力, 在應用上要異常小心!
因此, bash shell script 在先天上不支援 suid/sgid .
perl 亦如此, 除非額外再安裝 suid-perl ....
碰到安全問題, 每一個系統使用者(尤其是管理員)都應小心慎重對待.
或以一句話來總結的話, 就是:
--- 勿以善小而不為, 勿以惡小而為之!
http://bbs.chinaunix.net/thread-1686806-1-1.html
1. ls -l显示出来的这个叫做suid位，就是如rwS-r-x-r-x这样中的S（故意大写了）。
当S出现在所有用户的执行位时，其他凡是对此文件有执行权的用户执行时权限自动提升为所有者的权限。
LZ的问题是SH不具备suid位的权限，但为什么不能让sh具备suid位权限呢？
很显然，/bin/sh的所属用户是root，当其具备suid位权限的时候，任何能执行/bin/sh的用户都是root。
另：suid位改变的是执行用户的euid，这可以通过简单的程序来看出。
2. 系统api里有setuid(2)以及setgid(2)以及seteuid(2)等系统调用。作用同样是改变程序执行时的所属权限，但这些跟suid位有什么区别呢？
简要说明一下两者的大部分用途：
* suid位大多用于提升权限；
* setuid(2)等调用大多用于降低权限；
setuid(2)这些调用是只有root用户才能执行成功的，普通用户执行包含了setuid(2)的程序时，是不会成功的。原因很简单：
如果一个普通用户都能随便更改自己的执行权限到其它用户，那么系统中出现一些问题也不知道是谁干的。
实例程序分析：su工具：
su工具具备了suid位，程序代码中还包括了setuid(2)等调用，何故？
su工具用途是用来切换用户权限的，而且可以在任何用户之间切换：
纯粹的suid位是解决不了多用户权限切换的，总不至于频繁更改程序的所属用户吧。
而api中的setuid(2)能解决多用户切换问题，可是普通用户没有权限执行啊......
两者结合呢？让su用户有suid位的权限，再通过setuid(2)切换用户权限，如此：
先用户执行su的时候具备root权限，再接着有权执行setuid(2)切换到自己想要的用户的权限......
如果看su的源码，会发现其中有对文件系统mount时时候挂载了suid特性的检测，由此你会了解到setuid特性可以在mount的-o中关闭掉。
具体可以参考man 2 setuid，man mount等等。