Synopsis

user_attr

- extended user attributes database

/etc/user_attr

Description

/etc/user_attr is a local source of extended attributes associated with users and roles. user_attr can be used with other user attribute sources, including the LDAP people container and the user_attr NIS map. Programs use the getuserattr(3C) routines to gain access to this information.

The search order for multiple user_attr sources is specified in the /etc/nsswitch.conf file, as described in the nsswitch.conf(4) man page. The search order follows that for passwd(4).

Each entry in the user_attr databases consists of a single line with five fields separated by colons (:). Line continuations using the backslash (\) character are permitted. Each entry has the form:

user:qualifier:res1:res2:attr

user

The name of the user as specified in the passwd(4) database.

qualifier

Reserved for future use.

res1

The characters RO in this field indicate it is read only and not modifiable by the tools that update this database.

res2

Reserved for future use.

attr

An optional list of semicolon-separated (;) key-value pairs that describe the security attributes to apply to the object upon execution. Zero or more keys can be specified. The following keys are currently interpreted by the system:

audit_flags

Specifies per-user audit preselection flags as colon-separated always-audit-flags and never-audit-flags. As in, audit_flags=always-audit-flags:never-audit-flags. See audit_flags(5).

auths

Specifies a comma-separated list of authorization names chosen from those names defined in the auth_attr(4) database. Authorization names can be specified using the asterisk (*) character as a wildcard. For example, solaris.print.* means all of Oracle Solaris' printer authorizations.

All of the authorizations from profiles are available to the user.

defaultpriv

The default set of privileges assigned to a user's inheritable set upon login. See Privileges Keywords. An Extended Policy can be specified. privileges(5).

limitpriv

The maximum set of privileges a user or any process started by the user, whether through su(1M) or any other means, can obtain. See Privileges Keywords.

lock_after_retries

Either:

Specifies whether an account is locked after the count of failed logins for a user equals or exceeds the allowed number of retries as defined by RETRIES in /etc/default/login. Possible values are yes or no. The default is no.

Or:

Specifies the count of failed logins for a user. Possible values are 1 ... 15. Account locking is applicable only to local accounts and accounts in the ldap name service repository. LDAP account must be configured with an enableShadowUpdate of true as specified in ldapclient(1M).

pam_policy

Specifies the PAM policy to apply to a user. pam_policy must be either an absolute pathname to a pam.conf(4)-formatted file or the name of a pam.conf-formatted file located in /etc/security/pam_policy. See pam_user_policy(5) for more information.

profiles

Contains an ordered, comma-separated list of profile names chosen from prof_attr(4). Profiles are enforced by the profile shells. See pfexec(1). A list of profiles can also be defined in the /etc/security/policy.conf file. See policy.conf(4). If no profiles are assigned, the profile shells do not allow the user to execute any commands.

project

Can be assigned a name of one project from the project(4) database to be used as a default project to place the user in at login time. For more information, see getdefaultproj(3PROJECT).

roleauth

Specifies whether the assigned role requires a role password or the password of the user who is assuming the role.

Valid values are role and user. If roleauth is not specified, roleauth=role is implied.

roles

Can be assigned a comma-separated list of role names from the set of user accounts in this database whose type field indicates the account is a role. If the roles key value is not specified, the user is not permitted to assume any role.

type

Can be assigned one of these strings: normal, indicating that this account is for a normal user, one who logs in; or role, indicating that this account is for a role. Roles can only be assumed by a normal user after the user has logged in.

The following keys are available only if the system is configured with the Trusted Extensions feature:

