auth_attr(4) File Formats auth_attr(4)
auth_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 informa-
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 certain privileged pro-
grams 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 format of
each entry is:
name The name of the authorization. Authorization names are unique strings. Con-
struct authorization names using the following convention:
prefix. or prefix.suffix
prefix Everything in the name field up to the final dot (.). Authoriza-
tions 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.xyz-
company). Prefixes can have additional arbitrary components chosen
by the authorization's developer, with components separated by
suffix The final component in the name field. Specifies what is being
When there is no suffix, the name is defined as a heading. Head-
ings are not assigned to users but are constructed for use by
applications in their GUIs.
When a name ends with the word grant, the entry defines a grant authoriza-
tion. Grant authorizations are used to support fine-grained delegation.
Users with appropriate grant authorizations can delegate some of their
authorizations to others. To assign an authorization, the user needs to have
both the authorization itself and the appropriate grant authorization.
res1 Reserved for future use.
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 interfaces, such as in a scrolling list in a
long_desc A long description. This field can explain the precise purpose of the autho-
rization, 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 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 suf-
Example 2 Defining a Heading
Because the name field ends with a dot, the following entry defines a heading:
Example 3 Assigning Separate Authorizations to Set User Attributes
In this example, a heading entry is followed by other associated authorization entries.
The entries below the heading provide separate authorizations 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 authoriza-
tion, 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 authorizations 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 autho-
rization created with a solaris prefix, when the administrator also has either the spe-
cific 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 Table
With the following entry from /etc/nsswitch.conf, the local auth_attr file is consulted
before the NIS table:
getauthattr(3SECDB), getexecattr(3SECDB), getprofattr(3SECDB), getuserattr(3SECDB),
exec_attr(4), nsswitch.conf(4), user_attr(4)
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 (\).
SunOS 5.11 9 Jan 2002 auth_attr(4)