拥有 w(写)权限的人是否也拥有 r(读)权限?

Fox*_*Fox 13 permissions

Linux 文件和目录权限有 3 个不同级别(读、写、执行)。在《Linux 黑客基础知识》第 50 页中,写权限定义如下:

w 写入权限。这允许用户查看编辑文件。

查看文件等同于读取文件的说法正确吗?

Rin*_*ind 23

查看确实是读取,但写入权限不包括读取权限,因此这句话对我来说看起来是错误的。

/proc/sys具有仅具有写入权限的伪文件。它用于单向信令;所以触发一个事件(即,如果文件中有一个值,则执行一个操作,否则不执行任何操作;并且处理此事件的进程会清除该值)。不要认为它在日常生活中真的有用途。

sudo find /proc/[^0-9]* /sys -perm /222 ! -perm /444
Run Code Online (Sandbox Code Playgroud)

找到它们(总共大约有 5600 个文件)。举个例子:

$ ls -ltr /sys/module/snd_rawmidi/uevent
--w------- 1 root root 4096 jul 26 15:34 /sys/module/snd_rawmidi/uevent
Run Code Online (Sandbox Code Playgroud)

写,不读。甚至所有者(root)也无法查看它:

rinzwind@schijfwereld:~$ sudo -i
root@schijfwereld:~# more /sys/module/snd_rawmidi/uevent
more: cannot open /sys/module/snd_rawmidi/uevent: Permission denied
Run Code Online (Sandbox Code Playgroud)

  • 正常生活中的典型用法是上传目录——人们可以向该目录写入新文件,但不能读取到目前为止已上传的内容。我们经常在多用户计算机上使用它来相互发送文件——只需将它们复制到“~otheruser/upload”即可。 (15认同)
  • @SimonRichter,这个术语是“投递箱”,反映了银行和邮局中常见的物理盒子的术语。任何人都可以放入东西,但只有主人才能取出东西。当然,随后 Dropbox 公司不得不出现并混淆了术语。 (6认同)
  • 1)当我有一个命名管道时,我可能希望它对生产者来说是只写的,这样如果它**确实**尝试读取它就会出错而不是永远挂起。2) 或各种程序写入的日志文件,但出于安全原因不应**具有读取权限。不断地... (2认同)

raj*_*raj 16

不,写权限不包括读权限,书上的说法不正确。这些权限是独立的。如果您只有写入权限,则可以覆盖该文件,但无法读取它。如果您只有读取权限,则可以读取该文件,但不能覆盖它。如果您拥有这两种权限,则可以同时执行这两项操作。

这是一个例子。我们有一个包含三个文件的目录,file1file2file3。每个文件都包含一行文本This is file n(其中n=1、2 或 3),权限如下:

raj@jarek-02:~/test$ ls -l
total 12
-rw--w--w- 1 root root 15 Jul 26 19:54 file1
-rw-r--r-- 1 root root 15 Jul 26 19:52 file2
-rw-rw-rw- 1 root root 15 Jul 26 19:53 file3
Run Code Online (Sandbox Code Playgroud)

这些文件属于root,并且root对所有三个文件都具有读写权限,但其他用户(我当前是用户raj,正如您从系统提示符中看到的那样)对第一个文件只有写访问权限,只有读访问权限到第二个以及对第三个的读/写访问。

正如我们所料,我无法读取第一个文件,但可以读取其他两个文件:

raj@jarek-02:~/test$ cat file1
cat: file1: Permission denied
raj@jarek-02:~/test$ cat file2
This is file 2
raj@jarek-02:~/test$ cat file3
This is file 3
Run Code Online (Sandbox Code Playgroud)

现在让我们尝试覆盖这些文件。

raj@jarek-02:~/test$ echo "Overwriting file 1" > file1
raj@jarek-02:~/test$ echo "Overwriting file 2" > file2
bash: file2: Permission denied
raj@jarek-02:~/test$ echo "Overwriting file 3" > file3
Run Code Online (Sandbox Code Playgroud)

第一个和第三个命令成功(因为没有输出),第二个命令失败并显示“权限被拒绝”消息。

现在尝试再次显示文件:

raj@jarek-02:~/test$ cat file1
cat: file1: Permission denied
raj@jarek-02:~/test$ cat file2
This is file 2
raj@jarek-02:~/test$ cat file3
Overwriting file 3
Run Code Online (Sandbox Code Playgroud)

file1尽管我能够更改它,但我仍然无法显示。file2没有改变(因为尝试更改时出现“权限被拒绝”消息),我们可以看到它确实file3发生了变化。

为了验证file1是否也发生了更改,让我们尝试将其显示为root具有文件读取权限的用户:

root@jarek-02:/home/raj/test# cat file1
Overwriting file 1
Run Code Online (Sandbox Code Playgroud)

因此,实际上raj具有写访问权限的用户能够更改文件的内容,但在更改之前或之后都无法读取该文件。


Aus*_*arn 6

不,正如其他答案所指出的,书中的说法是错误的。

\n

只写文件/目录在现实生活中实际上有多种使用方式:

\n
    \n
  • /proc/sys中,当文件用于以面向事件的方式向内核发出某些信号但没有可供用户查询的有用关联状态时使用只写文件。最常见的情况是/sys用于显式绑定或取消绑定驱动程序的文件,以及v2 cgroup 中找到的cgroup.killmemory.reclaim文件(分别用于自动终止 cgroup 中的所有进程,并手动触发该 cgroup 中的内存回收)。
  • \n
  • 只写目录通常用于文件上传系统。用户可以写入该目录,但看不到其中的\xe2\x80\x99s。这很重要,因为它确保用户无法看到其他人上传的内容。
  • \n
  • 共享热目录设置有时也使用只写目录,出于本质上与它们\xe2\x80\x99 用于文件上传目录相同的安全原因。
  • \n
  • 在某些情况下,给定服务的日志文件对于配置为运行该服务的用户来说可能是只写的。这是有效的,因为日志是仅附加的(因此服务在打开文件时只是查找末尾,然后开始写入),并且它确保以某种方式危害服务的攻击者无法读取日志。
  • \n
\n
\n

更一般地说,认为 Linux 或其他类似 UNIX 上的任何权限都是隐式的这一想法通常是错误的。在经典的 UNIX DAC 模型中,隐含权限恰好为零,一切都明确编码。POSIX ACL、NFSv4 ACL 以及我所知道的所有 Linux MAC 系统也是如此。可能的例外是一些Linux 功能,但如果您不了解实际检查的内容,那么这些功能看起来只是隐含的。

\n

这很重要,因为隐式权限是危险的。由于它们没有明确编码,因此很容易忘记它们,并且忘记它们通常会导致安全问题。

\n