chown, fchown, lchown - 改变文件的所有权
内容简介
#include <sys/types.h> #include <unistd.h> int chown(const char *path, uid_t owner, gid_t group) int fchown(int fd, uid_t owner, gid_t group) int lchown(const char *path, uid_t owner, gid_t group) |
描述
These system calls change the owner and group of the file specified by%uA0path%uA0or by%uA0fd. Only a privileged process (Linux: one with the%uA0CAP_CHOWNꃊpability) may change the owner of a file. The owner of a file may change the group of the file to any group of which that owner is a member. A privileged process (Linux: with%uA0CAP_CHOWN) may change the group arbitrarily.
If the%uA0owner%uA0or%uA0group%uA0is specified as -1, then that ID is not changed. When the owner or group of an executable file are changed by a non-superuser, the S_ISUID and S_ISGID mode bits are cleared. POSIX does not specify whether this also should happen when root does the%uA0chown() the Linux behaviour depends on the kernel version. In case of a non-group-executable file (with clear S_IXGRP bit) the S_ISGID bit indicates mandatory locking, and is not cleared by a%uA0chown().
返回值
成功,则返回0。上的错误,则返回-1,errno设置为合适。
错误
根据文件系统上的,其他错误,也可以返回%uA0chown()%uA0更一般的错误在下面列出。%uA0
Error Code | 描述 |
---|---|
EACCES | Search permission is denied on a component of the path prefix. (See also%uA0path_resolution(2).) |
EFAULT | path%uA0points outside your accessible address space. |
ELOOP | Too many symbolic links were encountered in resolving%uA0path. |
ENAMETOOLONG | path%uA0is too long. |
ENOENT | The file does not exist. |
ENOMEM | Insufficient kernel memory was available. |
ENOTDIR | A component of the path prefix is not a directory. |
EPERM | The calling process did not have the required permissions (see above) to change owner and/or group. |
EROFS | The named file resides on a read-only file system. |
The general errors for%uA0fchown() are listed below: | |
EBADF | The descriptor is not valid. |
EIO | A low-level I/O error occurred while modifying the inode. |
ENOENT | See above. |
EPERM | See above. |
EROFS | See above. |
注意
In versions of Linux prior to 2.1.81 (and distinct from 2.1.46),%uA0chown() did not follow symbolic links. Since Linux 2.1.81,%uA0chown() does follow symbolic links, and there is a new system call%uA0lchown() that does not follow symbolic links. Since Linux 2.1.86, this new call (that has the same semantics as the old%uA0chown()) has got the same syscall number, and%uA0chown() got the newly introduced number.
The prototype for%uA0fchown() is only available if%uA0_BSD_SOURCE%uA0is defined.
遵循于
4.4BSD, SVr4, POSIX.1-2001. The 4.4BSD version can only be used by the superuser (that is, ordinary users cannot give away files).
限制
The%uA0chown() semantics are deliberately violated on NFS file systems which have UID mapping enabled. Additionally, the semantics of all system calls which access the file contents are violated, because%uA0chown() may cause immediate access revocation on already open files. Client side caching may lead to a delay between the time where ownership have been changed to allow access for a user and the time where the file can actually be accessed by the user on other clients.