svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
auth_attr(5)
auth_attr(5) File Formats auth_attr(5)
NAME
auth_attr - authorization description database
SYNOPSIS
/etc/security/auth_attr
/etc/security/auth_attr.d/package
DESCRIPTION
/etc/security/auth_attr is a local source for authorization names and
descriptions. The auth_attr file can be used with other authorization
sources, including the auth_attr NIS map. Programs use the getau‐
thattr(3C) routines to access this information.
/etc/security/auth_attr entries are locally managed by the system ad‐
ministrator. The /etc/security/auth_attr.d directory contains addi‐
tional entries installed by packages which should not be locally modi‐
fied. If an entry appears in multiple files in these locations,
/etc/security/auth_attr takes precedence. The auths(1) command may be
used to verify the active definition for an authorization.
The search order for multiple authorization sources is specified in the
nsswitch.conf(5) man page.
An authorization is a right assigned to users that is checked by cer‐
tain privileged programs to determine whether users can execute re‐
stricted functionality. Each entry in the auth_attr database consists
of one line of text containing six fields separated by colons (:). Line
continuations using the backslash (\) character are permitted. The for‐
mat of each entry is:
name:res1:res2:short_desc:long_desc:attr
name The name of the authorization. Authorization names are
unique strings. Construct authorization names using the
following convention:
prefix. or prefix.suffix
prefix Everything in the name field up to the final
dot (.). Authorizations from Oracle Solaris use
solaris as a prefix. To avoid name conflicts,
all other authorizations should use a prefix
that begins with the reverse-order Internet do‐
main name of the organization that creates the
authorization (for example, com.xyzcompany).
Prefixes can have additional arbitrary compo‐
nents chosen by the authorization's developer,
with components separated by dots.
suffix The final component in the name field. Speci‐
fies what is being authorized.
When there is no suffix, the name is defined as
a heading. Headings are not assigned to users
but are constructed for use by applications in
their GUIs.
To assign an authorization, the user needs to have both
the authorization itself and the solaris.auth.delegate
authorization.
res1 The characters RO in this field indicate it is read only
and not modifiable by the tools that update this data‐
base.
res2 Reserved for future use.
short_desc A short description or terse name for the authorization.
This name should be suitable for displaying in user in‐
terfaces, such as in a scrolling list in a GUI.
long_desc A long description. This field can explain the precise
purpose of the authorization, the applications in which
it is used, and the type of user that would be interested
in using it. The long description can be displayed in the
help text of an application.
attr An optional list of semicolon-separated (;) key-value
pairs that describe the attributes of an authorization.
Zero or more keys can be specified.
EXAMPLES
Example 1 Constructing a Name
In the following example, the name has a prefix (solaris.admin.usermgr)
followed by a suffix (read):
solaris.admin.usermgr.read
Example 2 Defining a Heading
Because the name field ends with a dot, the following entry defines a
heading:
solaris.user.:::User Accounts::
Example 3 Assigning Separate Authorizations to Set User Attributes
In this example, a heading entry is followed by other associated autho‐
rization entries. The entries below the heading provide separate autho‐
rizations for setting user attributes.
solaris.role.:::Role Accounts::
solaris.role.manage:::Manage Role Accounts::
solaris.role.delegate:::Delegate Role Accounts::
Example 4 Assigning a Grant Authorization
This example assigns to an administrator the following authorizations:
solaris.auth.delegate
solaris.user.manage
solaris.role.manage
With the above authorizations, the administrator can assign to others
the solaris.user.manage and solaris.role.manage authorizations, but not
any other authorization. If the administrator has both the so‐
laris.auth.delegate and the solaris.*.manage authorization, it would be
equivalent to the above authorizations. See user_attr(5) for more in‐
formation about how wildcards can be used to assign multiple authoriza‐
tions whose names have the same components.
Example 5 Authorizing the Ability to Assign Other Authorizations
The following entry defines an authorization that grants the ability to
assign any authorization.
solaris.auth.assign:::Grant All Solaris Authorizations::
Example 6 Consulting the Local Authorization File Ahead of LDAP
With the following entry from /etc/nsswitch.conf, the local auth_attr
file is consulted before the LDAP name service:
auth_attr:files ldap
FILES
/etc/security/auth_attr
Locally added entries.
/etc/security/auth_attr.d/*
Entries added by package installation.
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
TRIBUTE VALUE _ AvailabilitySee below. _ Interface StabilitySee below.
Availability
/etc/security/auth_attr is delivered in the system/core-os package.
/etc/security/auth_attr.d/ files are delivered in the packages that
provide the software they are associated with.
Interface Stability
The format is Committed. The contents have no stability attributes.
SEE ALSO
auths(1), getauthattr(3C), getexecattr(3C), getprofattr(3C), getuser‐
attr(3C), exec_attr(5), nsswitch.conf(5), user_attr(5), rbac(7)
NOTES
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.
The following characters are used in describing the database format and
must be escaped with a backslash if used as data: colon (:), semicolon
(;), equals (=), and backslash (\).
The authorization required to add/modify/delete authorizations is so‐
laris.auth.manage. The solaris.auth.assign authorization allows an au‐
thorized user to grant any authorization to a user. The so‐
laris.auth.delegate allows an authorized user to grant only the user's
authorizations to another user.
HISTORY
Support for /etc/security/auth_attr.d/ files was added in Oracle So‐
laris 11.0.0.
/etc/security/auth_attr was added in Solaris 8.
Oracle Solaris 11.4 21 Jun 2021 auth_attr(5)