Unix/Linux Go Back    


OpenSolaris 2009.06 - man page for auth_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)


auth_attr(4)				   File Formats 			     auth_attr(4)

NAME
       auth_attr - authorization description database

SYNOPSIS
       /etc/security/auth_attr

DESCRIPTION
       /etc/security/auth_attr	is  a  local source for authorization names and descriptions. The
       auth_attr file can be used with other authorization sources, including the  auth_attr  NIS
       map  and NIS+ table. Programs use the getauthattr(3SECDB) routines to access this informa-
       tion.

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

       An  authorization  is a right assigned to users that is checked by certain privileged pro-
       grams to determine whether users can execute restricted functionality. Each entry  in  the
       auth_attr  database consists of one line of text containing six fields separated by colons
       (:). Line continuations using the backslash (\) character are  permitted.  The  format  of
       each entry is:

	 name:res1:res2:short_desc:long_desc:attr

       name	     The  name of the authorization. Authorization names are unique strings. Con-
		     struct authorization names using the following convention:

		     prefix. or prefix.suffix

		     prefix    Everything in the name field up to the final dot  (.).  Authoriza-
			       tions  from  Sun  Microsystems,	Inc.  use solaris as a prefix. To
			       avoid name conflicts, all other authorizations should use a prefix
			       that  begins  with  the	reverse-order Internet domain name of the
			       organization that creates the authorization (for example, com.xyz-
			       company). Prefixes can have additional arbitrary components chosen
			       by the authorization's developer,  with	components  separated  by
			       dots.

		     suffix    The  final  component  in  the name field. Specifies what is being
			       authorized.

			       When there is no suffix, the name is defined as a  heading.  Head-
			       ings  are  not  assigned  to  users but are constructed for use by
			       applications in their GUIs.

		     When a name ends with the word grant, the entry defines a	grant  authoriza-
		     tion.  Grant  authorizations  are	used  to support fine-grained delegation.
		     Users with appropriate grant  authorizations  can	delegate  some	of  their
		     authorizations to others. To assign an authorization, the user needs to have
		     both the authorization itself and the appropriate grant authorization.

       res1	     Reserved for future use.

       res2	     Reserved for future use.

       short_desc    A short description or terse name for the authorization. This name should be
		     suitable for displaying in user interfaces, such as in a scrolling list in a
		     GUI.

       long_desc     A long description. This field can explain the precise purpose of the autho-
		     rization,	the  applications  in which it is used, and the type of user that
		     would be interested in using it. The long description can	be  displayed  in
		     the help text of an application.

       attr	     An  optional  list  of semicolon-separated (;) key-value pairs that describe
		     the attributes of an authorization. Zero or more keys may be specified.  The
		     keyword help identifies a help file in HTML.

EXAMPLES
       Example 1 Constructing a Name

       In the following example, the name has a prefix (solaris.admin.usermgr) followed by a suf-
       fix (read):

	 solaris.admin.usermgr.read

       Example 2 Defining a Heading

       Because the name field ends with a dot, the following entry defines a heading:

	 solaris.admin.usermgr.:::User Accounts::help=AuthUsermgrHeader.html

       Example 3 Assigning Separate Authorizations to Set User Attributes

       In this example, a heading entry is followed by other  associated  authorization  entries.
       The entries below the heading provide separate authorizations for setting user attributes.
       The attr field for each entry, including the heading  entry,  assigns  a  help  file.  The
       application  that  uses the help key requires the value to equal the name of a file ending
       in .htm or .html:

	 solaris.admin.usermgr.:::User Accounts::help=AuthUsermgrHeader.html
	 solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html
	 solaris.admin.usermgr.write:::Manage Users::help=AuthUsermgrWrite.html

       Example 4 Assigning a Grant Authorization

       This example assigns to an administrator the following authorizations:

	 solaris.admin.printer.grant
	 solaris.admin.printer.delete
	 solaris.admin.printer.modify
	 solaris.admin.printer.read
	 solaris.login.enable

       With  the  above  authorizations,   the	 administrator	 can   assign	to   others   the
       solaris.admin.printer.delete, solaris.admin.printer.modify, and solaris.admin.printer.read
       authorizations, but not the solaris.login.enable authorization. If the  administrator  has
       both  the  grant  authorization, solaris.admin.printmgr.grant, and the wildcard authoriza-
       tion, solaris.admin.printmgr.*, the administrator can grant to others any of  the  printer
       authorizations.	See  user_attr(4) for more information about how wildcards can be used to
       assign multiple authorizations whose names begin with the same components.

       Example 5 Authorizing the Ability to Assign Other Authorizations

       The following entry defines an authorization that grants the ability to assign any  autho-
       rization  created  with	a solaris prefix, when the administrator also has either the spe-
       cific authorization being granted or a matching wildcard entry:

	 solaris.grant:::Grant All Solaris Authorizations::help=PriAdmin.html

       Example 6 Consulting the Local Authorization File Ahead of the NIS Table

       With the following entry from /etc/nsswitch.conf, the local auth_attr  file  is	consulted
       before the NIS table:

	 auth_attr:files nisplus

FILES
       /etc/nsswitch.conf

       /etc/user_attr

       /etc/security/auth_attr

SEE ALSO
       getauthattr(3SECDB),    getexecattr(3SECDB),   getprofattr(3SECDB),   getuserattr(3SECDB),
       exec_attr(4), nsswitch.conf(4), user_attr(4)

NOTES
       When deciding which authorization source to use, keep in mind that NIS+ provides  stronger
       authentication than NIS.

       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.

       Each application has its own requirements for whether the help value must  be  a  relative
       pathname  ending  with a filename or the name of a file. The only known requirement is for
       the name of a file.

       The following characters are used in describing the database format and	must  be  escaped
       with a backslash if used as data: colon (:), semicolon (;), equals (=), and backslash (\).

SunOS 5.11				    9 Jan 2002				     auth_attr(4)
Unix & Linux Commands & Man Pages : ©2000 - 2017 Unix and Linux Forums


All times are GMT -4. The time now is 11:52 PM.