【Linux&Unix--文件描述符与权限】

╰+哭是因爲堅強的太久メ 2022-08-27 13:53 250阅读 0赞

个人学习整理，如有不足之处，请不吝指教。转载请注明：[@CSU-Max][CSU-Max]

系列博文：

**[Linux&Unix学习第一弹 —— 文件描述符与权限][Linux_Unix] **

** **[**Linux&Unix学习第二弹 -- 文件描述符与权限**][Linux_Unix_ --]

# 文件描述符 #

每个UNIX进程都有一个文件描述符范围，其大小为0到N，N标志文件描述符的最大值，N的大小取决于UNIX的版本及系统配置。实际上，它是一个索引值，指向内核为每一个进程所维护的该进程打开文件的记录表。当程序打开一个现有文件或者创建一个新文件时，内核向进程返回一个文件描述符。在Linux和Unix操作系统的程序设计中，一些涉及底层的程序编写往往会围绕着文件描述符展开。

## 标准文件描述符 ##

一般在进程运行时前三个文件描述符就已经打开了。

文件描述符 0 ： 标准输入

文件描述符 1 ： 标准输出

文件描述符 2 ： 标准错误输出

除了使用数字来表示之外，也可以使用符号常数，对应的分别是为：STDIN\_FILENO， STDOUT\_FILENO， STDERR\_FILENO。

这些标准文件描述符中任何一个都可以打开文件、管道、FIFO、设备甚至是套接字，调用read和write系统调用时可以立即使用这三个标准文件描述符。用于文件、管道等其他的文件描述符可以通过进程本身获得。

文件描述符只是对每个进程表的索引。进程表中每个记录项指向一个全系统的打开文件描述（即文件表记录项），而文件描述符指向文件数据。

上述过程可用下图表示：

![SouthEast][]

![SouthEast 1][]

如上图所示，多个文件描述符，甚至来自不同进程的文件描述符都可指向同一个文件描述。

每一个open或pipe系统调用都会创建一个新的打开文件描述和新的文件描述符。如上图所示，进程A两次都打开了同一个文件，得到了文件描述符5和6之后，并创建了打开文件描述1和2，后通过文件描述符复制机制，进程A得到了文件描述符5的复制品——文件描述符7。当然，文件描述符7指向的打开文件描述与文件描述符5指向的是相同的，即指向同一个打开文件描述，而不是像前面所说会创建新的。进程B是进程A的子进程，文件描述符3同意是文件描述符5的复制品。

# 文件权限及表示 #

每个文件的信息节点中都有一个所有者用户ID（简称所有者）和一个所有者组ID（简称组），同时，信息节点中还包含有三组权限位，每组三位，每组包含一个读权限位，一个写权限位和一个执行权限位。值为1时表示允许权限，为0时表示拒绝权限。三组权限中，一组用于所有者，一组用于组，一组用于其他用户（即不在前面两类中）。

权限位一般按照所有者、组、其他用户三组的一次顺序来表示的，通常用八进制数来表示。具体表示方法如下图所示：

![SouthEast 2][]

例如，八进制数755表示所有者有读、写和执行的权限，而组和其他用户只有读和执行权限。ls 命令显示其权限组合为 rwxr-xr-x ，用二进制表示为 111101101 。

# 文件权限位符号 #

如果你认为文件权限必须用上述的方法：9个文件权限位应该放在一起，并有一定的顺序（所有者、组、其他用户），那就错了。实际上并非如此，只要有这9个权限位即可。

权限位符号就是另外一种表示文件权限的方法，可用来代替传统的八进制数表示。这些符号的形式为 S\_Ipwww ，其中 p 代表访问权限（R，W或X），www 代表谁操作（USR， GRP 或 OTH），这就表示出了全部的9个符号。

例如之前提到的例子，不用八进制的755，可用权限位符号表示如下：

当USR、GRP或OTH拥有所有的三种访问权限时，则可以使用单独的符号，形式如： S\_IRWXw 。这里 w 表示的是用户类型，即可为U、G或O。故上述文件访问权限也可以表示如下：

S\_IRWXU | S\_IRGRP | S\_IXGRP | S\_IROTH |S\_IXOTH

虽然这种描述方式可读性较差，也很容易出错，但是操作者可自由安排权限位的位置，并且读编程来说它也更加方便，一般我们会一次性定义好所需要的宏，而不是在所有需要的位置都使用长的如 S\_IRUSR 的符号序列。

\#define PERM\_DIRECTORY       S\_IRWXU

\#define PERM\_FILE             (S\_IRSUR | S\_IWSUR | S\_IRGRP | S\_IROTH)

这样仅需改变一次宏，就可以改变整个应用程序的访问权限策略。

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

\*  转载请注明出处：  [@CSU-Max][CSU-Max]   [ http://blog.csdn.net/csu\_max][CSU-Max]      \*

\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

[CSU-Max]: http://blog.csdn.net/csu_max
[Linux_Unix]: http://blog.csdn.net/csu_max/article/details/37723253
[Linux_Unix_ --]: http://blog.csdn.net/csu_max/article/details/38086223
[SouthEast]: /images/20220823/5c508a7b5d4547129d1a359d0a3d0a67.png
[SouthEast 1]: /images/20220823/cd13dbfad9624c15a06a3e080179ab5c.png
[SouthEast 2]: /images/20220823/8b40873affce4bb3be6c3e39dc3efd4c.png