1auth_attr(4) File Formats auth_attr(4)
2
6 auth_attr - authorization description database
7
9 /etc/security/auth_attr
10
13 /etc/security/auth_attr is a local source for authorization names and
14 descriptions. The auth_attr file can be used with other authorization
15 sources, including the auth_attr NIS map and NIS+ table. Programs use
16 the getauthattr(3SECDB) routines to access this information.
17 The search order for multiple authorization sources is specified in the
20 /etc/nsswitch.conf file, as described in the nsswitch.conf(4) man page.
21 An authorization is a right assigned to users that is checked by cer‐
24 tain privileged programs to determine whether users can execute
25 restricted functionality. Each entry in the auth_attr database consists
26 of one line of text containing six fields separated by colons (:). Line
27 continuations using the backslash (\) character are permitted. The for‐
28 mat of each entry is:
29 name:res1:res2:short_desc:long_desc:attr
31 name The name of the authorization. Authorization names are
34 unique strings. Construct authorization names using the
35 following convention:
36 prefix. or prefix.suffix
38 prefix Everything in the name field up to the final
40 dot (.). Authorizations from Sun Microsystems,
41 Inc. use solaris as a prefix. To avoid name
42 conflicts, all other authorizations should use
43 a prefix that begins with the reverse-order
44 Internet domain name of the organization that
45 creates the authorization (for example,
46 com.xyzcompany). Prefixes can have additional
47 arbitrary components chosen by the authoriza‐
48 tion's developer, with components separated by
49 dots.
50 suffix The final component in the name field. Speci‐
53 fies what is being authorized.
54 When there is no suffix, the name is defined as
56 a heading. Headings are not assigned to users
57 but are constructed for use by applications in
58 their GUIs.
59 When a name ends with the word grant, the entry defines a
61 grant authorization. Grant authorizations are used to
62 support fine-grained delegation. Users with appropriate
63 grant authorizations can delegate some of their autho‐
64 rizations to others. To assign an authorization, the user
65 needs to have both the authorization itself and the
66 appropriate grant authorization.
67 res1 Reserved for future use.
70 res2 Reserved for future use.
73 short_desc A short description or terse name for the authorization.
76 This name should be suitable for displaying in user
77 interfaces, such as in a scrolling list in a GUI.
78 long_desc A long description. This field can explain the precise
81 purpose of the authorization, the applications in which
82 it is used, and the type of user that would be interested
83 in using it. The long description can be displayed in the
84 help text of an application.
85 attr An optional list of semicolon-separated (;) key-value
88 pairs that describe the attributes of an authorization.
89 Zero or more keys may be specified. The keyword help
90 identifies a help file in HTML.
91
94 Example 1 Constructing a Name
95 In the following example, the name has a prefix (solaris.admin.usermgr)
98 followed by a suffix (read):
99 solaris.admin.usermgr.read
102 Example 2 Defining a Heading
105 Because the name field ends with a dot, the following entry defines a
108 heading:
109 solaris.admin.usermgr.:::User Accounts::help=AuthUsermgrHeader.html
112 Example 3 Assigning Separate Authorizations to Set User Attributes
115 In this example, a heading entry is followed by other associated autho‐
118 rization entries. The entries below the heading provide separate autho‐
119 rizations for setting user attributes. The attr field for each entry,
120 including the heading entry, assigns a help file. The application that
121 uses the help key requires the value to equal the name of a file ending
122 in .htm or .html:
123 solaris.admin.usermgr.:::User Accounts::help=AuthUsermgrHeader.html
126 solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html
127 solaris.admin.usermgr.write:::Manage Users::help=AuthUsermgrWrite.html
128 Example 4 Assigning a Grant Authorization
131 This example assigns to an administrator the following authorizations:
134 solaris.admin.printer.grant
137 solaris.admin.printer.delete
138 solaris.admin.printer.modify
139 solaris.admin.printer.read
140 solaris.login.enable
141 With the above authorizations, the administrator can assign to others
145 the solaris.admin.printer.delete, solaris.admin.printer.modify, and
146 solaris.admin.printer.read authorizations, but not the
147 solaris.login.enable authorization. If the administrator has both the
148 grant authorization, solaris.admin.printmgr.grant, and the wildcard
149 authorization, solaris.admin.printmgr.*, the administrator can grant to
150 others any of the printer authorizations. See user_attr(4) for more
151 information about how wildcards can be used to assign multiple autho‐
152 rizations whose names begin with the same components.
153 Example 5 Authorizing the Ability to Assign Other Authorizations
156 The following entry defines an authorization that grants the ability to
159 assign any authorization created with a solaris prefix, when the admin‐
160 istrator also has either the specific authorization being granted or a
161 matching wildcard entry:
162 solaris.grant:::Grant All Solaris Authorizations::help=PriAdmin.html
165 Example 6 Consulting the Local Authorization File Ahead of the NIS Ta‐
168 ble
169 With the following entry from /etc/nsswitch.conf, the local auth_attr
172 file is consulted before the NIS table:
173 auth_attr:files nisplus
176
179 /etc/nsswitch.conf
180 /etc/user_attr
183 /etc/security/auth_attr
186
188 getauthattr(3SECDB), getexecattr(3SECDB), getprofattr(3SECDB), getuser‐
189 attr(3SECDB), exec_attr(4), nsswitch.conf(4), user_attr(4)
190
192 When deciding which authorization source to use, keep in mind that NIS+
193 provides stronger authentication than NIS.
194 Because the list of legal keys is likely to expand, any code that
197 parses this database must be written to ignore unknown key-value pairs
198 without error. When any new keywords are created, the names should be
199 prefixed with a unique string, such as the company's stock symbol, to
200 avoid potential naming conflicts.
201 Each application has its own requirements for whether the help value
204 must be a relative pathname ending with a filename or the name of a
205 file. The only known requirement is for the name of a file.
206 The following characters are used in describing the database format and
209 must be escaped with a backslash if used as data: colon (:), semicolon
210 (;), equals (=), and backslash (\).
211SunOS 5.11 9 Jan 2002 auth_attr(4)