Unix/Linux Go Back    

OpenSolaris 2009.06 - man page for user_attr (opensolaris section 4)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

user_attr(4)				   File Formats 			     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  con-
       tainer,	the  user_attr	NIS  map, and the user_attr NIS+ table. Programs use the getuser-
       attr(3SECDB) routines 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

       Each entry in the user_attr databases consists of a single line with five fields separated
       by  colons  (:).  Line continuations using the backslash (\) 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 execution. 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. Authorization names may be specified using
	       the asterisk (*) character as a wildcard. For example, solaris.printer.* means all
	       of Sun's printer authorizations.


	       Contains   an   ordered,   comma-separated  list  of  profile  names  chosen  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 pol-
	       icy.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 indicates 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) database to be used as a
	       default project to place the user in at login time. For more information, see get-


	       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 priv-
	       ilege  has the ability of crippling all applications; removing any other privilege
	       can cause many or all applications requiring privileges to malfunction. See "Priv-
	       ileges Keywords," below.


	       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.  Possible  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 executed. If unspecified, the default idletime of 30 minutes is in effect.


	       Contains one of two keywords that the Trusted Extensions CDE window manager inter-
	       prets 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
	       Extensions Reference Manual).


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

       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 role-
       mod 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 privileges(5), privileges  are  listed  in  the  form  PRIV_<privi-
       lege_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 exam-
       ples of commands that modify 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 authorizations:


       The  solaris.*  wildcard  authorization	shown above gives root all the solaris authoriza-
       tions; 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:

       |      ATTRIBUTE TYPE	     |	    ATTRIBUTE VALUE	   |
       |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), role-
       mod(1M),   useradd(1M),	 usermod(1M),	getdefaultproj(3PROJECT),    getuserattr(3SECDB),
       auth_attr(4),  exec_attr(4),  nsswitch.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 example nss-
       witch.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 (\).

SunOS 5.11				   12 Dec 2008				     user_attr(4)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums

All times are GMT -4. The time now is 09:31 PM.