auth_attr man page on OpenIndiana

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

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.  Programs use the getau‐
       thattr(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:res1:res2:short_desc:long_desc:attr

       name	     The name of the authorization.  Authorization  names  are
		     unique  strings.  Construct authorization names using the
		     following convention:

		     prefix. or prefix.suffix

		     prefix    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  authoriza‐
			       tion's  developer, with components separated by
			       dots.

		     suffix    The final component in the name	field.	Speci‐
			       fies 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 autho‐
		     rizations 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 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 HTML.

EXAMPLES
       Example 1 Constructing a Name

       In the following example, the name has a prefix (solaris.admin.usermgr)
       followed by a suffix (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 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:

	 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
       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‐
       ble

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

	 auth_attr:files nis

FILES
       /etc/nsswitch.conf

       /etc/user_attr

       /etc/security/auth_attr

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

NOTES
       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			  10 Dec 2009			  auth_attr(4)
[top]

List of man pages available for OpenIndiana

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]
Tweet
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