Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
auth_attr(4)			 File Formats			  auth_attr(4)

       auth_attr - authorization description database


       /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 information.

       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  cer-
       tain  privileged	 programs  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 for-
       mat of each entry is:


       name  The  name	of  the	 authorization.	Authorization names are	unique
	     strings. Construct	authorization names using the  following  con-

	     prefix. or	prefix.suffix

		   Everything  in  the	name  field  up	 to the	final dot (.).
		   Authorizations 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.xyzcompany).	 Prefixes  can
		   have	 additional  arbitrary components chosen by the	autho-
		   rization's developer, with components separated by dots.

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

		   When	 there is no suffix, the name is defined as a heading.
		   Headings 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
	     authorization. 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.

	     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.

	     A long description. This field can	explain	the precise purpose of
	     the  authorization, 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

       Example 1: Constructing a Name

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

       Example 2: Defining a Heading

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

       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	autho-
       rization	entries. The entries below the heading provide separate	autho-
       rizations  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:


       With the	above authorizations, the administrator	can assign  to	others
       the   solaris.admin.printer.delete,  solaris.admin.printer.modify,  and     authorizations,	  but	  not	   the
       solaris.login.enable  authorization.  If	the administrator has both the
       grant authorization,  solaris.admin.printmgr.grant,  and	 the  wildcard
       authorization, 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	autho-
       rizations 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 authorization	created	with a solaris prefix, when the	admin-
       istrator	also has either	the specific 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 Ta-

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

       auth_attr:files nisplus




       getauthattr(3SECDB), getexecattr(3SECDB), getprofattr(3SECDB), getuser-
       attr(3SECDB), exec_attr(4), nsswitch.conf(4), user_attr(4)

       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.9			  9 Jan	2002			  auth_attr(4)


Want to link to this manual page? Use this URL:

home | help