1user_attr(4) File Formats user_attr(4)
2
6 user_attr - extended user attributes database
7
9 /etc/user_attr
10
13 /etc/user_attr is a local source of extended attributes associated with
14 users and roles. user_attr can be used with other user attribute
15 sources, including the LDAP people container, the user_attr NIS map,
16 and the user_attr NIS+ table. Programs use the getuserattr(3SECDB) rou‐
17 tines to gain access to this information.
18 The search order for multiple user_attr sources is specified in the
21 /etc/nsswitch.conf file, as described in the nsswitch.conf(4) man page.
22 The search order follows that for passwd(4).
23 Each entry in the user_attr databases consists of a single line with
26 five fields separated by colons (:). Line continuations using the back‐
27 slash (\) character are permitted. Each entry has the form:
28 user:qualifier:res1:res2:attr
30 user
33 The name of the user as specified in the passwd(4) database.
35 qualifier
38 Reserved for future use.
40 res1
43 Reserved for future use.
45 res2
48 Reserved for future use.
50 attr
53 An optional list of semicolon-separated (;) key-value pairs that
55 describe the security attributes to apply to the object upon execu‐
56 tion. Zero or more keys may be specified. The following keys are
57 currently interpreted by the system:
58 auths
60 Specifies a comma-separated list of authorization names chosen
62 from those names defined in the auth_attr(4) database. Autho‐
63 rization names may be specified using the asterisk (*) charac‐
64 ter as a wildcard. For example, solaris.printer.* means all of
65 Sun's printer authorizations.
66 profiles
69 Contains an ordered, comma-separated list of profile names cho‐
71 sen from prof_attr(4). Profiles are enforced by the profile
72 shells, pfcsh, pfksh, and pfsh. See pfsh(1). A default profile
73 is assigned in /etc/security/policy.conf (see policy.conf(4)).
74 If no profiles are assigned, the profile shells do not allow
75 the user to execute any commands.
76 roles
79 Can be assigned a comma-separated list of role names from the
81 set of user accounts in this database whose type field indi‐
82 cates the account is a role. If the roles key value is not
83 specified, the user is not permitted to assume any role.
84 type
87 Can be assigned one of these strings: normal, indicating that
89 this account is for a normal user, one who logs in; or role,
90 indicating that this account is for a role. Roles can only be
91 assumed by a normal user after the user has logged in.
92 project
95 Can be assigned a name of one project from the project(4) data‐
97 base to be used as a default project to place the user in at
98 login time. For more information, see getdefaultproj(3PROJECT).
99 defaultpriv
102 The default set of privileges assigned to a user's inheritable
104 set upon login. See "Privileges Keywords," below.
105 limitpriv
108 The maximum set of privileges a user or any process started by
110 the user, whether through su(1M) or any other means, can
111 obtain. The system administrator must take extreme care when
112 removing privileges from the limit set. Removing any basic
113 privilege has the ability of crippling all applications; remov‐
114 ing any other privilege can cause many or all applications
115 requiring privileges to malfunction. See "Privileges Keywords,"
116 below.
117 lock_after_retries
120 Specifies whether an account is locked after the count of
122 failed logins for a user equals or exceeds the allowed number
123 of retries as defined by RETRIES in /etc/default/login. Possi‐
124 ble values are yes or no. The default is no. Account locking is
125 applicable only to local accounts.
126 The following keys are available only if the system is configured
128 with the Trusted Extensions feature:
129 idletime
131 Contains a number representing the maximum number of minutes a
133 workstation can remain idle before the Trusted Extensions CDE
134 window manager attempts the task specified in idlecmd. A zero
135 in this field specifies that the idlecmd command is never exe‐
136 cuted. If unspecified, the default idletime of 30 minutes is in
137 effect.
138 idlecmd
141 Contains one of two keywords that the Trusted Extensions CDE
143 window manager interprets when a workstation is idle for too
144 long. The keyword lock specifies that the workstation is to be
145 locked (thus requiring the user to re-authenticate to resume
146 the session). The keyword logout specifies that session is to
147 be terminated (thus, killing the user's processes launched in
148 the current session). If unspecified, the default value, lock,
149 is in effect.
150 clearance
153 Contains the maximum label at which the user can operate. If
155 unspecified, in the Defense Intelligence Agency (DIA) encodings
156 scheme, the default is specified in label_encodings(4) (see
157 label_encodings(4) and labels(5) in the Solaris Trusted Exten‐
158 sions Reference Manual).
159 min_label
162 Contains the minimum label at which the user can log in. If
164 unspecified, in the DIA encodings scheme, the default is speci‐
165 fied in label_encodings(4) (see label_encodings(4) and
166 labels(5) in the Solaris Trusted Extensions Reference Manual).
167 Except for the type key, the key=value fields in /etc/user_attr can be
172 added using roleadd(1M) and useradd(1M). You can use rolemod(1M) and
173 usermod(1M) to modify key=value fields in /etc/user_attr. Modification
174 of the type key is restricted as described in rolemod and usermod.
175 Privileges Keywords
177 The defaultpriv and limitpriv are the privileges-related keywords and
178 are described above.
179 See privileges(5) for a description of privileges. The command ppriv -l
182 (see ppriv(1)) produces a list of all supported privileges. Note that
183 you specify privileges as they are displayed by ppriv. In privi‐
184 leges(5), privileges are listed in the form PRIV_<privilege_name>. For
185 example, the privilege file_chown, as you would specify it in
186 user_attr, is listed in privileges(5) as PRIV_FILE_CHOWN.
187 Privileges are specified through the Solaris Management Console
190 (smc(1M)), the recommended method, or, on the command line, for users,
191 throughusermod(1M). See usermod(1M) for examples of commands that mod‐
192 ify privileges and their subsequent effect on user_attr.
193
195 Example 1 Assigning a Profile to Root
196 The following example entry assigns to root the All profile, which
199 allows root to use all commands in the system, and also assigns two
200 authorizations:
201 root::::auths=solaris.*,solaris.grant;profiles=All;type=normal
204 The solaris.* wildcard authorization shown above gives root all the
208 solaris authorizations; and the solaris.grant authorization gives root
209 the right to grant to others any solaris authorizations that root has.
210 The combination of authorizations enables root to grant to others all
211 the solaris authorizations. See auth_attr(4) for more about authoriza‐
212 tions.
213
216 /etc/nsswitch.conf
217 See nsswitch.conf(4).
219 /etc/user_attr
222 Described here.
224
227 See attributes(5) for descriptions of the following attributes:
228 ┌─────────────────────────────┬─────────────────────────────┐
233 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
234 ├─────────────────────────────┼─────────────────────────────┤
235 │Availibility │SUNWcsr │
236 ├─────────────────────────────┼─────────────────────────────┤
237 │Interface Stability │See below │
238 └─────────────────────────────┴─────────────────────────────┘
239 The command-line syntax is Committed. The output is Uncommitted.
242
244 auths(1), pfcsh(1), pfksh(1), pfsh(1), ppriv(1), profiles(1), roles(1),
245 roleadd(1M), rolemod(1M), useradd(1M), usermod(1M), getdefault‐
246 proj(3PROJECT), getuserattr(3SECDB), auth_attr(4), exec_attr(4), nss‐
247 witch.conf(4), passwd(4), policy.conf(4), prof_attr(4), project(4),
248 attributes(5), privileges(5)
249 See the dtstyle(1X), label_encodings(4), and labels(5) man pages in the
252 Solaris Trusted Extensions Reference Manual.
253 System Administration Guide: Security Services
256
258 When deciding which authorization source to use, if you are not using
259 LDAP, keep in mind that NIS+ provides stronger authentication than NIS.
260 The root user is usually defined in local databases for a number of
263 reasons, including the fact that root needs to be able to log in and do
264 system maintenance in single-user mode, before the network name service
265 databases are available. For this reason, an entry should exist for
266 root in the local user_attr file, and the precedence shown in the exam‐
267 ple nsswitch.conf(4) file entry under EXAMPLES is highly recommended.
268 Because the list of legal keys is likely to expand, any code that
271 parses this database must be written to ignore unknown key-value pairs
272 without error. When any new keywords are created, the names should be
273 prefixed with a unique string, such as the company's stock symbol, to
274 avoid potential naming conflicts.
275 In the attr field, escape the following symbols with a backslash (\) if
278 you use them in any value: colon (:), semicolon (;), carriage return
279 (\n), equals (=), or backslash (\).
280SunOS 5.11 12 Dec 2008 user_attr(4)