一个文件都有一个所有者, 表示该文件是谁创建的. 同时, 该文件还有一个组编号, 表示该文件所属的组, 一般为文件所有者所属的组.
　　如果是一个可执行文件, 那么在执行时, 一般该文件只拥有调用该文件的用户具有的权限. 而setuid, setgid 可以来改变这种设置.
　　setuid: 设置使文件在执行阶段具有文件所有者的权限. 典型的文件是 /usr/bin/passwd. 如果一般用户执行该文件, 则在执行过程中, 该文件可以获得root权限, 从而可以更改用户的密码.
　　setgid: 该权限只对目录有效. 目录被设置该位后, 任何用户在此目录下创建的文件都具有和该目录所属的组相同的组.
　 　sticky bit: 该位可以理解为防删除位. 一个文件是否可以被某用户删除, 主要取决于该文件所属的组是否对该用户具有写权限. 如果没有写权限, 则这个目录下的所有文件都不能被删除, 同时也不能添加新的文件. 如果希望用户能够添加文件但同时不能删除文件, 则可以对文件使用sticky bit位. 设置该位后, 就算用户对目录具有写权限, 也不能删除该文件.
　　下面说一下如何操作这些标志:
　　操作这些标志与操作文件权限的命令是一样的, 都是 chmod. 有两种方法来操作,
　　1) chmod u+s temp -- 为temp文件加上setuid标志. (setuid 只对文件有效)
　　chmod g+s tempdir -- 为tempdir目录加上setgid标志 (setgid 只对目录有效)
　　chmod o+t temp -- 为temp文件加上sticky标志 (sticky只对文件有效)
　　2) 采用八进制方式. 对一般文件通过三组八进制数字来置标志, 如 666, 777, 644等. 如果设置这些特殊标志, 则在这组数字之外外加一组八进制数字. 如 4666, 2777等. 这一组八进制数字三位的意义如下:
　　abc
　　a - setuid位, 如果该位为1, 则表示设置setuid
　　b - setgid位, 如果该位为1, 则表示设置setgid
　　c - sticky位, 如果该位为1, 则表示设置sticky
　　
　　设置完这些标志后, 可以用 ls -l 来查看. 如果有这些标志, 则会在原来的执行标志位置上显示. 如
　　rwsrw-r-- 表示有setuid标志
　　rwxrwsrw- 表示有setgid标志
　　rwxrw-rwt 表示有sticky标志
　　那么原来的执行标志x到哪里去了呢? 系统是这样规定的, 如果本来在该位上有x, 则这些特殊标志显示为小写字母 (s, s, t). 否则, 显示为大写字母 (S, S, T)

　　要删除一个文件，你不一定要有这个文件的写权限，但你一定要有这个文件的上级目录的写权限。也就是说，你即使没有一个文件的写权限，但你有这个文件的上级目录的写权限，你也可以把这个文件给删除，而如果没有一个目录的写权限，也就不能在这个目录下创建文件。
　　如何才能使一个目录既可以让任何用户写入文件，又不让用户删除这个目录下他人的文件，sticky就是能起到这个作用。stciky一般只用在目录上，用在文件上起不到什么作用。
　 　在一个目录上设了sticky位后，（如/tmp，权限为1777)所有的用户都可以在这个目录下创建文件，但只能删除自己创建的文件，这就对所有用户 能写的目录下的用户文件启到了保护的作用。（我当时/tmp没有设sticky位，而在文件上设了，这也就是为什么我为什么设了sticky位，还能删除 自己创建的文件的原因了）
　　
　　--------------------------------------------------------------------------------
　　
　　suid/sgid
　　
　　要了解 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 ....
　　
　　
　　--------------------------------------------------------------------------------
　　
　　
　　 uid gid euid egid
　　root 0 0
　　
　　test 500 500
　　
　　tset.shell 500 500 500 500 登陆后的shell
　　
　　test.passwd.process 500 500 0 500 fork后
　　 (-r-s--x--x)
　　
　　test用户fork binary文件passwd后，test属于others，拥有该文件的x权利，因为设置了suid，所以fork出来的进程(passwd.process)的euid=
　　
　　文件(passwd)的owner的uid 也就是
　　
　　passwd.process.euid=passwd.owner.uid=0
　　
　　euid和guid是用来进程passwd.process发生读，写，执行文件shadow的时候确认访问权限的.
　　
　　
　　-r-------- 1 root root 855 Sep 4 10:58 /etc/shadow ( passwd.uid=0 有r权限 ）
　　
　　文件shadow.owner.uid为0拥有r权限 因为passwd.process.euid=shadow.ower.uid=0所以由test用户产生的进程passwd.process拥有文件
　　
　　shadow的r权限
　　
　　-r-s--x--x 1 root root 19336 Sep 7 2004 /usr/bin/passwd