user_attr(4)							   File Formats 						      user_attr(4)

NAME

       user_attr - extended user attributes database

SYNOPSIS

       /etc/user_attr

DESCRIPTION

       /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)
       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 passwd(4).

       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:

       user:qualifier:res1:res2:attr

       user

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

       qualifier

	   Reserved for future use.

       res1

	   Reserved for future use.

       res2

	   Reserved for future use.

       attr

	   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:

	   auths

	       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.

	   profiles

	       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 policy.conf(4)). If no pro-
	       files are assigned, the profile shells do not allow the user to execute any commands.

	   roles

	       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.

	   type

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

	   project

	       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 getdefaultproj(3PROJECT).

	   defaultpriv

	       The default set of privileges assigned to a user's inheritable set upon login.

	   limitpriv

	       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 abil-
	       ity of crippling all applications; removing any other privilege can cause many or all applications requiring privileges to malfunc-
	       tion.

	       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.

	   lock_after_retries

	       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.

       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.

EXAMPLES

       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:

       root::::auths=solaris.*,solaris.grant;profiles=All;type=normal

       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 authorizations.

FILES

       /etc/nsswitch.conf

	   See nsswitch.conf(4).

       /etc/user_attr

	   Described here.

ATTRIBUTES

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

       +-----------------------------+-----------------------------+
       |      ATTRIBUTE TYPE	     |	    ATTRIBUTE VALUE	   |
       +-----------------------------+-----------------------------+
       |Interface Stability	     |Evolving			   |
       +-----------------------------+-----------------------------+

SEE ALSO

       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), nsswitch.conf(4),  passwd(4),  policy.conf(4),	prof_attr(4),  project(4),
       attributes(5), privileges(5)

NOTES

       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 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 (
), equals (=), or backslash ().

SunOS 5.10							    16 Mar 2004 						      user_attr(4)