user_attr(4) File Formats user_attr(4)NAMEuser_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, 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:
user:qualifier:res1:res2:attr
user The name of the user as specified in the passwd(4) data‐
base.
qualifier Reserved for future use.
res1 Reserved for future use.
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 may be speci‐
fied. The following keys are currently interpreted by the
system:
auths Specifies a comma-separated list of
authorization names chosen from
those names defined in the
auth_attr(4) database. Authorization
names may be specified using the
asterisk (*) character as a wild‐
card. For example, solaris.printer.*
means all of Sun's printer autho‐
rizations.
profiles Contains an ordered, comma-separated
list of profile names chosen 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/secu‐
rity/policy.conf (see pol‐
icy.conf(4)). If no profiles are
assigned, the profile shells do not
allow the user to execute any com‐
mands.
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 per‐
mitted 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 nor‐
mal user after the user has logged
in.
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 getdefault‐
proj(3PROJECT).
defaultpriv The default set of privileges
assigned to a user's inheritable set
upon login. See "Privileges Key‐
words," below.
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. The system admin‐
istrator must take extreme care when
removing privileges from the limit
set. Removing any basic privilege
has the ability of crippling all
applications; removing any other
privilege can cause many or all
applications requiring privileges to
malfunction. See "Privileges Key‐
words," below.
lock_after_retries 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.
Account locking is applicable only
to local accounts and accounts in
the ldap name service repository if
configured with an enableShadowUp‐
date of true as specified in ldap‐
client(1M).
The following keys are available only if the system is
configured with the Trusted Extensions feature:
idletime 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 executed. If
unspecified, the default idletime of 30 min‐
utes is in effect.
idlecmd Contains one of two keywords that the Trusted
Extensions CDE window manager interprets when
a workstation is idle for too long. The key‐
word lock specifies that the workstation is
to be locked (thus requiring the user to re-
authenticate to resume the session). The key‐
word logout specifies that session is to be
terminated (thus, killing the user's pro‐
cesses launched in the current session). If
unspecified, the default value, lock, is in
effect.
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_encod‐
ings(4) (see label_encodings(4) and labels(5)
in the Solaris Trusted Extensions Reference
Manual).
min_label Contains the minimum label at which the user
can log in. If unspecified, in the DIA encod‐
ings scheme, the default is specified in
label_encodings(4) (see label_encodings(4)
and labels(5) in the Solaris Trusted Exten‐
sions 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.
Privileges Keywords
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.
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 two
authorizations:
root::::auths=solaris.*,solaris.grant;profiles=All;type=normal
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‐
tions.
FILES
/etc/nsswitch.conf See nsswitch.conf(4).
/etc/user_attr Described here.
ATTRIBUTES
See attributes(5) for descriptions of the following attributes:
┌─────────────────────────────┬─────────────────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├─────────────────────────────┼─────────────────────────────┤
│Availibility │SUNWcsr │
├─────────────────────────────┼─────────────────────────────┤
│Interface Stability │See below │
└─────────────────────────────┴─────────────────────────────┘
The command-line syntax is Evolving. The output is Unstable.
SEE ALSOauths(1), pfcsh(1), pfksh(1), pfsh(1), ppriv(1), profiles(1), roles(1),
ldapclient(1M), roleadd(1M), rolemod(1M), useradd(1M), usermod(1M),
getdefaultproj(3PROJECT), getuserattr(3SECDB), auth_attr(4),
exec_attr(4), nsswitch.conf(4), passwd(4), policy.conf(4),
prof_attr(4), project(4), attributes(5), privileges(5)
See the dtstyle(1X), label_encodings(4), and labels(5) man pages in the
Solaris Trusted Extensions Reference Manual.
NOTES
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 (\).
SunOS 5.10 10 Jan 2011 user_attr(4)
