On many systems, a root or superuser has complete control of the system. The Interix subsystem does not recognize a root user. When the POSIX standard was developed, the concept of a root user was considered an administrative issue. Instead of a root user, the POSIX standard defines appropriate privileges for some operations.
The setuid and setgid mechanisms allow a program, when run, to adopt certain aspects of a security principal other than that of the user running the program. They allow the program to alternate these aspects between those of the invoking user and those of the "other" security principal.
Appropriate privileges are distinct from this. The setuid and setgid mechanisms allow an application to control the answer to the question, "Who are you?" Appropriate privileges answer the question, "What can you do?"
In classical UNIX systems, there is exactly one user to whom all privileges are granted. That user, typically called "root," has uid == 0. In Interix, all supported privileges on a given system are granted to all users who are members of the Administrators group on that system. You do not need to log on as "Administrator." Any user who has membership in the Administrators group possesses the privileges. Not all privileges defined in POSIX or UNIX are available under Interix; that is, there are certain privileges granted to no user at all.
Appropriate privileges are typically required for a variety of actions. These include accessing the file system, sending signals to other processes (process control), or changing the effective user identifier (UID) or group identifier (GID) for a process in order to change the ability of that process to perform certain actions.
According to the POSIX standard, a file has permissions that include bits to set a UID (setuid) and set a GID (setgid). If either or both bits are set on a file, and a process executes that file, the process gains the UID or GID of the file. When used carefully, this mechanism allows a nonprivileged user to execute programs that run with the higher privileges of the file's owner or group. When used incorrectly, however, this can present security risks by allowing nonprivileged users to perform actions that should only be performed by an administrator. For this reason, Interix does not support this mechanism by default. Instead, if you attempt to execute a file with either the setuid or setgid bit set, Interix does not execute the file and returns the error code ENOSETUID.
If you rely on an application that requires standard POSIX behavior, you can configure Interix to execute files with the setuid or setgid bits set. If Interix is configured in this way, when a process executes a file that has the setuid or setgid bit set, Interix constructs local security tokens for the process with the privileges assigned to the owner or group of the file. Because the tokens are local, they are not recognized by other computers on the network. This means that, even if the file is owned by a member of the Domain Administrators group, for example, the process will not have trusted access through Windows networking to other computers in the domain. Instead, the privileges will be effective only on the computer on which the process is running.
For example, a process executes a program file with its setuid bit set and owned by a member of the Domain Admins group. If that program attempts to change a domain user's password, that attempt will fail because the security tokens of the process are local and so are not recognized by other systems in the domain. If, on the other hand, the program attempts to change a local user's password, the attempt will succeed because the file's owner is a member of the Domain Admins group, which typically belongs to the local computer's Administrator's group. For information on how to configure Interix to execute files with the setuid or setgid bits set, see To enable execution of files with setuid or setgid mode bits set.
For the setuid(2)
,
setgid(2),
and chroot(2)
functions, a process must have the effective UID that maps back to
the system account, the administrator account for the local domain,
or the administrator account for the principal domain. The local
administrator account can only change the UID or GID to another ID
in the same domain.
For chown(1),
chmod(1),
and chgrp(1), an
account must have the Windows privileges SE_BACKUP and SE_RESTORE
to make files owned by another user or group, or to modify
permissions on a file owned by another user. These permissions
typically belong to the Administrator and Backup Operator
accounts.
For more information, see privileges.