USER_ATTR(4)USER_ATTR(4)NAMEuser_attr - extended user attributes database
/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, the user_attr NIS map,
and the user_attr NIS+ table. Programs use the getuserattr(3SECDB) rou‐
tines 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 back‐
slash (\) character are permitted. Each entry has the form:
The name of the user as specified in the passwd(4) database.
Reserved for future use.
Reserved for future use.
Reserved for future use.
An optional list of semicolon-separated (;) key-value pairs that
describe the security attributes to apply to the object upon execu‐
tion. Zero or more keys may be specified. The following keys are
currently interpreted by the system:
Specifies a comma-separated list of authorization names chosen
from those names defined in the auth_attr(4) database. Autho‐
rization names may be specified using the asterisk (*) charac‐
ter as a wildcard. For example, solaris.printer.* means all of
Sun's printer authorizations.
Contains an ordered, comma-separated list of profile names cho‐
sen from prof_attr(4). Profiles are enforced by the profile
shells, pfcsh, pfksh, and pfsh. See pfsh(1). A default profile
is assigned in /etc/security/policy.conf (see policy.conf(4)).
If no profiles are assigned, the profile shells do not allow
the user to execute any commands.
Can be assigned a comma-separated list of role names from the
set of user accounts in this database whose type field indi‐
cates the account is a role. If the roles key value is not
specified, the user is not permitted to assume any role.
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.
Can be assigned a name of one project from the project(4) data‐
base to be used as a default project to place the user in at
login time. For more information, see getdefaultproj(3PROJECT).
The default set of privileges assigned to a user's inheritable
set upon login. See "Privileges Keywords," below.
The maximum set of privileges a user or any process started by
the user, whether through su(1M) or any other means, can
obtain. The system administrator must take extreme care when
removing privileges from the limit set. Removing any basic
privilege has the ability of crippling all applications; remov‐
ing any other privilege can cause many or all applications
requiring privileges to malfunction. See "Privileges Keywords,"
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. Possi‐
ble values are yes or no. The default is no. Account locking is
applicable only to local accounts.
The following keys are available only if the system is configured
with the Trusted Extensions feature:
Contains a number representing the maximum number of minutes a
workstation can remain idle before the Trusted Extensions CDE
window manager attempts the task specified in idlecmd. A zero
in this field specifies that the idlecmd command is never exe‐
cuted. If unspecified, the default idletime of 30 minutes is in
Contains one of two keywords that the Trusted Extensions CDE
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.
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) (see
label_encodings(4) and labels(5) in the Solaris Trusted Exten‐
sions Reference Manual).
Contains the minimum label at which the user can log in. If
unspecified, in the DIA encodings scheme, the default is speci‐
fied in label_encodings(4) (see label_encodings(4) and
labels(5) in the Solaris Trusted Extensions Reference Manual).
Except for the type key, the key=value fields in /etc/user_attr can be
added using roleadd(1M) and useradd(1M). You can use rolemod(1M) and
usermod(1M) to modify key=value fields in /etc/user_attr. Modification
of the type key is restricted as described in rolemod and usermod.
The defaultpriv and limitpriv are the privileges-related keywords and
are described above.
See privileges(5) for a description of privileges. The command ppriv -l
(see ppriv(1)) produces a list of all supported privileges. Note that
you specify privileges as they are displayed by ppriv. In privi‐
leges(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 are specified through the Solaris Management Console
(smc(1M)), the recommended method, or, on the command line, for users,
throughusermod(1M). See usermod(1M) for examples of commands that mod‐
ify privileges and their subsequent effect on user_attr.
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 two
The solaris.* wildcard authorization shown above gives root all the
solaris authorizations; and the solaris.grant authorization gives root
the right to grant to others any solaris authorizations that root has.
The combination of authorizations enables root to grant to others all
the solaris authorizations. See auth_attr(4) for more about authoriza‐
See attributes(5) for descriptions of the following attributes:
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
│Availibility │ SUNWcsr │
│Interface Stability │ See below │
The command-line syntax is Committed. The output is Uncommitted.
SEE ALSOauths(1), pfcsh(1), pfksh(1), pfsh(1), ppriv(1), profiles(1), roles(1),
roleadd(1M), rolemod(1M), useradd(1M), usermod(1M), getdefault‐
proj(3PROJECT), getuserattr(3SECDB), auth_attr(4), exec_attr(4), nss‐
witch.conf(4), passwd(4), policy.conf(4), prof_attr(4), project(4),
See the dtstyle(1X), label_encodings(4), and labels(5) man pages in the
Solaris Trusted Extensions Reference Manual.
System Administration Guide: Security Services
When deciding which authorization source to use, if you are not using
LDAP, keep in mind that NIS+ provides stronger authentication than NIS.
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 exam‐
ple 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.
In the attr field, escape the following symbols with a backslash (\) if
you use them in any value: colon (:), semicolon (;), carriage return
(\n), equals (=), or backslash (\).
Dec 12, 2008 USER_ATTR(4)