Go to main content

man pages section 5: File Formats

Exit Print View

Updated: Thursday, March 14, 2019
 
 

user_attr (5)

Name

user_attr - extended user attributes database

Synopsis

/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(5) man page. The search order follows that for passwd(5).

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(5) database.

The special value default@ is used to specify default attributes. It is only interpreted by the LDAP name service.

qualifier

An optional field specifying a hostname or a netgroup name which qualifies where the extended attributes are applicable. The prefix @ is required to indicate that the value is a netgroup. This field is only interpreted by the LDAP name service, in which case the user or role may be assigned multiple user_attr entries. The precedence for retrieving a user's entry is to first look for the user's entry which explicitly matches the current hostname, then to look for the user's entry with a netgroup name matching the current hostname. An unqualified entry has the lowest precedence.

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:

access_times

One or more comma-separated rules that specify the days and times that the corresponding set of applications and services can be accessed. An asterisk is treated as a wildcard, which matches any service name. When evaluating the access_times for a specific service, if no entries are found then the user is exempt from time restrictions for that service. The syntax is:

{<service>,...}:<days><start>-<end>[/<days><start>-<end>...
[,{<service>,...}:<days><start>-<end>]...

Lists of one or more service names are enclosed in curly braces, followed by the corresponding time policy. The valid days are specified by a sequence of undelimited two character entries from the set:

Mo Tu We Th Fr Sa Su Wk Wd Al

The last three indicating the weekdays, the weekend and all 7 days to the week, respectively. The time-range is two 24-hour times HHMM, separated by a hyphen, indicating the start and end times. Generally, one range can be specified per day. However, an end time less than the start time applies to the following day.

Multiple specifications of days and times are separated by a slash. Multiple sets of rules are separated by a comma.

access_tz

Specifies the time zone that should be used when interpreting the times specified in access_times entries. If the access_tz value is not set, then the systems's default time zone, local time is used. The valid time zones are listed under /usr/share/lib/zoneinfo.

annotation

Specifies whether a user is prompted for an audit record annotation description. yes requires the user to provide an annotation description when prompted. optional allows the user to specify an annotation description when prompted. no will not prompt the user for an annotation description, and is the default choice.

An audit record annotation description is a text line terminated by a newline returned by the application's PAM conversation function. The annotation text is included in each audit record generated by the user.

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

auths

Specifies a comma-separated list of authorization names chosen from those names defined in the auth_attr(5) 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.

auth_profiles

Similar to the profiles keyword, except that the user must re-authenticate prior to execution if PRIV_PFEXEC is enabled and the command matches an entry in this list of profiles. Entries in this list take precedence over the list specified using the profiles keyword.

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 and idlecmd should be assigned together.

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. idletime and idlecmd should be assigned together.

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

limitpriv

The maximum set of privileges a user or any process started by the user, whether through su(8) 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(8).

unlock_after

Specifies the time since the account has been locked, that it may be unlocked by a successful authentication. The time may be specified as a number of minutes (m), hours (h), days (d), or weeks (w). <n>[m | h | d | w]. The default is unspecified. An administrator must unlock the account.

pam_policy

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

profiles

Contains an ordered, comma-separated list of profile names chosen from prof_attr(5). The process attributes of commands included in this list of profiles are applied via exec(2) if the process flag PRIV_PFEXEC is enabled. For more information, see the pfexec(1) man page.

A list of profiles can also be defined in the /etc/security/policy.conf file. For more information, see the policy.conf(5) man page. 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(5) 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.

tpd

Specifies whether the user is granted access to the Trusted Path Domain when remotely connecting to a Remote Access Daemon using the SMF service svc:/system/rad:remote. For more information, see the tpd(7) and rad(8) man pages. 'yes' means preserve the Trusted Path. The default value, 'no', means run outside of the Trusted Path. This attribute only applies if the remote service is running in an immutable zone and the trusted_path property is enabled in its SMF start method.

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

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

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

The values assigned to the access_times, auths, auth_profiles, 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, access_tz, 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(7) 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(7), 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(7) as PRIV_FILE_CHOWN.

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

The following authorizations are required to set the various keywords:

access_times
solaris.account.setpolicy
access_tz
solaris.account.setpolicy
annotation
solaris.account.setpolicy
audit_flags
solaris.audit.assign
auths
solaris.auth.delegate/assign
auth_profiles
solaris.profile.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
roleauth
solaris.account.setpolicy

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(5) for more about authorizations.

Example 2 Specifying the Time Rules for PAM Services

The following example entry specifies the days and times when specific PAM services are available to a user:

jdoe::::access_tz=US/Pacific;access_times={pfexec,sudo}\:\

MoWe0900-1730/Sa2200-0200,{*}\:Wk0800-2200;auth_profiles=\

File System Management;

The user jdoe is restricted to use the File System Management profile or to use sudo (8) on Mondays and Wednesdays between 9:00 AM and 5:30 PM, and from 10 PM on Saturdays until 2 AM the following morning. All other PAM services are available on weekdays from 8 AM to 10 PM. These times are all interpreted using the US/Pacific time zone.

Although the colon character must be escaped with a backslash in the user_attr entry, the backslash is not used with the administrative interfaces, e.g. usermod(8) and profiles(1). However, quotes are required to prevent the shell from interpreting other special characters like asterisk, braces, and blanks.

The above entry could have been created using the following commands:

# usermod -K access_tz=US/Pacific jdoe
# usermod -K access_times='{*}:Wk0800-2200' jdoe
# usermod -K access_times+='{pfexec,sudo}:MoWe0900-1730/Sa2200-0200' jdoe
# usermod -K auth_profiles='File System Management' jdoe

Files

/etc/nsswitch.conf

See nsswitch.conf(5).

/etc/user_attr

Locally added entries. The shipped header must remain intact.

/etc/user_attr.d/*

Entries added by package installation.

Attributes

See attributes(7) 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.

See Also

auths(1), pfexec(1), ppriv(1), profiles(1), roles(1), userattr(1), getuserattr(3C), getdefaultproj(3PROJECT), auth_attr(5), exec_attr(5), label_encodings(5), nsswitch.conf(5), pam.conf(5), passwd(5), policy.conf(5), prof_attr(5), project(5), attributes(7), audit_flags(7), pam_user_policy(7), privileges(7), getent(8), ldapclient(8), roleadd(8), rolemod(8), useradd(8), usermod(8)

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(5) 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(8) and usermod(8).

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