1261 lines
73 KiB
HTML
1261 lines
73 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
|||
|
|
<!DOCTYPE html
|
|||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|||
|
|
<html lang="en-us" xml:lang="en-us">
|
|||
|
|
<head>
|
|||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|||
|
|
<meta name="security" content="public" />
|
|||
|
|
<meta name="Robots" content="index,follow" />
|
|||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
|||
|
|
<meta name="DC.Type" content="concept" />
|
|||
|
|
<meta name="DC.Title" content="Plan object authority" />
|
|||
|
|
<meta name="abstract" content="This information is helpful when planning object authority." />
|
|||
|
|
<meta name="description" content="This information is helpful when planning object authority." />
|
|||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvplanappsec.htm" />
|
|||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
|
|||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
|
|||
|
|
<meta name="DC.Format" content="XHTML" />
|
|||
|
|
<meta name="DC.Identifier" content="planobjauth" />
|
|||
|
|
<meta name="DC.Language" content="en-us" />
|
|||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
|||
|
|
<!-- US Government Users Restricted Rights -->
|
|||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
|||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
|||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
|||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
|||
|
|
<title>Plan object authority</title>
|
|||
|
|
</head>
|
|||
|
|
<body id="planobjauth"><a name="planobjauth"><!-- --></a>
|
|||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|||
|
|
<h1 class="topictitle1">Plan object authority</h1>
|
|||
|
|
<div><p>This information is helpful when planning object authority.</p>
|
|||
|
|
<p>Your challenge as security administrator is to protect your organization’s
|
|||
|
|
information assets without frustrating the users on your system. You need
|
|||
|
|
to make sure that users have enough authority to do their jobs without giving
|
|||
|
|
them the authority to browse throughout the system and to make unauthorized
|
|||
|
|
changes.</p>
|
|||
|
|
<p>The i5/OS™ operating
|
|||
|
|
system provides integrated object security. Users must use the interfaces
|
|||
|
|
that the system provides to access objects. For example, if you want to access
|
|||
|
|
a database file, you must use commands or programs that are intended for accessing
|
|||
|
|
database files. You cannot use a command that is intended for accessing a
|
|||
|
|
message queue or a job log. </p>
|
|||
|
|
<p>Whenever you use a system interface to access an object, the system verifies
|
|||
|
|
that you have the authority to the object that is required by that interface.
|
|||
|
|
Object authority is a powerful and flexible tool for protecting the assets
|
|||
|
|
on your system. Your challenge as a security administrator is to set up an
|
|||
|
|
effective object security scheme that you can manage and maintain.</p>
|
|||
|
|
<p><strong>Object authority enforcement</strong></p>
|
|||
|
|
<p>Whenever you try to access an object, the operating system checks your
|
|||
|
|
authority to that object. However, if the security level on your system (QSECURITY
|
|||
|
|
system value) is set to 10 or 20, every user automatically has authority to
|
|||
|
|
access every object because every user profile has *ALLOBJ special authority. </p>
|
|||
|
|
<p><strong>Object authority tip:</strong> If you are not sure whether you are using
|
|||
|
|
object security, check the QSECURITY (security level) system value. If QSECURITY
|
|||
|
|
is 10 or 20, you are not using object security. You must plan and prepare
|
|||
|
|
before you change to security level 30 or higher. Otherwise, your users may
|
|||
|
|
not be able to access the information that they need.</p>
|
|||
|
|
<p>Object authority to system commands and programs</p>
|
|||
|
|
<div class="p">Following are several suggestions when you restrict authority to IBM-supplied
|
|||
|
|
objects:<ul><li>When you have more than one national language on your system, your system
|
|||
|
|
has more than one system (QSYS) library. Your system has a QSYSxxxx library
|
|||
|
|
for each national language on your system. If you are using object authority
|
|||
|
|
to control access to system commands, remember to secure the command in the
|
|||
|
|
QSYS library and in every QSYSxxx library on your system.</li>
|
|||
|
|
<li>The System/38™ library sometimes provides a command with function that
|
|||
|
|
is equivalent to the commands that you want to restrict. Be sure you restrict
|
|||
|
|
the equivalent command in the QSYS38 library.</li>
|
|||
|
|
<li>If you have the System/36™ environment, you may need to restrict additional
|
|||
|
|
programs. For example, the QY2FTML program provides System/36™ file transfer.</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<p><strong>Grouping objects</strong></p>
|
|||
|
|
<p>After you have determined ownership of libraries and objects, you can begin
|
|||
|
|
grouping objects on the system. To simplify managing authorities, use an authorization
|
|||
|
|
list to group objects with the same requirements. You can then give the public,
|
|||
|
|
group profiles, and user profiles authority to the authorization list rather
|
|||
|
|
than to the individual objects on the list. The system treats every object
|
|||
|
|
that you secure by an authorization list the same, but you can give different
|
|||
|
|
users different authorities to the entire list. </p>
|
|||
|
|
<p>An authorization list makes it easier to reestablish authorities when you
|
|||
|
|
restore objects. If you secure objects with an authorization list, the restore
|
|||
|
|
process automatically links the objects to the list. You can give a group
|
|||
|
|
or user the authority to manage an authorization list (*AUTLMGT). Authorization
|
|||
|
|
list management allows the user to add and remove other users from the list
|
|||
|
|
and to change the authorities for those users. </p>
|
|||
|
|
<div class="p">Recommendations:<ul><li>Use authorization lists for objects that require security protection and
|
|||
|
|
that have similar security requirements. Using authorization lists encourages
|
|||
|
|
you to think about categories of authority rather than individual authorities.
|
|||
|
|
Authorization lists also make it easier to restore objects and to audit the
|
|||
|
|
authorities on your system.</li>
|
|||
|
|
<li>Avoid complicated schemes that combine authorization lists, group authority,
|
|||
|
|
and individual authority. Choose the method that best suits the requirement,
|
|||
|
|
rather than using all of the methods at the same time.</li>
|
|||
|
|
</ul>
|
|||
|
|
You will also need to add the naming convention for authorization lists
|
|||
|
|
to your Naming Conventions form. Once you have prepared an Authorization List
|
|||
|
|
form, go back and add that information to your Library Description form. Your
|
|||
|
|
programmer or application provider might have already created authorization
|
|||
|
|
lists. Be sure to check with them.</div>
|
|||
|
|
<p><strong>Defining how information can be accessed</strong></p>
|
|||
|
|
<div class="p">Authority means the type of access allowed to an object. Different operations
|
|||
|
|
require different types of authority. Note: In some environments, the authority
|
|||
|
|
associated with an object is called the object’s mode of access. Authority
|
|||
|
|
to an object is divided into three categories:<ol><li>Object Authority defines what operations can be performed on the object
|
|||
|
|
as a whole.</li>
|
|||
|
|
<li>Data Authority defines what operations can be performed on the contents
|
|||
|
|
of the object.</li>
|
|||
|
|
<li>Field Authority defines what operations can be performed on the data fields.</li>
|
|||
|
|
</ol>
|
|||
|
|
The following table describes the types of authority available and lists
|
|||
|
|
some examples of how the authorities are used. In most cases, accessing an
|
|||
|
|
object requires a combination of object, data, field authorities. Appendix
|
|||
|
|
D provides information about the authority that is required to perform a specific
|
|||
|
|
function.</div>
|
|||
|
|
|
|||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><div>Description of Authority Types</div><thead align="left"><tr valign="bottom"><th valign="bottom" id="d0e82">Authority</th>
|
|||
|
|
<th valign="bottom" id="d0e84">Name</th>
|
|||
|
|
<th valign="bottom" id="d0e86">Functions allowed</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody><tr><td colspan="3" valign="top" headers="d0e82 d0e84 d0e86 ">Object Authorities</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*OBJOPR</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Object Operational</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Look at the description of an object. Use the object
|
|||
|
|
as determined by the user’s data authorities.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*OBJMGT</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Object Management</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Specify the security for the object. Move or rename
|
|||
|
|
the object. All functions defined for *OBJALTER and *OBJREF.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*OBJEXIST</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Object Existence</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Delete the object. Free storage of the object. Perform
|
|||
|
|
save and restore operations for the object 1. Transfer ownership of the object.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*OBJALTER</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Object Alter</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Add, clear, initialize and reorganize members of the
|
|||
|
|
database files. Alter and add attributes of database files: add and remove
|
|||
|
|
triggers. Change the attributes of SQL packages.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*OBJREF</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Object Reference</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Specify a database file as the parent in a referential
|
|||
|
|
constraint. For example, you want to define a rule that a customer record
|
|||
|
|
must exist in the CUSMAS file before an order for the customer can be added
|
|||
|
|
to the CUSORD file. You need *OBJREF authority to the CUSMAS file to define
|
|||
|
|
this rule.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*AUTLMGT</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Authorization List Management</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Add and remove users and their authorities from the
|
|||
|
|
authorization list 2.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td colspan="3" valign="top" headers="d0e82 d0e84 d0e86 ">Data Authorities</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*READ</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Read</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Display the contents of the object, such as viewing
|
|||
|
|
records in a file.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*ADD</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Add</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Add entries to an object, such as adding messages to
|
|||
|
|
a message queue or adding records to a file.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*UPD</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Update</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Change the entries in an object, such as changing records
|
|||
|
|
in a file.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*DLT</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Delete</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Remove entries from an object, such as removing messages
|
|||
|
|
from a message queue or deleting records from a file.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*EXECUTE</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Execute</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Run a program, service program, or SQL package. Locate
|
|||
|
|
an object in a library or a directory.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td colspan="3" valign="top" headers="d0e82 d0e84 d0e86 ">Field Authorities</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*Mgt</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Management</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Specify the security for the field.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*Alter</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Alter</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Change the attributes of the field.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*Ref</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Reference</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Specify the field as a part of the parent key in a referential
|
|||
|
|
constraint</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*Read</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Read</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Access the contents of the field. For example, display
|
|||
|
|
the contents of the field.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*Add</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Add</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Add entries to data, such as adding information to a
|
|||
|
|
specific field.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e82 ">*Update</td>
|
|||
|
|
<td valign="top" headers="d0e84 ">Update</td>
|
|||
|
|
<td valign="top" headers="d0e86 ">Change the content of existing entries in the field.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td colspan="3" valign="top" headers="d0e82 d0e84 d0e86 "><p><sup>1</sup> If a user has save system
|
|||
|
|
(*SAVSYS) special authority, object existence authority is not required to
|
|||
|
|
perform save and restore operations on the object.</p>
|
|||
|
|
<p><sup>2</sup> See
|
|||
|
|
Authorization List Management for more information.</p>
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
<p><strong>Commonly used authorities</strong></p>
|
|||
|
|
<p>Certain sets of object and data authorities are commonly required to perform
|
|||
|
|
operations on objects. You can specify these system-defined sets of authority
|
|||
|
|
(*ALL, *CHANGE, *USE) instead of individually defining the authorities needed
|
|||
|
|
for an object. *EXCLUDE authority is different than having no authority. *EXCLUDE
|
|||
|
|
authority specifically denies access to the object. Having no authority means
|
|||
|
|
you use the public authority defined for the object. The following table shows
|
|||
|
|
the system-defined authorities available using the object authority commands
|
|||
|
|
and displays.</p>
|
|||
|
|
|
|||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><div>System-Defined Authority</div><thead align="left"><tr valign="bottom"><th valign="bottom" id="d0e243">Authority</th>
|
|||
|
|
<th valign="bottom" id="d0e245">*ALL</th>
|
|||
|
|
<th valign="bottom" id="d0e247">*CHANGE</th>
|
|||
|
|
<th valign="bottom" id="d0e249">*USE</th>
|
|||
|
|
<th valign="bottom" id="d0e251">*EXECUTE</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody><tr><td colspan="5" valign="top" headers="d0e243 d0e245 d0e247 d0e249 d0e251 ">Object Authorities</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e243 ">*OBJOPR</td>
|
|||
|
|
<td valign="top" headers="d0e245 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e247 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e249 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e251 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e243 ">*OBJMGT</td>
|
|||
|
|
<td valign="top" headers="d0e245 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e247 "> </td>
|
|||
|
|
<td valign="top" headers="d0e249 "> </td>
|
|||
|
|
<td valign="top" headers="d0e251 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e243 ">*OBJEXIST</td>
|
|||
|
|
<td valign="top" headers="d0e245 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e247 "> </td>
|
|||
|
|
<td valign="top" headers="d0e249 "> </td>
|
|||
|
|
<td valign="top" headers="d0e251 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e243 ">*OBJALTER</td>
|
|||
|
|
<td valign="top" headers="d0e245 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e247 "> </td>
|
|||
|
|
<td valign="top" headers="d0e249 "> </td>
|
|||
|
|
<td valign="top" headers="d0e251 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e243 ">*OBJREF</td>
|
|||
|
|
<td valign="top" headers="d0e245 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e247 "> </td>
|
|||
|
|
<td valign="top" headers="d0e249 "> </td>
|
|||
|
|
<td valign="top" headers="d0e251 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td colspan="5" valign="top" headers="d0e243 d0e245 d0e247 d0e249 d0e251 ">Data Authorities</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e243 ">*READ</td>
|
|||
|
|
<td valign="top" headers="d0e245 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e247 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e249 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e251 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e243 ">*ADD</td>
|
|||
|
|
<td valign="top" headers="d0e245 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e247 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e249 "> </td>
|
|||
|
|
<td valign="top" headers="d0e251 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e243 ">*UPD</td>
|
|||
|
|
<td valign="top" headers="d0e245 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e247 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e249 "> </td>
|
|||
|
|
<td valign="top" headers="d0e251 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e243 ">*DLT</td>
|
|||
|
|
<td valign="top" headers="d0e245 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e247 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e249 "> </td>
|
|||
|
|
<td valign="top" headers="d0e251 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e243 ">*EXECUTE</td>
|
|||
|
|
<td valign="top" headers="d0e245 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e247 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e249 ">X</td>
|
|||
|
|
<td valign="top" headers="d0e251 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
<p>The following table shows additional system-defined authorities that are
|
|||
|
|
available using the WRKAUT and CHGAUT commands.</p>
|
|||
|
|
|
|||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><div>System-Defined Authority</div><thead align="left"><tr valign="bottom"><th valign="bottom" width="20.14388489208633%" id="d0e364">Authority</th>
|
|||
|
|
<th valign="bottom" width="13.237410071942445%" id="d0e366">*RWX</th>
|
|||
|
|
<th valign="bottom" width="13.381294964028779%" id="d0e368">*RW</th>
|
|||
|
|
<th valign="bottom" width="13.237410071942445%" id="d0e370">*RX</th>
|
|||
|
|
<th valign="bottom" width="13.381294964028779%" id="d0e372">*R</th>
|
|||
|
|
<th valign="bottom" width="13.237410071942445%" id="d0e374">*WX</th>
|
|||
|
|
<th valign="bottom" width="13.381294964028779%" id="d0e376">*W</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody><tr><td colspan="7" valign="top" headers="d0e364 d0e366 d0e368 d0e370 d0e372 d0e374 d0e376 ">Object Authorities</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="20.14388489208633%" headers="d0e364 ">*OBJOPR</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e366 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e368 ">X</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e370 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e372 ">X</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e374 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e376 ">X</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="20.14388489208633%" headers="d0e364 ">*OBJMGT</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e366 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e368 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e370 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e372 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e374 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e376 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="20.14388489208633%" headers="d0e364 ">*OBJEXIST</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e366 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e368 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e370 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e372 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e374 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e376 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="20.14388489208633%" headers="d0e364 ">*OBJALTER</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e366 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e368 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e370 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e372 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e374 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e376 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="20.14388489208633%" headers="d0e364 ">*OBJREF</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e366 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e368 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e370 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e372 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e374 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e376 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td colspan="7" valign="top" headers="d0e364 d0e366 d0e368 d0e370 d0e372 d0e374 d0e376 ">Data Authorities</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="20.14388489208633%" headers="d0e364 ">*READ</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e366 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e368 ">X</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e370 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e372 ">X</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e374 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e376 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="20.14388489208633%" headers="d0e364 ">*ADD</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e366 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e368 ">X</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e370 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e372 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e374 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e376 ">X</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="20.14388489208633%" headers="d0e364 ">*UPD</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e366 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e368 ">X</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e370 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e372 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e374 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e376 ">X</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="20.14388489208633%" headers="d0e364 ">*DLT</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e366 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e368 ">X</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e370 "> </td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e372 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e374 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e376 ">X</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="20.14388489208633%" headers="d0e364 ">*EXECUTE</td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e366 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e368 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e370 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e372 "> </td>
|
|||
|
|
<td valign="top" width="13.237410071942445%" headers="d0e374 ">X</td>
|
|||
|
|
<td valign="top" width="13.381294964028779%" headers="d0e376 "> </td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
<p>The LAN Server licensed program uses access control lists to manage authority.
|
|||
|
|
A user’s authorities are called permissions. The following table shows how
|
|||
|
|
the LAN Server permissions map to object and data authorities.</p>
|
|||
|
|
|
|||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><div>LAN Server Permissions</div><thead align="left"><tr valign="bottom"><th valign="bottom" width="28.14070351758794%" id="d0e510">Authority</th>
|
|||
|
|
<th valign="bottom" width="71.85929648241206%" id="d0e512">LAN server permissions</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody><tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*EXCLUDE</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">None</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td colspan="2" valign="top" headers="d0e510 d0e512 ">Object authorities</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*OBJOPR</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">See note 1</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*OBJMGT</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">Permission</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*OBJEXIST</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">Create, Delete</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*OBJALTER</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">Attribute</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*OBJREF</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">No equivalent</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td colspan="2" valign="top" headers="d0e510 d0e512 ">Data authorities</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*READ</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">Read</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*ADD</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">Create</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*UPD</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">Write</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*DLT</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">Delete</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="28.14070351758794%" headers="d0e510 ">*EXECUTE</td>
|
|||
|
|
<td valign="top" width="71.85929648241206%" headers="d0e512 ">Execute</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td colspan="2" valign="top" headers="d0e510 d0e512 "><sup>1</sup> Unless NONE is specified
|
|||
|
|
for a user in the access control list, the user is implicitly given *OBJOPR.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
<p><strong>Defining what information can be accessed</strong></p>
|
|||
|
|
<div class="p">You can define resource security for individual objects on the system.
|
|||
|
|
You can also define security for groups of objects using either library security
|
|||
|
|
or an authorization list:<ul><li><strong>Library Security:</strong> <p>Most objects on the system reside in libraries.
|
|||
|
|
To access an object, you need authority both to the object itself and the
|
|||
|
|
library in which the object resides. For most operations, including deleting
|
|||
|
|
an object, *USE authority to the object library is sufficient (in addition
|
|||
|
|
to the authority required for the object). Creating a new object requires
|
|||
|
|
*ADD authority to the object library. Appendix D shows what authority is required
|
|||
|
|
by CL commands for objects and the object libraries.</p>
|
|||
|
|
<div class="p">Using library security
|
|||
|
|
is one technique for protecting information while maintaining a simple security
|
|||
|
|
scheme. For example, to secure confidential information for a set of applications,
|
|||
|
|
you could do the following:<ul><li>Use a library to store all confidential files for a particular group of
|
|||
|
|
applications.</li>
|
|||
|
|
<li>Ensure that public authority is sufficient for all objects (in the library)
|
|||
|
|
that are used by applications (*USE or *CHANGE).</li>
|
|||
|
|
<li>Restrict public authority to the library itself (*EXCLUDE).</li>
|
|||
|
|
<li>Give selected groups or individuals authority to the library (*USE, or
|
|||
|
|
*ADD if the applications require it).</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
Although library security is a simple, effective method for protecting
|
|||
|
|
information, it may not be adequate for data with high security requirements.
|
|||
|
|
Highly sensitive objects should be secured individually or with an authorization
|
|||
|
|
list, rather than relying on library security.</li>
|
|||
|
|
<li><strong>Library Security and Library Lists:</strong> <p>When a library is added
|
|||
|
|
to a user’s library list, the authority the user has to the library is stored
|
|||
|
|
with the library list information. The user’s authority to the library remains
|
|||
|
|
for the entire job, even if the user’s authority to the library is revoked
|
|||
|
|
while the job is active. </p>
|
|||
|
|
<p>When access is requested to an object and
|
|||
|
|
*LIBL is specified for the object, the library list information is used to
|
|||
|
|
check authority for the library. If a qualified name is specified, the authority
|
|||
|
|
for the library is specifically checked, even if the library is included in
|
|||
|
|
the user’s library list.</p>
|
|||
|
|
<p>If a user is running under adopted authority
|
|||
|
|
when a library is added to the library list, the user remains authorized to
|
|||
|
|
the library even when the user is no longer running under adopted authority.
|
|||
|
|
This represents a potential security exposure. Any entries added to a user’s
|
|||
|
|
library list by a program running under adopted authority should be removed
|
|||
|
|
before the adopted authority program ends.</p>
|
|||
|
|
In addition, applications that
|
|||
|
|
use library lists rather than qualified library names have a potential security
|
|||
|
|
exposure. A user who is authorized to the commands to work with library lists
|
|||
|
|
could potentially run a different version of a program. See Library Lists
|
|||
|
|
for more information.</li>
|
|||
|
|
<li><strong>Field Authorities:</strong><p>Field authorities are now supported for database
|
|||
|
|
files. Authorities supported are Reference and Update. You can only administer
|
|||
|
|
these authorities through the SQL statements, GRANT and REVOKE. You can display
|
|||
|
|
these authorities through the Display Object Authority (DSPOBJAUT) and the
|
|||
|
|
Edit Object Authority (EDTOBJAUT) commands. You can only display the field
|
|||
|
|
authorities with the EDTOBJAUT command; you cannot edit them.</p>
|
|||
|
|
<div class="p">Changes
|
|||
|
|
for field authorities include the following:<ul><li>The Print Private Authority (PRTPVTAUT) command has a new field that indicates
|
|||
|
|
when a file has field authorities.</li>
|
|||
|
|
<li>The Display Object Authority (DSPOBJAUT) command now has a new Authority
|
|||
|
|
Type parameter to allow display of object authorities, field authorities,
|
|||
|
|
or all authorities. If the object type is not *FILE, you can display only
|
|||
|
|
object authorities.</li>
|
|||
|
|
<li>Information provided by List Users Authorized to Object (QSYLUSRA) API
|
|||
|
|
now indicates if a file has field authorities.</li>
|
|||
|
|
<li>The Grant User Authority (GRTUSRAUT) command will not grant a user’s field
|
|||
|
|
authorities.</li>
|
|||
|
|
<li>When a grant with reference object is performed using the GRTOBJAUT command
|
|||
|
|
and both objects (the one being granted to and the referenced one) are database
|
|||
|
|
files, all field authorities will be granted where the field names match.</li>
|
|||
|
|
<li>If a user’s authority to a database file is removed, any field authorities
|
|||
|
|
for the user are also removed.</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
</li>
|
|||
|
|
<li><strong>Security and the System/38™ Environment:</strong> <p>The System/38 Environment
|
|||
|
|
and CL programs of type CLP38 represent a potential security exposure. When
|
|||
|
|
a non-library qualified command is entered from the System/38 Command Entry screen, or
|
|||
|
|
invoked by any CLP38 CL program, library QUSER38 (if it exists) is the first
|
|||
|
|
library searched for that command. Library QSYS38 is the second library searched.
|
|||
|
|
A programmer or other knowledgeable user could place another CL command in
|
|||
|
|
either of these libraries and cause that command to be used instead of one
|
|||
|
|
from a library in the library list. </p>
|
|||
|
|
<p>Library QUSER38 is not shipped
|
|||
|
|
with the operating system. However, it can be created by anyone with enough
|
|||
|
|
authority to create a library. See the System/38 Environment Programming manual
|
|||
|
|
for more information about the System/38 Environment.</p>
|
|||
|
|
<div class="p"><strong>Recommendation
|
|||
|
|
for System/38 Environment</strong>:
|
|||
|
|
Use these measures to protect your system for the System/38 Environment and CL programs
|
|||
|
|
of type CLP38:<ul><li>Check the public authority of the QSYS38 library and if it is *ALL or
|
|||
|
|
*CHANGE then change it to *USE.</li>
|
|||
|
|
<li>Check the public authority of the QUSER38 library and if it is *ALL or
|
|||
|
|
*CHANGE then change it to *USE.</li>
|
|||
|
|
<li>If the QUSER38 and QSYS38 do not exist then create them and set them to
|
|||
|
|
public *USE authority. This will prevent anyone else from creating it at a
|
|||
|
|
later time and giving themselves or the public too much authority to it.</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
</li>
|
|||
|
|
<li><strong>Directory Security:</strong><p>When accessing an object in a directory,
|
|||
|
|
you must have authority to all the directories in the path containing the
|
|||
|
|
object. You must also have the necessary authority to the object to perform
|
|||
|
|
the operation you requested. </p>
|
|||
|
|
<p>You may want to use directory security
|
|||
|
|
in the same way that you use library security. Limit access to directories
|
|||
|
|
and use public authority to the objects within the directory. Limiting the
|
|||
|
|
number of private authorities defined for objects improves the performance
|
|||
|
|
of the authority checking process.</p>
|
|||
|
|
</li>
|
|||
|
|
<li><strong>Authorization List Security:</strong> <p>You can group objects with similar
|
|||
|
|
security requirements using an authorization list. An authorization list,
|
|||
|
|
conceptually, contains a list of users and the authority that the users have
|
|||
|
|
to the objects secured by the list. Each user can have a different authority
|
|||
|
|
to the set of objects the list secures. When you give a user authority to
|
|||
|
|
the authorization list, the operating system actually grants a private authority
|
|||
|
|
for that user to the authorization list. </p>
|
|||
|
|
<p>You can also use an authorization
|
|||
|
|
list to define public authority for the objects on the list. If the public
|
|||
|
|
authority for an object is set to *AUTL, the object gets its public authority
|
|||
|
|
from its authorization list. </p>
|
|||
|
|
<p>The authorization list object is used
|
|||
|
|
as a management tool by the system. It actually contains a list of all objects
|
|||
|
|
which are secured by the authorization list. This information is used to build
|
|||
|
|
displays for viewing or editing the authorization list objects.</p>
|
|||
|
|
<p>You
|
|||
|
|
cannot use an authorization list to secure a user profile or another authorization
|
|||
|
|
list. Only one authorization list can be specified for an object. </p>
|
|||
|
|
<p>Only
|
|||
|
|
the owner of the object, a user with all object (*ALLOBJ) special authority,
|
|||
|
|
or a user with all (*ALL) authority to the object, can add or remove the authorization
|
|||
|
|
list for an object. Objects in the system library (QSYS) can be secured with
|
|||
|
|
an authorization list. However, the name of the authorization list that secures
|
|||
|
|
an object is stored with the object. </p>
|
|||
|
|
<p>In some cases, when you install
|
|||
|
|
a new release of the operating system, all the objects in the QSYS library
|
|||
|
|
are replaced. The association between the objects and your authorization list
|
|||
|
|
would be lost. See the topic Planning Authorization Lists for examples of
|
|||
|
|
how to use authorization lists.</p>
|
|||
|
|
<p><strong>Authorization List Management:</strong> You
|
|||
|
|
can grant a special operational authority called Authorization List Management
|
|||
|
|
(*AUTLMGT) for authorization lists. Users with *AUTLMGT authority are allowed
|
|||
|
|
to add and remove the users’ authority to the authorization list and change
|
|||
|
|
the authorities for those users. *AUTLMGT authority, by itself, does not give
|
|||
|
|
authority to secure new objects with the list or to remove objects from the
|
|||
|
|
list.</p>
|
|||
|
|
<p>A user with *AUTLMGT authority can give only the same or less
|
|||
|
|
authority to others. For example, assume USERA has *CHANGE and *AUTLMGT authority
|
|||
|
|
to authorization list CPLIST1. USERA can add USERB to CPLIST1 and give USERB
|
|||
|
|
*CHANGE authority or less. USERA cannot give USERB *ALL authority to CPLIST1,
|
|||
|
|
because USERA does not have *ALL authority. </p>
|
|||
|
|
<p>A user with *AUTLMGT authority
|
|||
|
|
can remove the authority for a user if the *AUTLMGT user has equal or greater
|
|||
|
|
authority to the list than the user profile name being removed. If USERC has
|
|||
|
|
*ALL authority to CPLIST1, then USERA cannot remove USERC from the list, because
|
|||
|
|
USERA has only *CHANGE and *AUTLMGT.</p>
|
|||
|
|
<p><strong>Using Authorization Lists to
|
|||
|
|
Secure IBM-Supplied Objects:</strong> You may choose to use an authorization list
|
|||
|
|
to secure IBM-supplied objects. For example, you may want to restrict the
|
|||
|
|
use of a group of commands to a few users. Objects in IBM-supplied libraries,
|
|||
|
|
other than the QUSRSYS and QGPL libraries, are replaced whenever you install
|
|||
|
|
a new release of the operating system. Therefore, the link between objects
|
|||
|
|
in IBM-supplied libraries and authorization lists is lost. Also, if an authorization
|
|||
|
|
list secures an object in QSYS and a complete system restore is required,
|
|||
|
|
the link between the objects in QSYS and the authorization list is lost. After
|
|||
|
|
you install a new release or restore your system, use the EDTOBJAUT or GRTOBJAUT
|
|||
|
|
command to re-establish the link between the IBM-supplied object and the authorization
|
|||
|
|
list. </p>
|
|||
|
|
<p>The Implementation Guide for AS/400<sup>®</sup> Security and Auditing redbook
|
|||
|
|
contains sample programs, such as ALLAUTL and FIXAUTL, that can be used to
|
|||
|
|
attach authorization lists to the objects after the authorization lists are
|
|||
|
|
restored.</p>
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<p><strong>Authority for new objects in a library</strong></p>
|
|||
|
|
<p>Every library has a parameter called CRTAUT (create authority). This parameter
|
|||
|
|
determines the default public authority for any new object that is created
|
|||
|
|
in that library. When you create an object, the AUT parameter on the create
|
|||
|
|
command determines the public authority for the object. If the AUT value on
|
|||
|
|
the create command is *LIBCRTAUT, which is the default, the public authority
|
|||
|
|
for the object is set to the CRTAUT value for the library. </p>
|
|||
|
|
<div class="p">For example, assume library CUSTLIB has a CRTAUT value of *USE. Both of
|
|||
|
|
the commands below create a data area called DTA1 with public authority *USE:<ul><li>Specifying the AUT parameter: <samp class="codeph">CRTDTAARA DTAARA(CUSTLIB/DTA1) +
|
|||
|
|
TYPE(*CHAR) AUT(*LIBCRTAUT)</samp></li>
|
|||
|
|
<li>Allowing the AUT parameter to default. *LIBCRTAUT is the default: <samp class="codeph">CRTDTAARA
|
|||
|
|
DTAARA(CUSTLIB/DTA1) + TYPE(*CHAR)</samp></li>
|
|||
|
|
</ul>
|
|||
|
|
The default CRTAUT value for a library is *SYSVAL. Any new objects created
|
|||
|
|
in the library using AUT(*LIBCRTAUT) have public authority set to the value
|
|||
|
|
of the QCRTAUT system value. The QCRTAUT system value is shipped as *CHANGE.
|
|||
|
|
For example, assume the ITEMLIB library has a CRTAUT value of *SYSVAL. This
|
|||
|
|
command creates the DTA2 data area with public authority of change: <samp class="codeph">CRTDTAARA
|
|||
|
|
DTAARA(ITEMLIB/DTA2) + TYPE(*CHAR) AUT(*LIBCRTAUT)</samp><div class="note"><span class="notetitle">Note:</span> Several IBM-supplied
|
|||
|
|
libraries, including QSYS, have a CRTAUT value of *SYSVAL. If you change QCRTAUT
|
|||
|
|
to something other than *CHANGE, you may encounter problems. For example,
|
|||
|
|
devices are created in the QSYS library. The default when creating devices
|
|||
|
|
is AUT(*LIBCRTAUT). <p>The CRTAUT value for the QSYS library is *SYSVAL. If
|
|||
|
|
QCRTAUT is set to *USE or *EXCLUDE, public authority is not sufficient to
|
|||
|
|
allow sign-on at new devices.</p>
|
|||
|
|
<p>The CRTAUT value for a library can also
|
|||
|
|
be set to an authorization list name. Any new object created in the library
|
|||
|
|
with AUT(*LIBCRTAUT) is secured by the authorization list. The public authority
|
|||
|
|
for the object is set to *AUTL. </p>
|
|||
|
|
<p>The CRTAUT value of the library is
|
|||
|
|
not used during a move (MOVOBJ), create duplicate (CRTDUPOBJ), or restore
|
|||
|
|
of an object into the library. The public authority of the existing object
|
|||
|
|
is used.</p>
|
|||
|
|
<p>If the REPLACE (*YES) parameter is used on the create command,
|
|||
|
|
then the authority of the existing object is used instead of the CRTAUT value
|
|||
|
|
of the library.</p>
|
|||
|
|
</div>
|
|||
|
|
<strong>Create Authority (CRTAUT) Risks:</strong> If your
|
|||
|
|
applications use default authority for new objects created during application
|
|||
|
|
processing, you should control who has authority to change the library descriptions.
|
|||
|
|
Changing the CRTAUT authority for an application library could allow unauthorized
|
|||
|
|
access to new objects created in the library.</div>
|
|||
|
|
<p><strong>Authority for new objects in a directory</strong></p>
|
|||
|
|
<p>When you create a new object in a directory using the CRTDIR, MD or MKDIR
|
|||
|
|
commands, you specify the data authority and object authority that the public
|
|||
|
|
receives for the object. If you use the *INDIR option, the authority for the
|
|||
|
|
created directory is determined from the directory it is being created in.
|
|||
|
|
Otherwise, you can specify the specific desired authority.</p>
|
|||
|
|
<p><strong>Objects that adopt the owner's authority</strong></p>
|
|||
|
|
<p>Sometimes a user needs different authorities to an object or an application,
|
|||
|
|
depending on the situation. For example, a user may be allowed to change the
|
|||
|
|
information in a customer file when using application programs providing that
|
|||
|
|
function. However, the same user should be allowed to view, but not change,
|
|||
|
|
customer information when using a decision support tool, such as SQL. </p>
|
|||
|
|
<p>A solution to this situation is 1) give the user *USE authority to customer
|
|||
|
|
information to allow querying the files and 2) use adopted authority in the
|
|||
|
|
customer maintenance programs to allow the user to change the files. </p>
|
|||
|
|
<p>When an object uses the owner’s authority, this is called adopted authority.
|
|||
|
|
Objects of type *PGM, *SRVPGM, *SQLPKG and Java™ programs can adopt authority. When
|
|||
|
|
you create a program, you specify a user profile (USRPRF) parameter on the
|
|||
|
|
CRTxxxPGM command. This parameter determines whether the program uses the
|
|||
|
|
authority of the owner of the program in addition to the authority of the
|
|||
|
|
user running the program.</p>
|
|||
|
|
<div class="p">The following applies to adopted authority:<ul><li>Adopted authority is added to any other authority found for the user. </li>
|
|||
|
|
<li>Adopted authority is checked only if the authority that the user, the
|
|||
|
|
user’s group, or the public has to an object is not adequate for the requested
|
|||
|
|
operation.</li>
|
|||
|
|
<li>The special authorities (such as *ALLOBJ) in the owner’s profile are used.</li>
|
|||
|
|
<li>If the owner profile is a member of a group profile, the group’s authority
|
|||
|
|
is not used for adopted authority.</li>
|
|||
|
|
<li>Public authority is not used for adopted authority. For example, USER1
|
|||
|
|
runs the program LSTCUST, which requires *USE authority to the CUSTMST file:<ul><li>Public authority to the CUSTMST file is *USE.</li>
|
|||
|
|
<li>USER1’s authority is *EXCLUDE.</li>
|
|||
|
|
<li>USER2 owns the LSTCUST program, which adopts owner authority.</li>
|
|||
|
|
<li>USER2 does not own the CUSTMST file and has no private authority to it. </li>
|
|||
|
|
<li>Although public authority is sufficient to give USER2 access to the CUSTMST
|
|||
|
|
file, USER1 does not get access. Owner authority, primary group authority,
|
|||
|
|
and private authority are used for adopted authority.</li>
|
|||
|
|
<li>Only the authority is adopted. No other user profile attributes are adopted.
|
|||
|
|
For example, the limited capabilities attributes are not adopted.</li>
|
|||
|
|
</ul>
|
|||
|
|
</li>
|
|||
|
|
<li>Adopted authority is active as long as the program using adopted authority
|
|||
|
|
remains in the program stack. For example, assume PGMA uses adopted authority:<ul><li>If PGMA starts PGMB using the CALL command, these are the program stacks
|
|||
|
|
before and after the CALL command:
|
|||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><div>Adopted Authority and the CALL
|
|||
|
|
Command</div><thead align="left"><tr valign="bottom"><th valign="bottom" id="d0e805">Program stack before CALL command</th>
|
|||
|
|
<th valign="bottom" id="d0e807">Program stack after CALL command</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody><tr><td valign="top" headers="d0e805 "><p>QCMD<br />
|
|||
|
|
.<br />
|
|||
|
|
.<br />
|
|||
|
|
.<br />
|
|||
|
|
PGMA</p>
|
|||
|
|
</td>
|
|||
|
|
<td valign="top" headers="d0e807 "><p>QCMD<br />
|
|||
|
|
.<br />
|
|||
|
|
.<br />
|
|||
|
|
.<br />
|
|||
|
|
PGMA<br />
|
|||
|
|
PGMB</p>
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
Because PGMA remains in the program stack after PGMB is called, PGMB
|
|||
|
|
uses the adopted authority of PGMA. (The use adopted authority (USEADPAUT)
|
|||
|
|
parameter can override this.</li>
|
|||
|
|
<li>If PGMA starts PGMB using the Transfer Control (TFRCTL) command, the program
|
|||
|
|
stacks look like this:
|
|||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><div>Adopted Authority and the TFRCTL Command</div><thead align="left"><tr valign="bottom"><th valign="bottom" id="d0e828">Program stack before TFRCTL command</th>
|
|||
|
|
<th valign="bottom" id="d0e830">Program stack after TFRCTL command</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody><tr><td valign="top" headers="d0e828 "><p>QCMD<br />
|
|||
|
|
.<br />
|
|||
|
|
.<br />
|
|||
|
|
.<br />
|
|||
|
|
PGMA</p>
|
|||
|
|
</td>
|
|||
|
|
<td valign="top" headers="d0e830 "><p>QCMD<br />
|
|||
|
|
.<br />
|
|||
|
|
.<br />
|
|||
|
|
.<br />
|
|||
|
|
PGMB</p>
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
PGMB does not use the adopted authority of PGMA, because PGMA is no
|
|||
|
|
longer in the program stack.</li>
|
|||
|
|
</ul>
|
|||
|
|
</li>
|
|||
|
|
<li>If the program running under adopted authority is interrupted, the use
|
|||
|
|
of adopted authority is suspended. The following functions do not use adopted
|
|||
|
|
authority:<ul><li>System request</li>
|
|||
|
|
<li>Attention key (If a Transfer to Group Job (TFRGRPJOB) command is running,
|
|||
|
|
adopted authority is not passed to the group job)</li>
|
|||
|
|
<li>Break-message-handling program</li>
|
|||
|
|
<li>Debug functions</li>
|
|||
|
|
</ul>
|
|||
|
|
<div class="note"><span class="notetitle">Note:</span> Adopted authority is immediately interrupted by the attention key
|
|||
|
|
or a group job request. The user must have authority to the attention-key-handling
|
|||
|
|
program or the group job initial program, or the attempt fails.</div>
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
For example, USERA runs the program PGM1, which adopts the authority
|
|||
|
|
of USERB. PGM1 uses the SETATNPGM command and specifies PGM2. USERB has *USE
|
|||
|
|
authority to PGM2. USERA has *EXCLUDE authority to PGM2. The SETATNPGM function
|
|||
|
|
is successful because it is run using adopted authority. USERA receives an
|
|||
|
|
authority error when attempting to use the attention key because USERB’s authority
|
|||
|
|
is no longer active.<ul><li>If a program that uses adopted authority submits a job, that submitted
|
|||
|
|
job does not have the adopted authority of the submitting program.</li>
|
|||
|
|
<li>When a trigger program or exit point program is called, adopted authority
|
|||
|
|
from previous programs in the call stack will not be used as a source of authority
|
|||
|
|
for the trigger program or exit point program.</li>
|
|||
|
|
<li>The program adopt function is not used when you use the Change Job (CHGJOB)
|
|||
|
|
command to change the output queue for a job. The user profile making the
|
|||
|
|
change must have authority to the new output queue.</li>
|
|||
|
|
<li>Any objects created, including spooled files, are owned by the user of
|
|||
|
|
the program or by the user’s group profile, not by the owner of the program.</li>
|
|||
|
|
<li>Adopted authority can be specified on either the command that creates
|
|||
|
|
the program (CRTxxxPGM) or on the Change Program (CHGPGM) command.</li>
|
|||
|
|
<li>If a program is created using REPLACE(*YES) on the CRTxxxPGM command,
|
|||
|
|
the new copy of the program has the same USRPRF, USEADPAUT, and AUT values
|
|||
|
|
as the replaced program. The USRPRF and AUT parameters specified on the CRTxxxPGM
|
|||
|
|
parameter are ignored.</li>
|
|||
|
|
<li>Only the owner of the program can specify REPLACE(*YES) on the CRTxxxPGM
|
|||
|
|
command when USRPRF(*OWNER) is specified on the original program.</li>
|
|||
|
|
<li>Only a user who owns the program or has *ALLOBJ and *SECADM special authorities
|
|||
|
|
can change the value of the USRPRF parameter.</li>
|
|||
|
|
<li>You must be signed on as a user with *ALLOBJ and *SECADM special authorities
|
|||
|
|
to transfer ownership of an object that adopts authority.</li>
|
|||
|
|
<li>If someone other than the program’s owner or a user with *ALLOBJ and *SECADM
|
|||
|
|
special authorities restores a program that adopts authority, all private
|
|||
|
|
and public authorities to the program are revoked to prevent a possible security
|
|||
|
|
exposure.</li>
|
|||
|
|
</ul>
|
|||
|
|
The Display Program (DSPPGM) and Display Service Program (DSPSRVPGM)
|
|||
|
|
commands show whether a program adopts authority (User profile prompt) and
|
|||
|
|
whether it uses adopted authority from previous programs in the program stack
|
|||
|
|
(Use adopted authority prompt). The Display Program Adopt (DSPPGMADP) command
|
|||
|
|
shows all the objects that adopt the authority of a specific user profile.
|
|||
|
|
The Print Adopting Objects (PRTADPOBJ) command provides a report with more
|
|||
|
|
information about objects that adopt authority. This command also provides
|
|||
|
|
an option to print a report for objects that changed since the last time the
|
|||
|
|
command was run.</div>
|
|||
|
|
<p>Adopted Authority and Bound Programs: An ILE* program (*PGM) is an object
|
|||
|
|
that contains one or more modules. It is created by an ILE* compiler. An ILE
|
|||
|
|
program can be bound to one or more service programs (*SRVPGM). </p>
|
|||
|
|
<p>To activate an ILE program successfully, the user must have *EXECUTE authority
|
|||
|
|
to the ILE program and to all service programs to which it is bound. If an
|
|||
|
|
ILE program uses adopted authority from a program higher in the program call
|
|||
|
|
stack, that adopted authority is used to check authority to all service programs
|
|||
|
|
to which the ILE program is bound. If the ILE program adopts authority, the
|
|||
|
|
adopted authority will not be checked when the system checks the user’s authority
|
|||
|
|
to the service programs at program activation time.</p>
|
|||
|
|
<div class="p"><strong>Adopted Authority Risks and Recommendations:</strong> Allowing a program
|
|||
|
|
to run using adopted authority is an intentional release of control. You permit
|
|||
|
|
the user to have authority to objects, and possibly special authority, which
|
|||
|
|
the user would not normally have. Adopted authority provides an important
|
|||
|
|
tool for meeting diverse authority requirements, but it should be used with
|
|||
|
|
care:<ul><li>Adopt the minimum authority required to meet the application requirements.
|
|||
|
|
Adopting the authority of an application owner is preferable to adopting the
|
|||
|
|
authority of QSECOFR or a user with *ALLOBJ special authority.</li>
|
|||
|
|
<li>Carefully monitor the function provided by programs that adopt authority.
|
|||
|
|
Make sure these programs do not provide a means for the user to access objects
|
|||
|
|
outside the control of the program, such as command entry capability.</li>
|
|||
|
|
<li>Programs that adopt authority and call other programs must perform a library
|
|||
|
|
qualified call. Do not use the library list (*LIBL) on the call.</li>
|
|||
|
|
<li>Control which users are permitted to call programs that adopt authority.
|
|||
|
|
Use menu interfaces and library security to prevent these programs from being
|
|||
|
|
called without sufficient control.</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<p><strong>Programs that ignore adopted authority</strong></p>
|
|||
|
|
<p>You may not want some programs to use the adopted authority of previous
|
|||
|
|
programs in the program stack. For example, if you use an initial menu program
|
|||
|
|
that adopts owner authority, you may not want some of the programs called
|
|||
|
|
from the menu program to use that authority. </p>
|
|||
|
|
<div class="p">The use adopted authority (USEADPAUT) parameter of a program determines
|
|||
|
|
whether the system uses the adopted authority of previous programs in the
|
|||
|
|
stack when checking authority for objects. When you create a program, the
|
|||
|
|
default is to use adopted authority from previous programs in the stack. If
|
|||
|
|
you do not want the program to use adopted authority, you can change the program
|
|||
|
|
with the Change Program (CHGPGM) command or Change Service Program (CHGSRVPGM)
|
|||
|
|
command to set the USEADPAUT parameter to *NO. If a program is created using
|
|||
|
|
REPLACE(*YES) on the CRTxxxPGM command, the new copy of the program has the
|
|||
|
|
same USRPRF, USEADPAUT, and AUT values as the replaced program.<div class="note"><span class="notetitle">Note:</span> In some
|
|||
|
|
situations, you can use the MODINVAU MI instruction to prevent passing adopted
|
|||
|
|
authority to called functions. The MODINVAU instruction can be used to prevent
|
|||
|
|
passing any adopted authority from C and C++ programs to called functions
|
|||
|
|
in another program or service program. This may be useful when you do not
|
|||
|
|
know the USEADPAUT setting of the function that is called.</div>
|
|||
|
|
</div>
|
|||
|
|
<p><strong>Authority holders</strong></p>
|
|||
|
|
<div class="p">An authority holder is a tool for keeping the authorities for a program-described
|
|||
|
|
database file that does not currently exist on the system. Its primary use
|
|||
|
|
is for System/36 environment
|
|||
|
|
applications, which often delete program-described files and create them again.
|
|||
|
|
An authority holder can be created for a file that already exists or for a
|
|||
|
|
file that does not exist, using the Create Authority Holder (CRTAUTHLR) command.
|
|||
|
|
The following applies to authority holders:<ul><li>Authority holders can only secure files in the system auxiliary storage
|
|||
|
|
pool (ASP) or a basic user ASP. They cannot secure files in an independent
|
|||
|
|
ASP.</li>
|
|||
|
|
<li>The authority holder is associated with a specific file and library. It
|
|||
|
|
has the same name as the file.</li>
|
|||
|
|
<li>Authority holders can be used only for program-described database files
|
|||
|
|
and logical files created in the S/36 environment.</li>
|
|||
|
|
<li>Once the authority holder is created, you add private authorities for
|
|||
|
|
it like a file. Use the commands to grant, revoke, and display object authorities,
|
|||
|
|
and specify object type *FILE. On the object authority displays, the authority
|
|||
|
|
holder is indistinguishable from the file itself. The displays do not indicate
|
|||
|
|
whether the file exists nor do they show that the file has an authority holder.</li>
|
|||
|
|
<li>If a file is associated with an authority holder, the authorities defined
|
|||
|
|
for the authority holder are used during authority checking. Any private authorities
|
|||
|
|
defined for the file are ignored.</li>
|
|||
|
|
<li>Use the Display Authority Holder (DSPAUTHLR) command to display or print
|
|||
|
|
all the authority holders on the system. You can also use it to create an
|
|||
|
|
output file (Outfile) for processing.</li>
|
|||
|
|
<li>If you create an authority holder for a file that exists:<ul><li>The user creating the authority holder must have *ALL authority to the
|
|||
|
|
file. </li>
|
|||
|
|
<li>The owner of the file becomes the owner of the authority holder regardless
|
|||
|
|
of the user creating the authority holder.</li>
|
|||
|
|
<li>The public authority for the authority holder comes from the file. The
|
|||
|
|
public authority (AUT) parameter on the CRTAUTHLR command is ignored.</li>
|
|||
|
|
<li>The existing file’s authority is copied to the authority holder.</li>
|
|||
|
|
</ul>
|
|||
|
|
</li>
|
|||
|
|
<li>If you create a file and an authority holder for that file already exists:<ul><li>The user creating the file must have *ALL authority to the authority holder. </li>
|
|||
|
|
<li>The owner of the authority holder becomes the owner of the file regardless
|
|||
|
|
of the user creating the file.</li>
|
|||
|
|
<li>The public authority for the file comes from the authority holder. The
|
|||
|
|
public authority (AUT) parameter on the CRTPF or CRTLF command is ignored.</li>
|
|||
|
|
<li>The authority holder is linked to the file. The authority specified for
|
|||
|
|
the authority holder is used to secure the file.</li>
|
|||
|
|
</ul>
|
|||
|
|
</li>
|
|||
|
|
<li>If an authority holder is deleted, the authority information is transferred
|
|||
|
|
to the file itself.</li>
|
|||
|
|
<li>If a file is renamed and the new file name matches an existing authority
|
|||
|
|
holder, the authority and ownership of the file are changed to match the authority
|
|||
|
|
holder. The user renaming the file needs *ALL authority to the authority holder.</li>
|
|||
|
|
<li>If a file is moved to a different library and an authority holder exists
|
|||
|
|
for that file name and the target library, the authority and ownership of
|
|||
|
|
the file are changed to match the authority holder. The user moving the file
|
|||
|
|
must have *ALL authority to the authority holder.</li>
|
|||
|
|
<li>Ownership of the authority holder and the file always match. If you change
|
|||
|
|
the ownership of the file, ownership of the authority holder also changes.</li>
|
|||
|
|
<li>When a file is restored, if an authority holder exists for that file name
|
|||
|
|
and the library to which it is being restored, it is linked to the authority
|
|||
|
|
holder.</li>
|
|||
|
|
<li>Authority holders cannot be created for files in these libraries: QSYS,
|
|||
|
|
QRCL, QRECOVERY, QSPL, QTEMP, and QSPL0002 – QSPL0032.</li>
|
|||
|
|
</ul>
|
|||
|
|
<strong>Authority Holders and System/36 Migration: </strong> The System/36 Migration
|
|||
|
|
Aid creates an authority holder for every file that is migrated. It also creates
|
|||
|
|
an authority holder for entries in the System/36 resource security file if
|
|||
|
|
no corresponding file exists on the System/36. You need authority holders
|
|||
|
|
only for files that are deleted and re-created by your applications. Use the
|
|||
|
|
Delete Authority Holder (DLTAUTHLR) command to delete any authority holders
|
|||
|
|
that you do not need.</div>
|
|||
|
|
<p><strong>Authority Holder Risks:</strong> An authority holder provides the capability
|
|||
|
|
of defining authority for a file before that file exists. Under certain circumstances,
|
|||
|
|
this could allow an unauthorized user to gain access to information. If a
|
|||
|
|
user knew that an application would create, move, or rename a file, the user
|
|||
|
|
could create an authority holder for the new file. The user would thus gain
|
|||
|
|
access to the file. To limit this exposure, the CRTAUTHLR command is shipped
|
|||
|
|
with public authority *EXCLUDE. Only users with *ALLOBJ authority can use
|
|||
|
|
the command, unless you grant authority to others.</p>
|
|||
|
|
<p><strong>Working with authority</strong></p>
|
|||
|
|
<p>This information describes commonly-used methods for setting up, maintaining,
|
|||
|
|
and displaying authority information on your system. "Security commands" provides
|
|||
|
|
a complete list of the commands available for working with authority. The
|
|||
|
|
descriptions that follow do not discuss all the parameters for commands or
|
|||
|
|
all the fields on the displays.</p>
|
|||
|
|
<p><strong>Authority displays</strong></p>
|
|||
|
|
<div class="p">Four displays show object authorities: <ul><li>Display Object Authority display</li>
|
|||
|
|
<li>Edit Object Authority display</li>
|
|||
|
|
<li>Display Authority display </li>
|
|||
|
|
<li>Work with Authority display</li>
|
|||
|
|
</ul>
|
|||
|
|
<div class="note"><span class="notetitle">Note:</span> <ul><li>If you have *OBJMGT authority to an object, you see all private authorities
|
|||
|
|
for that object. If you do not have *OBJMGT authority, you see only your own
|
|||
|
|
sources of authority for the object.</li>
|
|||
|
|
<li>The *ADOPTED authority indicates only the additional authority received
|
|||
|
|
from the program owner.</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<p><strong>Authority reports</strong></p>
|
|||
|
|
<div class="p">Several reports are available to help you monitor your security implementation.
|
|||
|
|
For example, you can monitor objects with *PUBLIC authority other than *EXCLUDE
|
|||
|
|
and objects with private authorities with the following commands:<ul><li>Print Public Authority (PRTPUBAUT)</li>
|
|||
|
|
<li>Print Private Authority (PRTPVTAUT)</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<p><strong>Working with libraries</strong></p>
|
|||
|
|
<div class="p">Two parameters on the Create Library (CRTLIB) command affect authority: <ul><li>Authority (AUT): The AUT parameter can be used to specify either of the
|
|||
|
|
following: <ul><li>The public authority for the library</li>
|
|||
|
|
<li>The authorization list that secures the library.</li>
|
|||
|
|
</ul>
|
|||
|
|
The AUT parameter applies to the library itself, not to the objects
|
|||
|
|
in the library. If you specify an authorization list name, the public authority
|
|||
|
|
for the library is set to *AUTL. If you do not specify AUT when you create
|
|||
|
|
a library, *LIBCRTAUT is the default. The system uses the CRTAUT value from
|
|||
|
|
the QSYS library, which is shipped as *SYSVAL. </li>
|
|||
|
|
<li>Create Authority (CRTAUT): The CRTAUT parameter determines the default
|
|||
|
|
authority for any new objects that are created in the library. CRTAUT can
|
|||
|
|
be set to one of the system-defined authorities (*ALL, *CHANGE, *USE, or *EXCLUDE),
|
|||
|
|
to *SYSVAL (the QCRTAUT system value), or to the name of an authorization
|
|||
|
|
list. <div class="note"><span class="notetitle">Note:</span> You can change the CRTAUT value for a library using the Change
|
|||
|
|
Library (CHGLIB) command.</div>
|
|||
|
|
</li>
|
|||
|
|
</ul>
|
|||
|
|
</div>
|
|||
|
|
<p><strong>Creating objects</strong></p>
|
|||
|
|
<p>When you create a new object, you can either specify the authority (AUT)
|
|||
|
|
or use the default, *LIBCRTAUT.</p>
|
|||
|
|
<p><strong>Working with individual object authority</strong></p>
|
|||
|
|
<div class="p">To change the authority for an object you must have one of the following: <ul><li>*ALLOBJ authority or membership in a group profile that has *ALLOBJ special
|
|||
|
|
authority.<div class="note"><span class="notetitle">Note:</span> The group’s authority is not used if you have private authority
|
|||
|
|
to the object.</div>
|
|||
|
|
</li>
|
|||
|
|
<li>Ownership of the object. If a group profile owns the object, any member
|
|||
|
|
of the group can act as the object owner, unless the member has been given
|
|||
|
|
specific authority that does not meet the requirements for changing the object’s
|
|||
|
|
authority.</li>
|
|||
|
|
<li>*OBJMGT authority to the object and any authorities being granted or revoked
|
|||
|
|
(except *EXCLUDE). Any user who is allowed to work with the object’s authority
|
|||
|
|
can grant or revoke *EXCLUDE authority.</li>
|
|||
|
|
</ul>
|
|||
|
|
The easiest way to change authority for an individual object is with
|
|||
|
|
the Edit Object Authority display. This display can be called directly by
|
|||
|
|
using the Edit Object Authority (EDTOBJAUT) command or selected as an option
|
|||
|
|
from the Work with Objects by Owner (WRKOBJOWN) or WRKOBJ (Work with Objects)
|
|||
|
|
display. You can also use these commands to change object authority: <ul><li>Change Authority (CHGAUT)</li>
|
|||
|
|
<li>Work with Authority (WRKAUT)</li>
|
|||
|
|
<li>Grant Object Authority (GRTOBJAUT)</li>
|
|||
|
|
<li>Revoke Object Authority (RVKOBJAUT)</li>
|
|||
|
|
</ul>
|
|||
|
|
To specify the generic authority subsets, such as Read/Write (*RX) or
|
|||
|
|
Write/Execute (*WX), you must use the CHGAUT or WRKAUT commands.</div>
|
|||
|
|
<p><strong>Specifying user-defined authority</strong></p>
|
|||
|
|
<div class="p">The Object Authority column on the Edit Object Authority display allows
|
|||
|
|
you to specify any of the system-defined sets of authorities (*ALL, *CHANGE,
|
|||
|
|
*USE, *EXCLUDE). If you want to specify authority that is not a system-defined
|
|||
|
|
set, use F11 (Display detail). <div class="note"><span class="notetitle">Note:</span> If the User options (USROPT) field in
|
|||
|
|
your user profile is set to *EXPERT, you always see this detailed version
|
|||
|
|
of the display without having to press F11. You can press F11 (Display data
|
|||
|
|
authorities) to view or change the data authorities.</div>
|
|||
|
|
To give authority
|
|||
|
|
to additional users, press F6 (Add new users) from the Edit Object Authority
|
|||
|
|
display. You see the Add New Users display, which allows you to define authority
|
|||
|
|
for multiple users.</div>
|
|||
|
|
<p>Removing a user’s authority for an object is different from giving the
|
|||
|
|
user *EXCLUDE authority. *EXCLUDE authority means the user is specifically
|
|||
|
|
not allowed to use the object. Only *ALLOBJ special authority and adopted
|
|||
|
|
authority override *EXCLUDE authority. Removing a user’s authority means the
|
|||
|
|
user has no specific authority to the object. The user can gain access through
|
|||
|
|
a group profile, an authorization list, public authority, *ALLOBJ special
|
|||
|
|
authority, or adopted authority. </p>
|
|||
|
|
<div class="p">You can remove a user’s authority using the Edit Object Authority display.
|
|||
|
|
Type blanks in the Object Authority field for the user and press the Enter
|
|||
|
|
key. The user is removed from the display. You can also use the Revoke Object
|
|||
|
|
Authority (RVKOBJAUT) command. Either revoke the specific authority the user
|
|||
|
|
has or revoke *ALL authority for the user. <div class="note"><span class="notetitle">Note:</span> The RVKOBJAUT command revokes
|
|||
|
|
only the authority you specify. For example, USERB has *ALL authority to FILEB
|
|||
|
|
in library LIBB. You revoke *CHANGE authority: <kbd class="userinput">RVKOBJAUT OBJ(LIBB/FILEB)
|
|||
|
|
OBJTYPE(*FILE) + USER(*USERB) AUT(*CHANGE)</kbd></div>
|
|||
|
|
</div>
|
|||
|
|
<p><strong>Working with authority for multiple objects</strong></p>
|
|||
|
|
<div class="p">The <span class="uicontrol">Edit Object Authority</span> display allows you to
|
|||
|
|
interactively work with the authority for one object at a time. The Grant
|
|||
|
|
Object Authority (GRTOBJAUT) command allows you to make authority changes
|
|||
|
|
to more than one object at a time. You can use the GRTOBJAUT authority command
|
|||
|
|
interactively or in batch. You can also call it from a program. Following
|
|||
|
|
are examples of using the GRTOBJAUT command, showing the prompt display. When
|
|||
|
|
the command runs, you receive a message for each object indicating whether
|
|||
|
|
the change was made. Authority changes require an exclusive lock on the object
|
|||
|
|
and cannot be made when an object is in use. Print your job log for a record
|
|||
|
|
of changes attempted and made. To give all the objects in the TESTLIB library
|
|||
|
|
a public authority of *USE:<pre class="screen">Grant Object Authority (GRTOBJAUT)
|
|||
|
|
|
|||
|
|
Type choices, press Enter.
|
|||
|
|
Object . . . . . . . . . . . . . *ALL
|
|||
|
|
Library . . . . . . . . . . . . . TESTLIB
|
|||
|
|
Object type . . . . . . . . . . *ALL
|
|||
|
|
ASP device . . . . . . . . . . . *
|
|||
|
|
Users . . . . . . . . . . . . . *PUBLIC
|
|||
|
|
+ for more values
|
|||
|
|
Authority . . . . . . . . . . . *USE</pre>
|
|||
|
|
This example for the GRTOBJAUT
|
|||
|
|
command gives the authority you specify, but it does not remove any authority
|
|||
|
|
that is greater than you specified. If some objects in the TESTLIB library
|
|||
|
|
have public authority *CHANGE, the command just shown would not reduce their
|
|||
|
|
public authority to *USE. To make sure that all objects in TESTLIB have a
|
|||
|
|
public authority of *USE, use the GRTOBJAUT command with the REPLACE parameter: <kbd class="userinput">GRTOBJAUT
|
|||
|
|
OBJ(TESTLIB/*ALL) OBJTYPE(*ALL) + USER(*PUBLIC) REPLACE(*YES)</kbd></div>
|
|||
|
|
<p>The REPLACE parameter indicates whether the authorities you specify replaces
|
|||
|
|
the existing authority for the user. The default value of REPLACE(*NO) gives
|
|||
|
|
the authority that you specify, but it does not remove any authority that
|
|||
|
|
is greater than the authority you specify, unless you are granting *EXCLUDE
|
|||
|
|
authority. These commands set public authority only for objects that currently
|
|||
|
|
exist in the library. To set the public authority for any new objects that
|
|||
|
|
are created later, use the CRTAUT parameter on the library description.</p>
|
|||
|
|
<p><strong>Working with object ownership</strong></p>
|
|||
|
|
<div class="p">To change ownership of an object, use one of the following:<ul><li>The Change Object Owner (CHGOBJOWN) command</li>
|
|||
|
|
<li>The Work with Objects by Owner (WRKOBJOWN) command </li>
|
|||
|
|
<li>The Change Owner (CHGOWN) command</li>
|
|||
|
|
</ul>
|
|||
|
|
The Work with Objects by Owner display shows all the objects owned by
|
|||
|
|
a profile. You can assign individual objects to a new owner. You can also
|
|||
|
|
change ownership for more than one object at a time by using the NEWOWN (new
|
|||
|
|
owner) parameter at the bottom of the display. When you change ownership using
|
|||
|
|
either method, you can choose to remove the previous owner’s authority to
|
|||
|
|
the object. The default for the CUROWNAUT (current owner authority) parameter
|
|||
|
|
is *REVOKE. To transfer ownership of an object, you must have:<ul><li>Object existence authority for the object </li>
|
|||
|
|
<li>*ALL authority or ownership, if the object is an authorization list</li>
|
|||
|
|
<li>Add authority for the new owner’s user profile</li>
|
|||
|
|
<li>Delete authority for the present owner’s user profile</li>
|
|||
|
|
</ul>
|
|||
|
|
You cannot delete a user profile that owns objects. The Work with Objects
|
|||
|
|
by Owner display includes integrated file system objects. For these objects,
|
|||
|
|
the Object column on the display shows the first 18 characters of the path
|
|||
|
|
name. If the path name is longer than 18 characters, a greater than symbol
|
|||
|
|
(>) appears at the end of the path name. To see the absolute path name, place
|
|||
|
|
your cursor anywhere on the path name and press the F22 key.</div>
|
|||
|
|
<p><strong>Resource security</strong></p>
|
|||
|
|
<p>Resource security on the system allows you to define who can use objects
|
|||
|
|
and how those objects can be used. The ability to access an object is called
|
|||
|
|
authority. When you set up object authority, you can need to be careful to
|
|||
|
|
give your users enough authority to do their work without giving them the
|
|||
|
|
authority to browse and change the system. </p>
|
|||
|
|
<p>Object authority gives permissions to the user for a specific object and
|
|||
|
|
can specify what the user is allowed to do with the object. An object resource
|
|||
|
|
can be limited through specific detailed user authorities, such as adding
|
|||
|
|
records or changing records. System resources can be used to give the user
|
|||
|
|
access to specific system-defined subsets of authorities: *ALL, *CHANGE, *USE,
|
|||
|
|
and *EXCLUDE. Files, programs, libraries, and directories are the most common
|
|||
|
|
system objects that require resource security protection, but you can specify
|
|||
|
|
authority for any individual object on the system.</p>
|
|||
|
|
<p><strong>Understanding the types of authority:</strong> After you have determined
|
|||
|
|
your objectives for your resource security and recorded your decisions on
|
|||
|
|
the Library Description form, you can begin to plan types of authority. Resource
|
|||
|
|
security defines how users have access to objects on the system. </p>
|
|||
|
|
<div class="p">Authority means how someone is authorized to use an object. For example,
|
|||
|
|
you may have the authority to view information or to change information on
|
|||
|
|
the system. The system provides several different authority types. IBM<sup>®</sup> groups these
|
|||
|
|
authority types into categories, called system-defined authorities, which
|
|||
|
|
meet the needs of most people. The table below lists the categories and tells
|
|||
|
|
how they apply to securing files and programs. <div class="note"><span class="notetitle">Note:</span> Refer to the tables below
|
|||
|
|
when you plan authorities.</div>
|
|||
|
|
|
|||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><div>System-defined authorities</div><thead align="left"><tr valign="bottom"><th valign="bottom" id="d0e1146">Authority name</th>
|
|||
|
|
<th valign="bottom" id="d0e1148">Operations allowed for files</th>
|
|||
|
|
<th valign="bottom" id="d0e1150">Operations not allowed for files</th>
|
|||
|
|
<th valign="bottom" id="d0e1152">Operations allowed for programs</th>
|
|||
|
|
<th valign="bottom" id="d0e1154">Operations not allowed for programs</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody><tr><td valign="top" headers="d0e1146 ">*USE</td>
|
|||
|
|
<td valign="top" headers="d0e1148 ">View information in the file.</td>
|
|||
|
|
<td valign="top" headers="d0e1150 ">Change or delete any information in the file. Delete
|
|||
|
|
the file. </td>
|
|||
|
|
<td valign="top" headers="d0e1152 ">Run the program.</td>
|
|||
|
|
<td valign="top" headers="d0e1154 ">Change or delete the program</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e1146 ">*CHANGE</td>
|
|||
|
|
<td valign="top" headers="d0e1148 ">View, change and delete records in the file.</td>
|
|||
|
|
<td valign="top" headers="d0e1150 ">Delete or clear the entire file.</td>
|
|||
|
|
<td valign="top" headers="d0e1152 ">Change the description of the program.</td>
|
|||
|
|
<td valign="top" headers="d0e1154 ">Change or delete the program.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e1146 ">*ALL</td>
|
|||
|
|
<td valign="top" headers="d0e1148 ">Create and delete the file. Add, change and delete records
|
|||
|
|
in the file. Authorize others to use the file.</td>
|
|||
|
|
<td valign="top" headers="d0e1150 ">None</td>
|
|||
|
|
<td valign="top" headers="d0e1152 ">Create, change and delete the program. Authorize others
|
|||
|
|
to use the program.</td>
|
|||
|
|
<td valign="top" headers="d0e1154 ">Change the owner of the program, if the program adopts
|
|||
|
|
authority.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e1146 ">*EXCLUDE<sup>1</sup></td>
|
|||
|
|
<td valign="top" headers="d0e1148 ">None</td>
|
|||
|
|
<td valign="top" headers="d0e1150 ">Any access to the file.</td>
|
|||
|
|
<td valign="top" headers="d0e1152 ">None</td>
|
|||
|
|
<td valign="top" headers="d0e1154 ">Any access to the program.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td colspan="5" valign="top" headers="d0e1146 d0e1148 d0e1150 d0e1152 d0e1154 "><sup>1</sup> *EXCLUDE overrides any authorities
|
|||
|
|
that you grant to the public or through a group profile.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
To design simple resource security, try to plan security for entire
|
|||
|
|
libraries. To do this, you need to understand how the system-defined authorities
|
|||
|
|
apply to libraries, which the table below shows:
|
|||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><div>System-defined
|
|||
|
|
authorities for libraries</div><thead align="left"><tr valign="bottom"><th valign="bottom" width="22.033898305084744%" id="d0e1218">Authority name</th>
|
|||
|
|
<th valign="bottom" width="38.983050847457626%" id="d0e1220">Operations allowed</th>
|
|||
|
|
<th valign="bottom" width="38.983050847457626%" id="d0e1222">Operations not allowed</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody><tr><td valign="top" width="22.033898305084744%" headers="d0e1218 ">*USE</td>
|
|||
|
|
<td valign="top" width="38.983050847457626%" headers="d0e1220 "><ul><li>For objects in the library, any operation allowed by the authority to
|
|||
|
|
the specific object.</li>
|
|||
|
|
<li>For the library, view descriptive information.</li>
|
|||
|
|
</ul>
|
|||
|
|
</td>
|
|||
|
|
<td valign="top" width="38.983050847457626%" headers="d0e1222 "><ul><li>Add new objects to the library.</li>
|
|||
|
|
<li>Change the library description.</li>
|
|||
|
|
<li>Delete the library.</li>
|
|||
|
|
</ul>
|
|||
|
|
</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="22.033898305084744%" headers="d0e1218 ">*CHANGE</td>
|
|||
|
|
<td valign="top" width="38.983050847457626%" headers="d0e1220 "><ul><li>For objects in the library, any operation allowed by the authority to
|
|||
|
|
the specific object.</li>
|
|||
|
|
<li>Add new objects to the library.</li>
|
|||
|
|
<li>Change the library description.</li>
|
|||
|
|
</ul>
|
|||
|
|
</td>
|
|||
|
|
<td valign="top" width="38.983050847457626%" headers="d0e1222 ">Delete the library.</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" width="22.033898305084744%" headers="d0e1218 ">*ALL</td>
|
|||
|
|
<td valign="top" width="38.983050847457626%" headers="d0e1220 "><ul><li>Everything allowed with change.</li>
|
|||
|
|
<li>Delete the library.</li>
|
|||
|
|
<li>Authorize others to the library.</li>
|
|||
|
|
</ul>
|
|||
|
|
</td>
|
|||
|
|
<td valign="top" width="38.983050847457626%" headers="d0e1222 ">None.</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
You also need to understand how library and object authority work
|
|||
|
|
together. The table below gives examples of authorities that are required
|
|||
|
|
for both an object and the library:
|
|||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><div>How library authority and
|
|||
|
|
object authority work together</div><thead align="left"><tr valign="bottom"><th valign="bottom" id="d0e1279">Object type</th>
|
|||
|
|
<th valign="bottom" id="d0e1281">Operations</th>
|
|||
|
|
<th valign="bottom" id="d0e1283">Object authority needed</th>
|
|||
|
|
<th valign="bottom" id="d0e1285">Library authority needed</th>
|
|||
|
|
</tr>
|
|||
|
|
</thead>
|
|||
|
|
<tbody><tr><td valign="top" headers="d0e1279 ">File</td>
|
|||
|
|
<td valign="top" headers="d0e1281 ">Change data</td>
|
|||
|
|
<td valign="top" headers="d0e1283 ">*CHANGE</td>
|
|||
|
|
<td valign="top" headers="d0e1285 ">*USE</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e1279 ">File</td>
|
|||
|
|
<td valign="top" headers="d0e1281 ">Delete the file</td>
|
|||
|
|
<td valign="top" headers="d0e1283 ">*ALL</td>
|
|||
|
|
<td valign="top" headers="d0e1285 ">*USE</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e1279 ">File</td>
|
|||
|
|
<td valign="top" headers="d0e1281 ">Create the file</td>
|
|||
|
|
<td valign="top" headers="d0e1283 ">*ALL</td>
|
|||
|
|
<td valign="top" headers="d0e1285 ">*CHANGE</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e1279 ">Program</td>
|
|||
|
|
<td valign="top" headers="d0e1281 ">Run the program</td>
|
|||
|
|
<td valign="top" headers="d0e1283 ">*USE</td>
|
|||
|
|
<td valign="top" headers="d0e1285 ">*USE</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e1279 ">Program</td>
|
|||
|
|
<td valign="top" headers="d0e1281 ">Change (recompile) the program</td>
|
|||
|
|
<td valign="top" headers="d0e1283 ">*ALL</td>
|
|||
|
|
<td valign="top" headers="d0e1285 ">*CHANGE</td>
|
|||
|
|
</tr>
|
|||
|
|
<tr><td valign="top" headers="d0e1279 ">Program</td>
|
|||
|
|
<td valign="top" headers="d0e1281 ">Delete the program</td>
|
|||
|
|
<td valign="top" headers="d0e1283 ">*ALL</td>
|
|||
|
|
<td valign="top" headers="d0e1285 ">*USE</td>
|
|||
|
|
</tr>
|
|||
|
|
</tbody>
|
|||
|
|
</table>
|
|||
|
|
</div>
|
|||
|
|
Directory authority is similar to library authority. You need authority
|
|||
|
|
to all the directories in the path name for an object in order to access the
|
|||
|
|
object.</div>
|
|||
|
|
</div>
|
|||
|
|
<div>
|
|||
|
|
<div class="familylinks">
|
|||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamvplanappsec.htm" title="This topic provides on overview for creating an application security plan for your company.">Plan application security</a></div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</body>
|
|||
|
|
</html>
|