clearance: Contains the maximum label at which the user can operate. If unspecified, in the Defense Intelligence Agency (DIA) encodings scheme, the default is specified in label_encodings(4).
idlecmd: Contains one of two keywords that the Trusted Extensions window manager interprets when a workstation is idle for too long. The keyword lock specifies that the workstation is to be locked (thus requiring the user to re-authenticate to resume the session). The keyword logout specifies that session is to be terminated (thus, killing the user's processes launched in the current session). If unspecified, the default value, lock, is in effect.
idletime: Contains a number representing the maximum number of minutes a workstation can remain idle before the Trusted Extensions window manager attempts the task specified in idlecmd. A zero in this field specifies that the idlecmd command is never executed. If no value is specified, the default idletime of 30 minutes is in effect.
min_label: Contains the minimum label at which the user can log in. If unspecified, in the DIA encodings scheme, the default is specified in label_encodings(4).

Except for the type key, the key=value fields in the user_attr database can be added using roleadd(1M) and useradd(1M). You can use rolemod(1M) and usermod(1M) to modify these values. Modification of the type key is restricted as described in rolemod and usermod.

The values assigned to the auths, roles, and profiles keywords are cumulative. To assign the values, /etc/user_attr is searched first, followed by each of the profiles, in order. The other keywords (audit_flags, project, defaultpriv, limitpriv, lock_after_retries, idletime, idlecmd, pam_policy, clearance and min_label) are first matched, meaning that /etc/user_attr is searched first, followed by each of the profiles, in order. Once a match is found that search is over.

Privileges Keywords

See privileges(5) for a description of privileges. The command ppriv -l (see ppriv(1)) produces a list of all supported privileges. You specify privileges as they are displayed by ppriv. In privileges(5), privileges are listed in the form PRIV_<privilege_name>. For example, the privilege file_chown, as you would specify it in user_attr, is listed in privileges(5) as PRIV_FILE_CHOWN.

Privileges can be specified through usermod(1M)and rolemod(1M). See usermod(1M) for examples of commands that modify privileges and their subsequent effect on user_attr.

The following authorizations are required to set the various keywords:

 audit_flags             solaris.audit.assign
auths                   solaris.auth.delegate/assign
clearance               solaris.label.delegate
defaultpriv             solaris.privilege.delegate/assign
idlecmd                 solaris.session.setpolicy
idletime                solaris.session.setpolicy
limitpriv               solaris.privilege.delegate/assign
lock_after_retries      solaris.account.setpolicy
min_label               solaris.label.delegate
pam_policy              solaris.account.setpolicy
profiles                solaris.profile.delegate/assign
project                 solaris.project.delegate/assign
roles                   solaris.role.delegate/assign

The solaris.auth.assign authorization allows an authorized user to grant any authorization to another user. The solaris.auth.delegate allows an authorized user to grant only the user's authorizations to another user. The same principle applies to roles, profiles, privileges, and project.

The clearance and min_label values can only be set based on the authorized user's label range. The defaultpriv and limitpriv values can only be set based on the authorized user's granted defaultpriv and limitpriv privileges.

Examples

Example 1 Assigning a Profile to Root

The following example entry assigns to root the All profile, which allows root to use all commands in the system, and also assigns all authorizations:

root::::auths=solaris.*;profiles=All;type=normal

The solaris.* wildcard authorization gives root all of the solaris authorizations. See auth_attr(4) for more about authorizations.

Files

/etc/nsswitch.conf: See nsswitch.conf(4).
/etc/user_attr: Locally added entries. The shipped header must remain intact.
/etc/user_attr.d/*: Entries added by package installation.

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	system/core-os
Interface Stability	See below.

The command-line syntax is Committed. The output is Uncommitted.

Notes

The root user is usually defined in local databases for a number of reasons, including the fact that root needs to be able to log in and do system maintenance in single-user mode, before the network name service databases are available. For this reason, an entry should exist for root in the local user_attr file, and the precedence shown in the example nsswitch.conf(4) file entry under EXAMPLES is highly recommended.

Because the list of legal keys is likely to expand, any code that parses this database must be written to ignore unknown key-value pairs without error. When any new keywords are created, the names should be prefixed with a unique string, such as the company's stock symbol, to avoid potential naming conflicts.

This file should not be edited. Values are changed using useradd(1M) and usermod(1M).

A user without an entry in user_attr gets the default values as defined in /etc/security/policy.conf.

Skip Navigation Links
Exit Print View
	man pages section 4: File Formats Oracle Solaris 11.1 Information Library