AUTH_ATTR(4)AUTH_ATTR(4)NAMEauth_attr - authorization description database
/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 and NIS+ table. Programs use
the getauthattr(3SECDB) routines to access this information.
The search order for multiple authorization sources is specified in the
/etc/nsswitch.conf file, as described in the nsswitch.conf(4) man page.
An authorization is a right assigned to users that is checked by cer‐
tain privileged programs to determine whether users can execute
restricted 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:
The name of the authorization. Authorization names are
unique strings. Construct authorization names using the
prefix. or prefix.suffix
Everything in the name field up to the final
dot (.). Authorizations from Sun Microsystems,
Inc. use solaris as a prefix. To avoid name
conflicts, all other authorizations should use
a prefix that begins with the reverse-order
Internet domain name of the organization that
creates the authorization (for example,
com.xyzcompany). Prefixes can have additional
arbitrary components chosen by the authoriza‐
tion's developer, with components separated by
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
When a name ends with the word grant, the entry defines a
grant authorization. Grant authorizations are used to
support fine-grained delegation. Users with appropriate
grant authorizations can delegate some of their autho‐
rizations to others. To assign an authorization, the user
needs to have both the authorization itself and the
appropriate grant authorization.
Reserved for future use.
Reserved for future use.
A short description or terse name for the authorization.
This name should be suitable for displaying in user
interfaces, such as in a scrolling list in a GUI.
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.
An optional list of semicolon-separated (;) key-value
pairs that describe the attributes of an authorization.
Zero or more keys may be specified. The keyword help
identifies a help file in HTML.
Example 1 Constructing a Name
In the following example, the name has a prefix (solaris.admin.usermgr)
followed by a suffix (read):
Example 2 Defining a Heading
Because the name field ends with a dot, the following entry defines a
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. The attr field for each entry,
including the heading entry, assigns a help file. The application that
uses the help key requires the value to equal the name of a file ending
in .htm or .html:
Example 4 Assigning a Grant Authorization
This example assigns to an administrator the following authorizations:
With the above authorizations, the administrator can assign to others
the solaris.admin.printer.delete, solaris.admin.printer.modify, and
solaris.admin.printer.read authorizations, but not the
solaris.login.enable authorization. If the administrator has both the
grant authorization, solaris.admin.printmgr.grant, and the wildcard
authorization, solaris.admin.printmgr.*, the administrator can grant to
others any of the printer authorizations. See user_attr(4) for more
information about how wildcards can be used to assign multiple autho‐
rizations whose names begin with 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 created with a solaris prefix, when the admin‐
istrator also has either the specific authorization being granted or a
matching wildcard entry:
solaris.grant:::Grant All Solaris Authorizations::help=PriAdmin.html
Example 6 Consulting the Local Authorization File Ahead of the NIS Ta‐
With the following entry from /etc/nsswitch.conf, the local auth_attr
file is consulted before the NIS table:
SEE ALSOgetauthattr(3SECDB), getexecattr(3SECDB), getprofattr(3SECDB), getuser‐
attr(3SECDB), exec_attr(4), nsswitch.conf(4), user_attr(4)NOTES
When deciding which authorization source to use, keep in mind that NIS+
provides stronger authentication than NIS.
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.
Each application has its own requirements for whether the help value
must be a relative pathname ending with a filename or the name of a
file. The only known requirement is for the name of a file.
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 (\).
Jan 9, 2002 AUTH_ATTR(4)