Tribblix: manual page: user

USER_ATTR(5) File Formats and Configurations 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(3SECDB) 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.

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 specified. 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(5) database.
Authorization names may be specified using the asterisk (*)
character as a wildcard. For example, solaris.printer.* means
all of Sun's printer authorizations.

profiles

Contains an ordered, comma-separated list of profile names
chosen from prof_attr(5). 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(5)). If no profiles are assigned, the profile
shells do not allow the user to execute any commands.

roleauth

Specifies whether a user assuming a role is required to use
the role password or their own password. If the roleauth key
value is not specified, the role password is required for
users assuming the role.

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.

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

defaultpriv

The default set of privileges assigned to a user's
inheritable set upon login. See "Privileges Keywords,"
below.

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. 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;
removing any other privilege can cause many or all
applications requiring privileges to malfunction. See
"Privileges Keywords," 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.

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) (see label_encodings(5) and labels(7) 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 encodings scheme, the default is
specified in label_encodings(5) (see label_encodings(5) and
labels(7) 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(8) and useradd(8). You can use rolemod(8) and
usermod(8) 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(7) 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
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.

See usermod(8) for examples of commands that modify 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(5) for more
about authorizations.

FILES

/etc/nsswitch.conf

See nsswitch.conf(5).

/etc/user_attr

Described here.

ATTRIBUTES

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.

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

October 1, 2020 USER_ATTR(5)