privileges(5)                                             privileges(5)

  privileges

  NAME

    privileges - discussion of permissions, security, and accounts on Interix

  DESCRIPTION

    The Windows security model may hold some surprises. For one thing, users
    and groups share the same name space in the Security Access database,
    rather than groups and users being separate.

    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/group 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.

  DOMAINS AND USER NAMES

    All computers served by a single security access database form a domain.
    (Every Windows-based 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:

    *     domain\username
    *     domain/username
    *     domain:username
    *     domain+username

  THE SUPERUSER

    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

    renamewtmpx()     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.)

  SEE ALSO

    acl(5)