码迷,mamicode.com
首页 > 其他好文 > 详细

Liunx UID and GID

时间:2015-09-19 07:26:11      阅读:180      评论:0      收藏:0      [点我收藏+]

标签:

一个文件都有一个所有者, 表示该文件是谁创建的. 同时, 该文件还有一个组编号, 表示该文件所属的组, 一般为文件所有者所属的组.
  如果是一个可执行文件, 那么在执行时, 一般该文件只拥有调用该文件的用户具有的权限. 而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

Liunx UID and GID

标签:

原文地址:http://www.cnblogs.com/Nyan-Workflow-FC/p/4820854.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!