sticky(7) [netbsd man page]

STICKY(7)					       BSD Miscellaneous Information Manual						 STICKY(7)

NAME

     sticky -- Description of the `sticky' (S_ISVTX) bit functionality

DESCRIPTION

     A special file mode, called the sticky bit (mode S_ISVTX), is used to indicate special treatment for directories.	See chmod(2) or the file
     /usr/include/sys/stat.h

   Sticky files
     For regular files, the use of mode S_ISVTX is reserved and can be set only by the super-user.  NetBSD does not currently treat regular files
     that have the sticky bit set specially, but this behavior might change in the future.

   Sticky directories
     A directory whose ``sticky bit'' is set becomes a directory in which the deletion of files is restricted.	A file in a sticky directory may
     only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of
     the directory, or the super-user.	This feature is usefully applied to directories such as /tmp which must be publicly writable but should
     deny users the license to arbitrarily delete or rename each others' files.

     Any user may create a sticky directory.  See chmod(1) for details about modifying file modes.

HISTORY

     The sticky bit first appeared in V7, and this manual page appeared in section 8.  Its initial use was to mark sharable executables that were
     frequently used so that they would stay in swap after the process exited.	Sharable executables were compiled in a special way so their text
     and read-only data could be shared amongst processes.  vi(1) and sh(1) were such executables.  This is where the term ``sticky'' comes from -
     the program would stick around in swap, and it would not have to be fetched again from the file system.  Of course as long as there was a
     copy in the swap area, the file was marked busy so it could not be overwritten.  On V7 this meant that the file could not be removed either,
     because busy executables could not be removed, but this restriction was lifted in BSD releases.

     To replace such executables was a cumbersome process.  One had first to remove the sticky bit, then execute the binary so that the copy from
     swap was flushed, overwrite the executable, and finally reset the sticky bit.

     Later, on SunOS 4, the sticky bit got an additional meaning for files that had the bit set and were not executable: read and write operations
     from and to those files would go directly to the disk and bypass the buffer cache.  This was typically used on swap files for NFS clients on
     an NFS server, so that swap I/O generated by the clients on the servers would not evict useful data from the server's buffer cache.

BUGS

     Neither open(2) nor mkdir(2) will create a file with the sticky bit set.

BSD
								   May 10, 2011 							       BSD

CHMOD(2)						      BSD System Calls Manual							  CHMOD(2)

NAME

     chmod, lchmod, fchmod -- change mode of file

LIBRARY

     Standard C Library (libc, -lc)

SYNOPSIS

     #include <sys/stat.h>

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

     int
     lchmod(const char *path, mode_t mode);

     int
     fchmod(int fd, mode_t mode);

DESCRIPTION

     The function chmod() sets the file permission bits of the file specified by the pathname path to mode.  fchmod() sets the permission bits of
     the specified file descriptor fd.	lchmod() is like chmod() except in the case where the named file is a symbolic link, in which case
     lchmod() sets the permission bits of the link, while chmod() sets the bits of the file the link references.  chmod() verifies that the
     process owner (user) either owns the file specified by path (or fd), or is the super-user.  A mode is created from or'd permission bit masks
     defined in <sys/stat.h>:
	   #define S_IRWXU 0000700    /* RWX mask for owner */
	   #define S_IRUSR 0000400    /* R for owner */
	   #define S_IWUSR 0000200    /* W for owner */
	   #define S_IXUSR 0000100    /* X for owner */

	   #define S_IRWXG 0000070    /* RWX mask for group */
	   #define S_IRGRP 0000040    /* R for group */
	   #define S_IWGRP 0000020    /* W for group */
	   #define S_IXGRP 0000010    /* X for group */

	   #define S_IRWXO 0000007    /* RWX mask for other */
	   #define S_IROTH 0000004    /* R for other */
	   #define S_IWOTH 0000002    /* W for other */
	   #define S_IXOTH 0000001    /* X for other */

	   #define S_ISUID 0004000    /* set user id on execution */
	   #define S_ISGID 0002000    /* set group id on execution */
	   #define S_ISVTX 0001000    /* sticky bit */

     The mode ISVTX (the 'sticky bit') can be set on a regular file by the super-user, but has no effect.

     If mode ISVTX (the 'sticky bit') is set on a directory, an unprivileged user may not delete or rename files of other users in that directory.
     The sticky bit may be set by any user on a directory which the user owns or has appropriate permissions.

     For more information about the history and properties of the sticky bit, see sticky(7).

     Changing the owner of a file turns off the set-user-id and set-group-id bits; writing to a file turns off the set-user-id and set-group-id
     bits unless the user is the super-user.  This makes the system somewhat more secure by protecting set-user-id (set-group-id) files from
     remaining set-user-id (set-group-id) if they are modified, at the expense of a degree of compatibility.

RETURN VALUES

     Upon successful completion, a value of 0 is returned.  Otherwise, a value of -1 is returned and errno is set to indicate the error.

ERRORS

     chmod() and lchmod() will fail and the file mode will be unchanged if:

     [ENOTDIR]		A component of the path prefix is not a directory.

     [ENAMETOOLONG]	A component of a pathname exceeded {NAME_MAX} characters, or an entire path name exceeded {PATH_MAX} characters.

     [ENOENT]		The named file does not exist.

     [EACCES]		Search permission is denied for a component of the path prefix.

     [ELOOP]		Too many symbolic links were encountered in translating the pathname.

     [EPERM]		The effective user ID does not match the owner of the file and the effective user ID is not the super-user.

     [EPERM]		The mode includes the setgid bit (S_ISGID) but the file's group is neither the effective group ID nor is it in the group
			access list.

     [EROFS]		The named file resides on a read-only file system.

     [EFAULT]		path points outside the process's allocated address space.

     [EIO]		An I/O error occurred while reading from or writing to the file system.

     [EFTYPE]		The effective user ID is not the super-user, the mode includes the sticky bit (S_ISVTX), and path does not refer to a
			directory.

     fchmod() will fail if:

     [EBADF]		The descriptor is not valid.

     [EINVAL]		fd refers to a socket, not to a file.

     [EPERM]		The effective user ID does not match the owner of the file and the effective user ID is not the super-user.

     [EPERM]		The mode includes the setgid bit (S_ISGID) but the file's group is neither the effective group ID nor is it in the group
			access list.

     [EROFS]		The file resides on a read-only file system.

     [EIO]		An I/O error occurred while reading from or writing to the file system.

     [EFTYPE]		The effective user ID is not the super-user, the mode includes the sticky bit (S_ISVTX), and fd does not refer to a direc-
			tory.

SEE ALSO

     chmod(1), chflags(2), chown(2), open(2), stat(2), getmode(3), setmode(3), sticky(7), symlink(7)

STANDARDS

     The chmod() function conforms to ISO/IEC 9945-1:1990 (``POSIX.1'').

HISTORY

     The fchmod() function call appeared in 4.2BSD.  The lchmod() function call appeared in NetBSD 1.3.

BSD
								 October 11, 2011							       BSD