Setuid and setgid

Some programs, such as passwd, need to run as a specific user in order to work properly:

$ which -l passwd
-rwsrwxr-x  1 root      root         21544 Mar 30 23:34 /usr/bin/passwd

Notice that the third character in the owner's permissions is s. This indicates a setuid (“set user ID”) command; when you run passwd, the program runs as the owner of the file (i.e., root). An S means that the setuid bit is set for the file, but the execute bit isn't set.

You might also find some setgid (“set group ID”) commands, which run with the same group ID as the owner of the file, but not with the owner's user ID. If setgid is set on a directory, files created in the directory have the directory's group ID, not that of the file's creator. This scheme is commonly used for spool areas, such as /usr/spool/mail, which is setgid and owned by the mail group, so that programs running as the mail group can update things there, but the files still belong to their normal owners.

Note: If you change the ownership of a setuid command, the setuid bit is cleared, unless you're logged in as root. Similarly, if you change the group of a setgid command, the setgid bit is cleared, unless you're root.

When running on a Windows host, mkefs, mketfs, and mkifs can't get the execute (x), setuid (“set user ID”), or setgid (“set group ID”) permissions from the file. Use the perms attribute to specify these permissions explicitly. You might also have to use the uid and gid attributes to set the ownership correctly. To determine whether or not a utility needs to have the setuid or setgid permission set, see its entry in the Utilities Reference.

CAUTION:

Setuid and setgid commands can cause a security problem. If you create any, make sure that only the owner can write them, and that a malicious user can't hijack them—especially if root owns them.