Linux文件权限隐藏的细节深入分析

简介: linux是一个安全的操作系统,她是以文件为基础而设计的,其文件权限是比较复杂的,可以用stat命令以及lsattr命令来显示某个文件的详细信息:    $ stat file1  ...

linux是一个安全的操作系统,她是以文件为基础而设计的,其文件权限是比较复杂的,可以用stat命令以及lsattr命令来显示某个文件的详细信息:

 

  $ stat file1
  file: `file1'
  size: 11904 blocks: 24 io block: 4096 regular file
  device: 301h/769d inode: 355982 links: 1 
  access: (0755/-rwxr-xr-x) uid: ( 503/ jack) gid: ( 503/ general)
  access: 2003-10-19 09:14:12.000000000 +0800
  modify: 2003-10-14 20:41:21.000000000 +0800
  change: 2003-10-19 18:56:25.000000000 +0800
  
  $ lsattr file
  ----i--a----- file

可以看到,文件权限的含义是比较广的,先来看-rwxr-xr-x,第一位是文件的类型,它定义了用户只能某种方式来操作文件,后面九位是文件的存取控制信息,linux的文件许可机制将用户分为三类:文件属主u(user)、文件属组g(group)和其它用户o(other)。三类不同的用户可以对文件拥有三种不同级别的权限:读r(read)、写w(write)和运行x(execute)。于是形成了九位的权限信息,分为三组,分别对应u,g, o。除此之外,用户还可以设置setuid与setgid位来改变程序的执行身份。用lsattr命令则可以看到文件的属性,控制位包括 asacddiijsttu,这些也是能控制文件的存取的。

由于篇幅有限,不可能就这些一一进行分析,本文着力分析文件权限中w(write)的真正含义,挖出其背后隐藏的细节,力图使读者能正确用好这个关键的权限位,不至于在系统管理中出现差漏。

为了能更直观的说明问题,本文采用实验操作的方式,一步一步的进行分析。为了简化操作,我们用o(other)这组权限来做实验。实验中用到的权限位均属于o(other), 进行操作的用户均非root用户,属于o(other)。

在实验之前,必须澄清一个概念,目录也是一种文件,它主要包括了两方面的信息,该目录下文件的文件名称与文件inode编号,它们之间有一一对应的关系。不过目录文件比较特殊,不能用常规的方法进行读写,必须用系统的专用命令来操作。命令ls其实是对目录文件进行读操作,命令mv,rm则是对目录文件进行写操作。

好了,该说说w(write)的真正含义了,一句话,linux文件权限中的w是对该文件的*内容*进行限定。下面的实验可以验证。

实验1, 目录文件: /test(rwx), 普通文件: /test/file(r--). 当前目录:/test

linux是一个安全的操作系统,她是以文件为基础而设计的,其文件权限是比较复杂的,可以用stat命令以及lsattr命令来显示某个文件的详细信息:

 

  
  $ echo "abc" >file
  bash: file: permission denied

试图对file的内容进行改写, 但file的权限是只读,很显然,操作失败。

linux是一个安全的操作系统,她是以文件为基础而设计的,其文件权限是比较复杂的,可以用stat命令以及lsattr命令来显示某个文件的详细信息: 

 

 
  $ cat file
  hello world!

没有问题, 可以读出file的内容。

linux是一个安全的操作系统,她是以文件为基础而设计的,其文件权限是比较复杂的,可以用stat命令以及lsattr命令来显示某个文件的详细信息: 

 

 
  $ mv file file2
  $ ls
  file2

  

这是怎么回事呢, file的权限明明是只读啊, 请注意, 前面提到了, 文件中的rw权限只是针对当前文件的内容进行限定, 文件名不属于当前文件的内容, 它是保存在上一级的目录文件的内容中。而mv命令表面上是针对file的,其实是对/test的内容进行改写,再看看/test的权限, 是可写的(rwx)。许多用户为了保护文件,将其权限设成只读就不管了,这是非常危险的,诚然,可以达到保护文件内容的目的(其实也未必,补充内容中有论述),但你却不能保证文件是否会被更名或被删除,保险的方法是将文件父目录的权限也设为只读。当然,也有其他的方法,比如用chattr +i命令或将文件系统用ro方式挂载等等,但这些不在本文论述范围。

linux是一个安全的操作系统,她是以文件为基础而设计的,其文件权限是比较复杂的,可以用stat命令以及lsattr命令来显示某个文件的详细信息: 

 

 
  $ rm -f file2
  $ ls
  $
  

同样的原因, 我们可以删除file2, 与上一次操作不同的是,我们不是改写/test的一条纪录,而是在删除/test的一条纪录。

实验2, 目录文件: /test(r-x), 普通文件: /test/file(rw-), 当前目录:/test

linux是一个安全的操作系统,她是以文件为基础而设计的,其文件权限是比较复杂的,可以用stat命令以及lsattr命令来显示某个文件的详细信息:

 

  
  $ echo "abc" >file
  $ cat file
  abc
  

/test的权限虽然是只读,但我们改写的是file的内容, 它的权限是可写,当然没有问题。

linux是一个安全的操作系统,她是以文件为基础而设计的,其文件权限是比较复杂的,可以用stat命令以及lsattr命令来显示某个文件的详细信息: 

 

 
  $ mv file file2
  mv: cannot move 'file' to 'file2': permission denied
  $ rm -f file
  rm: cannot remove 'file': permission denied
  

我们已经知道, 这两条指令其实与file的权限无关, 而是在改写/test的内容, 当然操作失败。通过前面几个操作,我们应该要分清楚指令真正的操作对象是谁,这样才能对文件权限作出正确的设定。

实验3, 目录文件: /test(rwx), 普通文件: /test/file(r--), 目录文件: /test/dir(r-x), 普通文件: /test/dir/file(rw-), 当前目录:/test

linux是一个安全的操作系统,她是以文件为基础而设计的,其文件权限是比较复杂的,可以用stat命令以及lsattr命令来显示某个文件的详细信息:

 

  
  $ mv file file2
  $ mv dir dir2
  $ ls
  dir2 file2
  

很顺利, 因为/test/file与/test/dir的父目录/test的权限给的太宽松了,是rwx。

linux是一个安全的操作系统,她是以文件为基础而设计的,其文件权限是比较复杂的,可以用stat命令以及lsattr命令来显示某个文件的详细信息: 

 

 

 
  $ rm -f file2
  $ rm -rf dir2
  rm: cannot remove 'dir2/file': permission denied
  $ ls -r
  .:
  dir2
  
  ./dir2:
  file

到这里, 我们已经丝毫不奇怪普通文件/test/file2被删除, 但具有同等地位的目录文件/test/dir2却安然无恙。当执行rm -rf dir2时, 由于存在普通文件/test/dir2/file, 系统便尝试先删除它, 也就相当于修改目录文件/test/dir2的内容, 但它的权限是只读, 不能进行修改,也就相当于不能删除/test/dir2/file, 又由于/test/dir2与/test/dir2/file有依存关系, /test/dir2也就自然会被保留下来。

回顾上一个操作(mv dir dir2),为什么目录文件/test/dir却可以被更名呢?由于更名操作并不涉及到自身的内容被修改,修改的只是父目录的内容,而进行删除操作时,父目录的内容固然要被修改,但也同时也要修改自身的内容(因为要删除该目录下的文件),这就不被允许了。如果/test/dir2的权限是可写, 或者目录下没有子文件, 那么它的下场就和/test/file2一样, 被删除。

通过前面的几个操作,可以看到,文件有这么几个关键状态:被读、被改写、被改名、被删除、被执行。然而系统只区分三种权限,即读、写、执行(rwx)。那么改名与删除这两个操作是否系统就置之不理了呢?不是的,系统将这两个操作归入被操作文件的上一级目录来管理。那么又是以何种方式来管理的呢?答案是目录将其下的所有文件看作是它的内容。这样,当用户更名或删除某个文件时,执行的是对上一级目录的写操作,属于rwx三种权限之一的w操作,并没有逃出系统的管理范围。

我们的大脑总是活跃的, 能想象出各种各样的事情, 能把许多简单的东西组合成很复杂东西, 上面几个实验不正是这样吗, 象这样的实验我们还可以设计出许多, 但做的越多, 脑子似乎越乱(我已经有一点了), 你能记的住这么多吗? ok, 我们也许能将它想的简单一些, 只需注意两个方面, 一是要清楚目录的内容是什么;二是要明白文件权限中的w(write)的真正含义。仔细想想, 不是吗?

补充:

在实验1中, 如果用vim对file进行编辑, 并且强制保存(w!), 是可以成功的。这并不是说vim就可以绕开系统的安全机制,而是vim耍了一个小小的把戏,它是先删除这个文件,而后又生成一个同名的新文件。但有一个情况例外,就是当这个文件有另外一个硬链接文件存在时,vim会拒绝强制保存,仔细想想,当进行删除操作后,文件还存在,并没有被真正删除.

目录
相关文章
|
22天前
|
存储 安全 Linux
|
4月前
|
Linux 调度
Linux 内核源代码情景分析(一)(下)
Linux 内核源代码情景分析(一)
64 1
|
3月前
|
安全 Linux 数据安全/隐私保护
探索Linux操作系统的文件权限管理
【9月更文挑战第29天】在数字世界中,文件权限管理如同保护我们隐私的锁。本文将带你了解如何在Linux系统中设置和管理文件权限,确保你的数据安全。我们将一起学习如何通过命令行工具来控制文件访问,就像学习一门新语言一样有趣。准备好了吗?让我们一起开启这场技术之旅!
|
2月前
|
Linux
linux/mac 下查看、修改文件权限的命令
这篇文章介绍了在Linux和Mac操作系统下如何查看和修改文件及文件夹的权限。
71 0
|
4月前
|
存储 IDE Unix
Linux 内核源代码情景分析(四)(上)
Linux 内核源代码情景分析(四)
34 1
Linux 内核源代码情景分析(四)(上)
|
4月前
|
存储 Linux 块存储
Linux 内核源代码情景分析(三)(下)
Linux 内核源代码情景分析(三)
38 4
|
4月前
|
Linux C语言
深度探索Linux操作系统 —— 编译过程分析
深度探索Linux操作系统 —— 编译过程分析
28 2
|
4月前
|
存储 Unix Linux
Linux 内核源代码情景分析(四)(下)
Linux 内核源代码情景分析(四)
25 2
|
4月前
|
Linux 人机交互 调度
Linux 内核源代码情景分析(二)(下)
Linux 内核源代码情景分析(二)
40 2
|
4月前
|
存储 Unix Linux
Linux 内核源代码情景分析(二)(上)
Linux 内核源代码情景分析(二)
34 2
下一篇
无影云桌面