[置顶] unix环境高级编程-4.9-chmod，fchmod函数和粘住位

这两个函数可以更改我们现有文件的访问权限。

#include <sys/stat.h>

int chmod(const char *pathname,mode_t mode);

int fchmod(int filedes,mode_t mode);

以上函数返回0是表示成功，-1，表示不成功。

查看GNU C手册：

int chmod (const char *filename, mode t mode) [Function]
The chmod function sets the access permission bits for the file named by filename to
mode.
If filename is a symbolic link, chmod changes the permissions of the file pointed to by（如果文件名字是链接，chmod通过链接改变权限。而不是链接本身）
the link, not those of the link itself.
This function returns 0 if successful and -1 if not. In addition to the usual file name
errors (see Section 11.2.3 [File Name Errors], page 224), the following errno error
conditions are defined for this function:
ENOENT The named file doesn’t exist.
EPERM This process does not have permission to change the access permissions
of this file. Only the file’s owner (as judged by the effective user ID of
the process) or a privileged user can change them.
EROFS The file resides on a read-only file system.
EFTYPE mode has the S_ISVTX bit (the “sticky bit”) set, and the named file is
not a directory. Some systems do not allow setting the sticky bit on

non-directory files, and some do (and only some of those assign a useful
meaning to the bit for non-directory files).
You only get EFTYPE on systems where the sticky bit has no useful meaning
for non-directory files, so it is always safe to just clear the bit in mode
and call chmod again. See Section 14.9.5 [The Mode Bits for Access Permission],
page 370, for full details on the sticky bit.

 

int fchmod (int filedes, int mode) [Function]
This is like chmod, except that it changes the permissions of the currently open file（当前已经打开的）
given by filedes.
The return value from fchmod is 0 on success and -1 on failure. The following errno
error codes are defined for this function:
EBADF The filedes argument is not a valid file descriptor.
EINVAL The filedes argument corresponds to a pipe or socket, or something else
that doesn’t really have access permissions.
EPERM This process does not have permission to change the access permissions
of this file. Only the file’s owner (as judged by the effective user ID of
the process) or a privileged user can change them.
EROFS The file resides on a read-only file system.

 

从上边函数解释可以知道，chmod 函数在制定的文件进行操作，而fchmod函数则对已经打开的文件进行操作。

为了改变一个文件的权限位，进程有效用户ID，必须等于文件的所有者ID,或者该进程必须具有超级用户权限。

下表所示常量的某种按位或运算构成的。

 

Chmod函数的mode常量
mode	说明
S_ISUID S_ISGID S_ISVIX	执行时设置用户ID 执行时设置组ID 保存正文(粘住位)
S_IRWXU S_IRUSR S_IWUSR S_IXUSR	用户(所有者)读、写和执行 用户(所有者)读 用户(所有者)写 用户(所有者)执行
S_IRWXG S_IRGRP S_IWGRP S_IXGRP	组读、写和执行 组读 组写 组执行
S_IRWXO S_IROTH S_IWOTH S_IXOTH	其他读、写和执行 其他读 其他写 其他执行

上一节我们生成了foo bar两个文件。

下面实例来修改这两个文件的权限模式。

实例

#include "apue.h"

int main(void)
{
        struct stat  statbuf;
        if(stat("foo",&statbuf)<0)
          err_sys("stat error for foo");
        if(chmod("foo",(statbuf.st_mode&~S_IXGRP)|S_ISGID)<0)
          err_sys("chmod err for foo");

        if(chmod("bar",S_IRUSR|S_IWUSR|S_IRGRP|S_IROTH)<0)
         err_sys("chmod err for bar");

        exit(0);


}

运行结果：

 chmod函数在下列条件下自动清除两个权限位。

• Solaris等系统对用于普通文件的你那诸位腹语了特殊含义，在这些系统如果我们试图设置普通文件的粘住位，而且有没有超级用户的用户特权。那么mode忠的年诸位将自动被关闭，这意味这只有超级用户才能设置普通文件的年诸位，这样做的理由是方式不怀好意的用户设置年诸位，并由此降低系统性能。
• 新创建文件的组ID，可能不是调用进程所属组。新文件的组ID，可能是父目录的组ID,特别的，如果新文件的组ID,不等于进程的有效组ID,或者进程附加组ID中的一个，以及进程没有超级用户的特权，那么设置组ID文件，二该文件是有并非该用户所诉的组拥有的。

4.10 粘住位

S_ISVTX位有一有趣历史。

S_ISVTX位被称为粘住位。如果一个可执行程序文件的这一位被设置了，那么在该程序第一次被执行并结束时，其程序正文部分的一个副本仍被保存在交换区中，这使得下次执行该程序时能较快地将其装入内存区。其原因是：

交换区占用连续磁盘空间，可将它视为连续文件，而且一个程序的正文部分在交换区中也是连续存放的，而在一般的UNIX文件系统中，文件的各数据块很可能是随机存放的。

现今较新的UNIX系统大多都配置有虚拟存储系统以及快速文件系统，所以不再需要使用这种技术。

如果对一个目录设置了粘住位，则只有对该目录具有写权限的用户在满足下列条件之一的情况下，才能删除或更名该目录下的文件：1.拥有该文件    2. 拥有该目录    3. 是超级用户

示例：目录/tmp和/var/spool/uucppublic是设置粘住位的典型候选者——任何用户都可在这两个目录中创建文件。任一用户(用户、组和其他)对这两个目录的权限通常都是读、写和执行。但用户不应删除或更名属于其他人的文件，为此在这两个目录的文件模式中都设置了粘住位。

 

更多内容欢迎访问：http://blog.csdn.net/wallwind