Unit 14 Advanced topic in users, groups and permissions
Keyword: user, group, security
爆发一下，今天多发些。
本小节会深入介绍文件系统的关于用户权限方面的知识点，这一节是整个Linux的重要基础知识之一。
14.1 User and group management
先简单说一下Linux关于用户和组的文件和命令。
存储帐户信息的文件主要有四个
/etc/passwd
存储帐户名称、uid及shell等
/etc/shadow
储存加密的帐户密码
/etc/group
储存用户组的信息及成员的信息
/etc/gshadow
储存加密的用户组密码
管理用户主要有以下几个命令
*useradd*
新增用户
*usermod*
修改用户的属性。如：shell、密码、uid、用户组、过期时间等等
*userdel*
删除用户
*w*
显示现时登陆的用户及登陆时间，信息相比who要少一些
*last*
显示历史登陆信息及重启信息，其使用的是/var/log/wtmp的信息
*lastb*
只显示失败的登陆信息
*lastlog*
显示用户最后一次的登陆信息
14.2 Advanced Permission
这里会阐述一个比较重要的基础知识点——umask。
umask
在系统启动的时候，一般会在用户初始化的时候会设置umask（.bashrc），这里会再详细解释一下其功用。
一般的文件权限都对应三个种用户u（文件所属用户，简称“用户”）、g（文件所属组的用户，简称“组”）、o（其他用户，简称“其他”），每种用户也对应四种权限r（读、4）、w（写、2）、x（执行、1）、-（无权限、0）。具体到二进制分别对应9个bit。如果有一个文件权限为 用户：读、写、执行；组：读、写；其他：无，那对应的权限用数字表达是u:4+2+1=7，g:4+2=6，o:0，最后得出ugo=760。那干umask啥事呢？
因为用户创建文件时候也需要一个默认的权限的，umask就是与设置这个默认的权限有关。umask也一样为9bit，分别对应文件权限一样的位置。当然umask并不直接设置默认权限，而是设置默认权限的最大权限，那他是怎样做到的呢？
简单点说就是将文件的默认权限的9个bit与umask的9个bit做“与”的逻辑操作。如创建一般系统文件默认的权限是666，那就是说所有的用户都可以删除新创建的文件，这样就比较危险了。所以在使用$umask=002以后，文件创建时默认权限为666&&002=664，这样其他用户就只有r了。那为何不直接设置一个默认权限而要这样一个折中的方案呢？
据我的理解，由于不同用户、不同的文件类型在不同的环境需要的默认创建权限都不一样，有些可以松一些，有些要很严格，如果划一会造成可能某些文件的安全性过高，而有些又可能会过低。现在由于所有默认的权限都要与umask做一次“与”操作，这样无论默认权限是什么，其最宽松的范围已经被划定了，这样在不同的环境中通过简单设置一下umask就可以做到很复杂的效果，既保证了安全性，也保持了弹性（flexible），又一个比Windows优胜之处！
*umask*
改变uamsk
Linux的其实也并非完美，其组功能我觉得算是其中的表现之一。Windows的组功能虽然也不算很好，但相比之下确有特点。由于以前的组功能太弱，以致必须发明一些新技术来补救，以下就是其中一些。
suid bit
这个并非对应组功能的，他是为了弥补另一个缺陷的（终于要开始说Linux的坏话了）。有些程序（如用/usr/bin/passwd改自己的密码）需要写系统配置文件（/etc/passwd or /etc/shadow）。但由于系统安全性的原因——谁运行进程就使用谁的uid，安全性也要切合谁的uid，其他用户（o）只能读取而不能写这些配置文件（这就造成了其他用户无法修改自己的密码）。万般无奈之下，就对可执行文件（一般文件和目录不生效）发明了suid。
其作用是如果文件是一个可执行的文件设定了suid=1的时候，当除owner以外的用户运行这个程序的时候，会以owner的uid来运行，当然也会用owner的安全性来执行。这样的好处就可以解决上边的问题，但对于安全性也是一种挑战。所以对于脚本这种可执行文件suid也不生效，而且对于一般用户开发的程序是不建议使用的。
大家可以试试在一个console里面用root以外的用户运行$passwd，在另一个console里面运行$ps aux | grep passwd，你会看见passwd是root在运行。
如果设置了suid bit会在用户权限部分的执行位（x）会变成s，如果用户权限部分原来已经有执行的权限，就会变成S（大写）。
增加suid bit可以使用以下的命令$chmod u+s exefile
sgid bit
一般的共享目录都希望做到一种效果，就是同组创建的文件同组用户可以互相访问（rwx）。但由于Linux有个优先组（primary group）的问题，谁人创建的文件，文件的组属性就是谁人的优先组。而通常一个用户都会属于几个组，而且工作中都会在不同的组的共享文件夹之间切换，这就造成尽管用户与目录的gid相同，但仍会生成不同gid的文件。虽然有newgrp指令可以解决一些问题，但对于用户来说也很麻烦，这就需要另一个解决方案了。
Linux系统针对目录设置了一个sgid bit的东东（一般文件也有，但不生效），当sgid=1的时候其可以令目录下新建的文件的gid与目录的gid相同（但相关权限仍然是用户的默认权限，并非从从目录的组属性继承下来的权限，这与Windows很大不同）。
如果设置了sgid bit会在组权限部分的执行位（x）会变成s，如果组权限部分原来已经有执行的权限，就会变成S（大写）。
增加sgid bit可以使用以下的命令$chmod g+s directory
stricky bit
说到Windows，他的文件目录安全管理也不算完美。以前老有些同组的用户把目录下面别的用户文件删掉（其实是鼠标拖曳到别的文件夹，老让我查是谁删的，还要去做文件恢复，恨得我牙痒痒）。因为同组用户都需要有写权限修改文件，所以不能将同组改为只读。现在Linux就终于有解决方案了——stricky bit。
当文件夹的stricky bit=1的时候只有owner和root才可以删除文件，这样的安全性就大大提高了。
如果设置了stricky bit会在其他用户权限部分的执行位（x）会变成t，如果其他用户权限部分原来已经有执行的权限，就会变成T（大写）。
增加stricky bit可以使用以下的命令$chmod o+t file
关于目录有一点要切记的是，当前目录的权限（permission）设置只会在当前目录生效，子目录对于父目录的一般设置都不会继承的。Linux的机制是采用文件的权限默认值加umask生成新文件的默认权限，这与Windows采取继承上一级目录权限的机制有很大的不同。
阅读(399) | 评论(0) | 转发(0) |
