Users of client computers can use the chmod 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 (UID) of the file owner, not the UID 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 ID (GID) where 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 permissions allow it), but not to transfer ownership to a second user. Consequently, to use chown or chgrp 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 through Active Directory Lookup or 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.

Security issue

Changing setuid and setgid behavior