另一个问题：假如我想更换该文件的拥有者和所属组应该咋办？
这个时候我们就可以使用chown 和 chgrp 指令了：
chown:
功能：修改文件的拥有者
格式：chown [参数] 用户名 文件名
chgrp:
功能：修改文件或目录的所属组
格式：chgrp [参数] 用户组名 文件名
常用选项：-R 递归修改文件或目录的所属组
我们可以来试试：
[root@VM-8-12-centos lesson6]# ll total 8 drwxr-xr-x 2 root root 4096 Dec 2 21:31 mydir -rwxrwxrwx 1 root root 0 Dec 2 21:30 mytxt.txt -rwxr--rwx 1 root root 110 Dec 2 17:05 text.c -rw-r--r-- 1 root root 0 Dec 2 21:31 text.cpp [root@VM-8-12-centos lesson6]# chown grm text.c [root@VM-8-12-centos lesson6]# ll total 8 drwxr-xr-x 2 root root 4096 Dec 2 21:31 mydir -rwxrwxrwx 1 root root 0 Dec 2 21:30 mytxt.txt -rwxr--rwx 1 grm root 110 Dec 2 17:05 text.c -rw-r--r-- 1 root root 0 Dec 2 21:31 text.cpp [root@VM-8-12-centos lesson6]#
不难发现该文件的所属组已经被修改成功。
修改所属组也是同样的方法，只是用的命令变为：chgrp
4 文件掩码
通过上面我们知道：
超级用户建立一个普通文件（不包括可执行文件）的默认权限是 ：rw- r-- r-- （644）
而建立一个目录的默认权限是：rwx r-x r-x （755）
那么为什么是这样子的呢？
系统新建文件夹起始权限 =0666 ，新建目录起始权限 =0777
但实际上你所创建的文件和目录，看到的权限往往不是上面这个值。原因就是创建文件或目录的时候还要受到umask 的影响。
而umask就是文件掩码。那最终权限（也就是系统的默认权限）与起始权限和文件掩码有啥关系呢？
最终权限=mask & ~umask （mask是文件起始权限）
umask
功能：
查看或修改文件掩码
格式： umask 权限值
说明 ：将现有的存取权限减去权限掩码后，即可产生建立文件时预设权限。超级用户默认掩码值为 0022 ，普通用户默认为 0002 。
在超级用户下建立 文件： 110 110 110 （666） 111 101 101 & ------------ 110 100 100 （644） 目录： 111 111 111 （777） 111 101 101 & ------------ 111 101 101 （755）
假如我们想修改系统默认的文件掩码呢？
可以使用命令：
umask XXX
我们不妨跳转到普通用户下来使用一下：
[grm@VM-8-12-centos ~]$ umask 012 [grm@VM-8-12-centos ~]$ touch tmp.txt [grm@VM-8-12-centos ~]$ mkdir -p dir [grm@VM-8-12-centos ~]$ ll total 4 drwxrw-r-x 2 grm grm 4096 Dec 18 13:24 dir -rw-rw-r-- 1 grm grm 0 Dec 2 22:30 grmfile -rw-rw-r-- 1 grm grm 0 Dec 18 13:23 tmp.txt
通过计算我们也能很快速的得到上面的结果。
5 目录的权限
- 可执行权限: 如果目录没有可执行权限, 则无法cd到目录中。
- 可读权限: 如果目录没有可读权限, 则无法用ls等命令查看目录中的文件内容。
- 可写权限: 如果目录没有可写权限, 则无法在目录中创建文件, 也无法在目录中删除文件.
其中比较容易出错的就是这个可执行权限了，进入一个目录首先需要的就是可执行权限，这点大家务必要牢记。
6 粘滞位
于是 , 问题来了 ~~
换句话来讲 , 就是只要用户具有目录的写权限 , 用户就可以删除目录中的文件 , 而不论这个用户是否有这个文件的写权限 .
这好像不太科学啊 , 我张三创建的一个文件 , 凭什么被你李四可以删掉 ? 我们用下面的过程印证一下：
我们用root用户创建一个共享目录（也就是其他用户都能够在里面建立文件的目录）将其权限都打开
然后其他用户以及root就可以往里面添加自己创建的文件了
但是问题来了，如果有一天grm把bxz惹毛了，bxz一气之下就把grm所创建的文件给干掉了，操作系统会同意这样做的吗？
我们发现好像还真的就删除了，这合理吗？还是一个bug?
所以我们就引出了粘滞位的概念：
当一个目录被设置为"粘滞位"(用chmod +t),则该目录下的文件只能由
一、超级管理员删除
二、该目录的所有者删除
三、该文件的所有者删除
我们为share目录增加一个粘滞位：
[root@VM-8-12-centos /]# chmod +t share [root@VM-8-12-centos /]# ll total 84 lrwxrwxrwx. 1 root root 7 Mar 7 2019 bin -> usr/bin dr-xr-xr-x. 5 root root 4096 Jul 28 11:37 boot drwxr-xr-x 4 root root 4096 Nov 4 17:34 cpp drwxr-xr-x 2 root root 4096 Nov 5 2019 data drwxr-xr-x 19 root root 3020 Sep 20 16:33 dev drwxr-xr-x. 95 root root 12288 Dec 2 22:04 etc drwxr-xr-x. 4 root root 4096 Dec 2 22:02 home lrwxrwxrwx. 1 root root 7 Mar 7 2019 lib -> usr/lib lrwxrwxrwx. 1 root root 9 Mar 7 2019 lib64 -> usr/lib64 drwxr-xr-x 3 root root 4096 Oct 3 20:34 linux drwx------. 2 root root 16384 Mar 7 2019 lost+found drwxr-xr-x. 2 root root 4096 Apr 11 2018 media drwxr-xr-x. 2 root root 4096 Apr 11 2018 mnt drwxr-xr-x. 4 root root 4096 Sep 20 15:18 opt dr-xr-xr-x 117 root root 0 Sep 20 16:33 proc dr-xr-x---. 8 root root 4096 Nov 23 21:26 root drwxr-xr-x 25 root root 880 Nov 15 20:05 run lrwxrwxrwx. 1 root root 8 Mar 7 2019 sbin -> usr/sbin drwxrwxrwt 2 root root 4096 Dec 18 13:58 share drwxr-xr-x. 2 root root 4096 Apr 11 2018 srv dr-xr-xr-x 13 root root 0 Sep 26 20:53 sys drwxrwxrwt. 8 root root 4096 Dec 18 12:56 tmp drwxr-xr-x. 14 root root 4096 Jan 8 2021 usr drwxr-xr-x. 20 root root 4096 Jan 8 2021 var
我们发现other的最后一位权限由x变成了t
接下来我们再删除来试试：
[bxz@VM-8-12-centos share]$ ll total 8 -rw-rw-r-- 1 bxz bxz 0 Dec 18 13:53 bxz1 -rw-rw-r-- 1 bxz bxz 0 Dec 18 13:53 bxz2 -rw-rw-r-- 1 grm grm 30 Dec 18 13:52 grm1 -rw-rw-r-- 1 bxz bxz 91 Dec 18 13:54 nxz1 -rw-r--r-- 1 root root 0 Dec 18 13:51 root1 -rw-r--r-- 1 root root 0 Dec 18 13:51 root2 [bxz@VM-8-12-centos share]$ rm -rf grm1 rm: cannot remove ‘grm1’: Operation not permitted
很明显该操作现在已经不被允许了。
7 权限的总结
目录的可执行权限是表示你可否在目录下执行命令。
如果目录没有-x权限，则无法对目录执行任何命令，甚至无法cd 进入目录, 即使目录仍然有-r 读权限（这个地方很容易犯错，认为有读权限就可以进入目录读取目录下的文件）
而如果目录具有-x权限，但没有-r权限，则用户可以执行命令，可以cd进入目录。但由于没有目录的读权限所以在目录下，即使可以执行ls命令，但仍然没有权限读出目录下的文档。
