We have discussed how write permission controls the ability to change the data in a file. But how about changing the permission bits, the owner, the group, and even the timestamps? No one can change anything on a CD and an NFS server can overrule an NFS client. In the following discussion, I will assume a local read-write filesystem and that the user called "root" has appropriate special administrative privileges for the file system in question.
chmod -- Changing The File Permissions
To change the file permissions at all, you must be the owner of the file or you must be the root user. The root user can change any permission bit. This may not be true of the owner. The one bit that the owner may not be able to switch on is the SGID bit.
To turn on that bit, the owner must be a member of the group that the file is in. If this restriction was not in place, a user could simply create an SGID program to give himself access to files controlled by groups other than those to which he belongs. Remember that, as we mentioned above, the SGID bit has been often overloaded into also being used for file locking. A version of Unix may or may not allow a file owner to switch on the SGID bit of a file in a different group if no execute bit is set.
Simply turning on an execute bit may result in the SUID and SGID bits being cleared (even for root). This is a security feature to ensure that the user intends for the SUID and SGID bits to be set. The user can switch them back on explicitly. Or the user can simply explicitly set all the bit at once. Also be aware that writing to a file may, on some versions of Unix, clear the SUID and SGID bits. See below for the effect of changing the owner or group of a file.
chown -- Changing The File Owner
Originally, Unix allowed a file owner to give away a file. A file's owner could change the owner to someone else. There was no way for a non-root user to undo this operation. When Unix split into a Berkeley/AT&T versions, the USG (Unix Support Group, part of AT&T) versions of Unix tended to inherit this behavior. Meanwhile BSD (Berkeley Software Distribution, part of University of California, Berkeley) removed chown from non-root users. BSD had implemented disk quotas which could limit how much disk space a user could have in a filesystem. Naughty users could give away large files to sneek past the quotas.
Today, it is not easy to say if a non-root can chown a file. Many versions of Unix allow
both behaviors. HP-UX has a
setprivgroup facility that can control whether or not members of a particular group can invoke chown. Solaris has a global paramter
rstchown which can be set to allow global chown. Setting this parameter also disables a change-group limitation described below (without affecting the SGID limitations described above). Recent Linux version have a
CAP_CHOWN capability to control this feature. You will need to consult your documentation for other versions of Unix. And you will need to consult your System Administrator to see how your particular system is configured.
The default with most OS's is for chown to be restricted to root only. And there is a consensus that it should stay this way for security considerations. If a non-root user does change the owner of a file and any execute bit is on, the SUID and SGID bits must be cleared. This may or may not happen with root.
chown, chgrp -- Changing The File Group
The chown command can (with any modern, Posix compliant version of Unix) also attempt a group change. And there is a chgrp command. Both of these invoke the chown() system call to change a group. The fact that a common system call is involved helps explain why some OS versions jointly enforce or relax restrictions on non-root users for both owner and group changes.
A non-root user can change the group of file he owns to a group of which he is a member. Posix prohibits a non-root user from changing a files group to a group of which he is not a member. But some OS's lift this restriction if the restriction against changing a file's owner has been lifted.
If the group is changed by a non-root user and one or execute bits are set, the SUID and SGID bits are cleared.
touch -- Changing The File Timestamps
When the touch command is used to change the timestamps of an existing file, it invokes either the old utime() or the new utimes() system call. To change the timestamp on an existing file, you must own the file or be root. Also, you must have write permission on the file or be root.