User and group information is stored in the Security Access database. Users and groups are stored in the same database, so group and user names must be unique; no group can have a user's name and vice versa. (This database replaces /etc/passwd and /etc/groups files.) Users and groups are created using User Manager or using the MS-DOS net user command. (Example shell scripts to create and remove users are included in the directory /usr/examples/admin.) Users can belong to many groups.
Permissions are not implemented the same way on Windows as they are on traditional UNIX systems. (See acl(5) for a discussion of how permissions are implemented.) In addition, the root user has powers on a traditional UNIX system that are not automatically assigned to any one user on Windows.
All computers served by a single security access database form a domain. (Every Windows or Windows 2000 computer also has its own domain for local administration.) Different domains can have users with the same login name. The combination domain\username is unique on a network: the user represented by DEV\chris is not the user represented by ADMIN\chris. The Windows idiom for specifying a domain and a user name is domain\username. Interix utilities return domain+username, but will accept any of the following forms where a user name would usually go:
Appropriate privileges are typically required for actions such as file-system access, for certain process control actions (sending signals to other processes), and for changing the effective user identifier (ID) or group ID of a process in such a way that it changes the ability of the process to perform certain actions.
The calls associated most often with appropriate privileges are setuid(2) and setgid(2) (and their variants), and chroot(2).
The following privileges allow a user to act as the traditional superuser for different calls:
| Call | Windows privilege |
|---|---|
| chgrp() | SE_BACKUP, SE_RESTORE |
| chmod() | SE_BACKUP, SE_RESTORE |
| chown() | SE_BACKUP, SE_RESTORE |
| chroot() | SID of SYSTEM, local+Administrator or pdomain+Administrator |
| kill() | SE_SECURITY_NAME or SE_TCB_NAME |
| SE_SECURITY_NAME | |
| set*[gu]id() | SID of SYSTEM or {local,pdomain}+Administrator |
Most of the calls rely on Windows privileges associated with the calling process, but the set*id() calls rely on the Windows security ID of the calling function; pdomain is the principal domain of the system. This might change in a future release.
The privileges to perform certain actions overlap with the permissions to perform actions. (See acl(5) for a discussion of mapping Windows discretionary access control lists to permissions.)
acl(5)