View Source: chown(2) - Waikato Linux Users Group

Edit PageHistory Diff Info LikePages
CHOWN
!!!CHOWN
----
!!NAME

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''__);__

!!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.

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:

;[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.

!!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.

!!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)
----
13 pages link to chown(2):
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.
Last edited on Wednesday, October 30, 2002 12:01:37 am by PerryLorier
Edit PageHistory Diff Info LikePages