Differences between version 3 and revision by previous author of chown(2).
Other diffs: Previous Major Revision, Previous Revision, or view the Annotated Edit History
| Newer page: | version 3 | Last edited on Wednesday, October 30, 2002 12:01:37 am | by PerryLorier | Revert |
| Older page: | version 1 | Last edited on Tuesday, June 4, 2002 12:23:39 am | by perry | Revert |
@@ -1,207 +1,51 @@
CHOWN
!!!CHOWN
-NAME
-SYNOPSIS
-DESCRIPTION
-RETURN VALUE
-ERRORS
-NOTES
-CONFORMING TO
-RESTRICTIONS
-SEE ALSO
----
!!NAME
-
-, fchown, lchown
- change ownership of a file
+chown - change ownership of a file
!!SYNOPSIS
+ __#include <sys/types.h>__
+ __#include <unistd.h>__
+ __int chown(const char *__''path''__, uid_t__ ''owner''__, gid_t__ ''group''__);__
-__#include __
-#include __
-
-
-__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''__);__
!!DESCRIPTION
+The owner of the file specified by ''path''. Only the super-user 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. The super-user may change the group arbitrarily.
-The owner of
the file specified by
''path
'' or by
-fd
'' is changed. Only the super
-user 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. The
-super-user may change the group arbitrarily
.
+If
the ''owner
'' or ''group
'' is specified as
-1, then
that ID
is not changed
.
+When the owner or group of an executable file are changed by a non-super-user, the S_ISUID and S_ISGID mode bits are cleared. POSIX does not specify whether this also should happen when root does the ''chown''; 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 ''chown''.
-If the ''owner'' or ''group'' is specified as -1, then
-that ID is not changed.
-
-
-When the owner or group of an executable file are changed by
-a non-super-user, the S_ISUID and S_ISGID mode bits are
-cleared. POSIX does not specify whether this also should
-happen when root does the ''chown''; 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 ''chown''.
!!RETURN VALUE
-
-
-
-
+On success, zero is returned. On error, -1 is returned, and ''errno'' is set appropriately.
!!ERRORS
+Depending on the file system, other errors can be returned. The more general errors for __chown__ are listed below:
-Depending on the file system, other errors can be returned.
-The more general errors for __chown__ are listed
-below
:
-
-
-__EPERM__
-
-
-
-
-
-
-
-__
EROFS__
-
-
-
-
-
-
-__
EFAULT__
-
-
-
-
-
-
-__
ENAMETOOLONG__
-
-
-
-
-
-__
ENOENT__
-
-
-
-
-
-__
ENOMEM__
-
-
-
-
-
-__
ENOTDIR__
-
-
-
-
-
-
-__
EACCES__
-
-
-
-
-
-
-__
ELOOP__
-
-
-
-
-
-
-The general errors for __fchown__ are listed
-below
:
-
-
-__EBADF__
-
-
-The descriptor is not valid.
-
-
-__ENOENT__
-
-
-See above.
-
-
-__EPERM__
-
-
-See above.
-
-
-__EROFS__
-
-
-See above.
-
-
-__EIO__
-
-
-
-
+;[EPERM]
: The effective UID does not match the owner of the file, and is not zero; or the ''owner'' or ''group'' were specified incorrectly.
+;[
EROFS]:
The named file resides on a read-only file system.
+;[
EFAULT]:
''path'' points outside your accessible address space.
+;[
ENAMETOOLONG]:
''path'' is 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.
+;[
EACCES]:
Search permission is denied on a component of the path prefix.
+;[
ELOOP]:
Too many symbolic links were encountered in resolving ''path''.
+;[EIO]
: A low-level I/O error occurred while modifying the inode.
!!NOTES
+In versions of Linux prior to 2.1.81 (and distinct from 2.1.46), __chown__ did not follow symbolic links. Since Linux 2.1.81, __chown__ does follow symbolic links, and there is a new system call lchown(2) that does not follow symbolic links. Since Linux 2.1.86, this new call (that has the same semantics as the old __chown__) has got the same syscall number, and __chown__ got the newly introduced number.
-In versions of Linux prior to 2.1.81 (and distinct from
-2.1.46), __chown__ did not follow symbolic links. Since
-Linux 2.1.81, __chown__ does follow symbolic links, and
-there is a new system call __lchown__ that does not
-follow symbolic links. Since Linux 2.1.86, this new call
-(that has the same semantics as the old __chown__) has
-got the same syscall number, and __chown__ got the newly
-introduced number.
-
-
-The prototype for __fchown__ is only available if
-___BSD_SOURCE__ is defined (either explicitly, or
-implicitly, by not defining _POSIX_SOURCE or compiling with
-the -ansi flag).
!!CONFORMING TO
+The __chown__ call conforms to SVr4, SVID, POSIX, X/OPEN. The 4.4BSD version can only be used by the superuser (that is, ordinary users cannot give away files). SVr4 documents [EINVAL], [EINTR], [ENOLINK] and [EMULTIHOP] returns, but no [ENOMEM]. POSIX.1 does not document [ENOMEM] or [ELOOP] error conditions.
-The __chown__ call conforms to SVr4, SVID, POSIX, X/OPEN.
-The 4.4BSD version can only be used by the superuser (that
-is, ordinary users cannot give away files). SVr4 documents
-EINVAL, EINTR, ENOLINK and EMULTIHOP returns, but no ENOMEM.
-POSIX.1 does not document ENOMEM or ELOOP error
-conditions.
-
-
-The __fchown__ call conforms to 4.4BSD and SVr4. SVr4
-documents additional EINVAL, EIO, EINTR, and ENOLINK error
-conditions.
!!RESTRICTIONS
-
-
-
-
-
-
-
-
-
-
+The __chown__() 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 __chown__() 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.
!!SEE ALSO
-
-
+chmod(2), flock(2), fchown(2), lchown
(2)
----
