xref: /titanic_41/usr/src/man/man1/roles.1 (revision 7535ae1914017b0e648abd7a139aca709fa82be3)
te
Copyright (c) 2001, Sun Microsystems, Inc. All Rights Reserved
The contents of this file are subject to the terms of the Common Development and Distribution License (the "License"). You may not use this file except in compliance with the License.
You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific language governing permissions and limitations under the License.
When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright owner]
ROLES 1 "Feb 14, 2001"
NAME
roles - print roles granted to a user
SYNOPSIS

roles [ user ]...
DESCRIPTION

The command roles prints on standard output the roles that you or the optionally-specified user have been granted. Roles are special accounts that correspond to a functional responsibility rather than to an actual person (referred to as a normal user).

Each user may have zero or more roles. Roles have most of the attributes of normal users and are identified like normal users in passwd(4) and shadow(4). Each role must have an entry in the user_attr(4) file that identifies it as a role. Roles can have their own authorizations and profiles. See auths(1) and profiles(1).

Roles are not allowed to log into a system as a primary user. Instead, a user must log in as him\(em or herself and assume the role. The actions of a role are attributable to the normal user. When auditing is enabled, the audited events of the role contain the audit ID of the original user who assumed the role.

A role may not assume itself or any other role. Roles are not hierarchical. However, rights profiles (see prof_attr(4)) are hierarchical and can be used to achieve the same effect as hierarchical roles.

Roles must have valid passwords and one of the shells that interprets profiles: either pfcsh, pfksh, or pfsh. See pfexec(1).

Role assumption may be performed using su(1M), rlogin(1), or some other service that supports the PAM_RUSER variable. Successful assumption requires knowledge of the role's password and membership in the role. Role assignments are specified in user_attr(4).

EXAMPLES

Example 1 Sample output

The output of the roles command has the following form:

example% roles tester01 tester02tester01 : admin
tester02 : secadmin, root
example%
EXIT STATUS

The following exit values are returned: 0

Successful completion.

1

An error occurred.

FILES

/etc/user_attr

/etc/security/auth_attr

/etc/security/prof_attr

SEE ALSO

auths(1), pfexec(1), profiles(1), rlogin(1), su(1M), getauusernam(3BSM), auth_attr(4), passwd(4), prof_attr(4), shadow(4), user_attr(4), attributes(5)