Understanding setuid, setgid, and sticky bits

Users of client computers can use the chmod(1) utility to set the setuid (set-user-identifier-on-execution), setgid (set-group-identifier-on-execution), and sticky file mode bits on files or directories that are stored on an NTFS file system partition and shared through Server for NFS. When the file or directory is subsequently accessed by a UNIX-based client, the standard semantics for these bits will apply. For example, an executable file that has the setuid bit set will execute under the user ID of the file's owner, not the user ID of the user who is executing the file.

Typically, when the setuid or setgid bit is set on a file, the owner or group of the file is changed to the owner or group under whose ID the file will be executed. Unless a user has the right to restore files or directories, Windows security allows a user to take ownership of a file (if the file's permissions allow it), but not to transfer ownership to a second user. Consequently, to use chown(1) or chgrp(1) to change the owner or group of a file to another user or group, you must have the privilege to restore files and directories. By default, this privilege is assigned to members of the Administrators and Backup Operators groups, although it can be assigned to other groups or to individual users. In addition, the account of the user running chown or chgrp and the user or group to whom ownership is being transferred must be properly mapped by User Name Mapping.

Some UNIX-based network file system (NFS) servers apply special interpretations or restrictions for the setuid, setgid, and sticky bits. Some versions of UNIX, for example, enforce mandatory locking on a directory with the setgid bit set but no execute permissions. Server for NFS does not implement special interpretations or restrictions on using these bits.