USER_ATTR(5) | File Formats and Configurations | USER_ATTR(5) |
user_attr - extended user attributes database
/etc/user_attr
/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
qualifier
res1
res2
attr
auths
profiles
roleauth
roles
type
project
defaultpriv
limitpriv
lock_after_retries
The following keys are available only if the system is configured with the Trusted Extensions feature:
clearance
min_label
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.
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.
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.
/etc/nsswitch.conf
/etc/user_attr
See attributes(7) 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.
auths(1), pfcsh(1), pfksh(1), pfsh(1), ppriv(1), profiles(1), roles(1), getdefaultproj(3PROJECT), getuserattr(3SECDB), auth_attr(5), exec_attr(5), nsswitch.conf(5), passwd(5), policy.conf(5), prof_attr(5), project(5), attributes(7), privileges(7), roleadd(8), rolemod(8), useradd(8), usermod(8)
System Administration Guide: Security Services
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 | OmniOS |