user_attr man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]

USER_ATTR(4)							  USER_ATTR(4)

       user_attr - extended user attributes database


       /etc/user_attr is a local source of extended attributes associated with
       users and roles. user_attr  can	be  used  with	other  user  attribute
       sources,	 including  the	 LDAP people container, the user_attr NIS map,
       and the user_attr NIS+ table. Programs use the getuserattr(3SECDB) rou‐
       tines to gain access to this information.

       The  search  order  for	multiple user_attr sources is specified in the
       /etc/nsswitch.conf file, as described in the nsswitch.conf(4) man page.
       The search order follows that for passwd(4).

       Each  entry  in	the user_attr databases consists of a single line with
       five fields separated by colons (:). Line continuations using the back‐
       slash (\) character are permitted. Each entry has the form:



	   The name of the user as specified in the passwd(4) database.


	   Reserved for future use.


	   Reserved for future use.


	   Reserved for future use.


	   An  optional	 list  of semicolon-separated (;) key-value pairs that
	   describe the security attributes to apply to the object upon execu‐
	   tion.  Zero	or  more keys may be specified. The following keys are
	   currently interpreted by the system:


	       Specifies a comma-separated list of authorization names	chosen
	       from  those  names defined in the auth_attr(4) database. Autho‐
	       rization names may be specified using the asterisk (*)  charac‐
	       ter  as a wildcard. For example, solaris.printer.* means all of
	       Sun's printer authorizations.


	       Contains an ordered, comma-separated list of profile names cho‐
	       sen  from  prof_attr(4).	 Profiles  are enforced by the profile
	       shells, pfcsh, pfksh, and pfsh. See pfsh(1). A default  profile
	       is  assigned in /etc/security/policy.conf (see policy.conf(4)).
	       If no profiles are assigned, the profile shells	do  not	 allow
	       the user to execute any commands.


	       Can  be	assigned a comma-separated list of role names from the
	       set of user accounts in this database whose  type  field	 indi‐
	       cates  the  account  is	a  role. If the roles key value is not
	       specified, the user is not permitted to assume any role.


	       Can be assigned one of these strings: normal,  indicating  that
	       this  account  is  for a normal user, one who logs in; or role,
	       indicating that this account is for a role. Roles can  only  be
	       assumed by a normal user after the user has logged in.


	       Can be assigned a name of one project from the project(4) data‐
	       base to be used as a default project to place the  user	in  at
	       login time. For more information, see getdefaultproj(3PROJECT).


	       The  default set of privileges assigned to a user's inheritable
	       set upon login.	See "Privileges Keywords," below.


	       The maximum set of privileges a user or any process started  by
	       the  user,  whether  through  su(1M)  or	 any  other means, can
	       obtain. The system administrator must take  extreme  care  when
	       removing	 privileges  from  the	limit  set. Removing any basic
	       privilege has the ability of crippling all applications; remov‐
	       ing  any	 other	privilege  can	cause many or all applications
	       requiring privileges to malfunction. See "Privileges Keywords,"


	       Specifies  whether  an  account	is  locked  after the count of
	       failed logins for a user equals or exceeds the  allowed	number
	       of  retries as defined by RETRIES in /etc/default/login. Possi‐
	       ble values are yes or no. The default is no. Account locking is
	       applicable only to local accounts.

	   The	following  keys are available only if the system is configured
	   with the Trusted Extensions feature:


	       Contains a number representing the maximum number of minutes  a
	       workstation  can	 remain idle before the Trusted Extensions CDE
	       window manager attempts the task specified in idlecmd.  A  zero
	       in  this field specifies that the idlecmd command is never exe‐
	       cuted. If unspecified, the default idletime of 30 minutes is in


	       Contains	 one  of  two keywords that the Trusted Extensions CDE
	       window manager interprets when a workstation is	idle  for  too
	       long.  The keyword lock specifies that the workstation is to be
	       locked (thus requiring the user to  re-authenticate  to	resume
	       the  session).  The keyword logout specifies that session is to
	       be terminated (thus, killing the user's processes  launched  in
	       the  current session). If unspecified, the default value, lock,
	       is in effect.


	       Contains the maximum label at which the user  can  operate.  If
	       unspecified, in the Defense Intelligence Agency (DIA) encodings
	       scheme, the default is  specified  in  label_encodings(4)  (see
	       label_encodings(4)  and labels(5) in the Solaris Trusted Exten‐
	       sions Reference Manual).


	       Contains the minimum label at which the user  can  log  in.  If
	       unspecified, in the DIA encodings scheme, the default is speci‐
	       fied  in	  label_encodings(4)   (see   label_encodings(4)   and
	       labels(5) in the Solaris Trusted Extensions Reference Manual).

       Except  for the type key, the key=value fields in /etc/user_attr can be
       added using roleadd(1M) and useradd(1M). You can	 use  rolemod(1M)  and
       usermod(1M)  to modify key=value fields in /etc/user_attr. Modification
       of the type key is restricted as described in rolemod and usermod.

   Privileges Keywords
       The defaultpriv and limitpriv are the privileges-related	 keywords  and
       are described above.

       See privileges(5) for a description of privileges. The command ppriv -l
       (see ppriv(1)) produces a list of all supported privileges.  Note  that
       you  specify  privileges	 as  they  are	displayed  by ppriv. In privi‐
       leges(5), privileges are listed in the form PRIV_<privilege_name>.  For
       example,	  the  privilege  file_chown,  as  you	would  specify	it  in
       user_attr, is listed in privileges(5) as PRIV_FILE_CHOWN.

       Privileges  are	specified  through  the	 Solaris  Management   Console
       (smc(1M)),  the recommended method, or, on the command line, for users,
       throughusermod(1M). See usermod(1M) for examples of commands that  mod‐
       ify privileges and their subsequent effect on user_attr.

       Example 1 Assigning a Profile to Root

       The  following  example	entry  assigns	to root the All profile, which
       allows root to use all commands in the system,  and  also  assigns  two


       The  solaris.*  wildcard	 authorization	shown above gives root all the
       solaris authorizations; and the solaris.grant authorization gives  root
       the  right to grant to others any solaris authorizations that root has.
       The combination of authorizations enables root to grant to  others  all
       the  solaris authorizations. See auth_attr(4) for more about authoriza‐


	   See nsswitch.conf(4).


	   Described here.

       See attributes(5) for descriptions of the following attributes:

       │Availibility	    │ SUNWcsr	      │
       │Interface Stability │ See below	      │

       The command-line syntax is Committed. The output is Uncommitted.

       auths(1), pfcsh(1), pfksh(1), pfsh(1), ppriv(1), profiles(1), roles(1),
       roleadd(1M),   rolemod(1M),   useradd(1M),   usermod(1M),   getdefault‐
       proj(3PROJECT), getuserattr(3SECDB), auth_attr(4),  exec_attr(4),  nss‐
       witch.conf(4),  passwd(4),  policy.conf(4),  prof_attr(4),  project(4),
       attributes(5), privileges(5)

       See the dtstyle(1X), label_encodings(4), and labels(5) man pages in the
       Solaris Trusted Extensions Reference Manual.

       System Administration Guide: Security Services

       When  deciding  which authorization source to use, if you are not using
       LDAP, keep in mind that NIS+ provides stronger authentication than NIS.

       The root user is usually defined in local databases  for	 a  number  of
       reasons, including the fact that root needs to be able to log in and do
       system maintenance in single-user mode, before the network name service
       databases  are  available.  For	this reason, an entry should exist for
       root in the local user_attr file, and the precedence shown in the exam‐
       ple nsswitch.conf(4) file entry under EXAMPLES is highly recommended.

       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.

       In the attr field, escape the following symbols with a backslash (\) if
       you use them in any value: colon (:), semicolon	(;),  carriage	return
       (\n), equals (=), or backslash (\).

				 Dec 12, 2008			  USER_ATTR(4)

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net