Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Apropos / Subsearch:
optional field

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

                       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 applica-
                                tions 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  authoriza-
                       tion.  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  inter-
                       ested  in  using  it.  The long description can be dis-
                       played 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.

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

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