124 lines
7.4 KiB
HTML
124 lines
7.4 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="Root, QOpenSys, and user-defined file systems" />
|
|||
|
|
<meta name="abstract" content="These are security considerations for the root, QOpenSys, and user-defined file systems." />
|
|||
|
|
<meta name="description" content="These are security considerations for the root, QOpenSys, and user-defined file systems." />
|
|||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvplanifssec.htm" />
|
|||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvifssecrootfile.htm" />
|
|||
|
|
<meta name="DC.Relation" scheme="URI" content="rzamvifsrootdir.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="ifsrootfiles" />
|
|||
|
|
<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>Root, QOpenSys, and user-defined file systems</title>
|
|||
|
|
</head>
|
|||
|
|
<body id="ifsrootfiles"><a name="ifsrootfiles"><!-- --></a>
|
|||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
|||
|
|
<h1 class="topictitle1">Root, QOpenSys, and user-defined file systems</h1>
|
|||
|
|
<div><p>These are security considerations for the root, QOpenSys, and user-defined
|
|||
|
|
file systems.</p>
|
|||
|
|
<div class="section"><h4 class="sectiontitle">How authority works</h4><div class="p">The root, QOpenSys, and user-defined
|
|||
|
|
file systems provide a blending of iSeries™ server, PC, and UNIX** capabilities
|
|||
|
|
both for object management and for security. When you use the integrated file
|
|||
|
|
system commands from an iSeries server session (WRKAUT and CHGAUT), you can
|
|||
|
|
set all the normal iSeries server object authorities. This includes
|
|||
|
|
the *R, *W, and *X authorities that are compatible with Spec 1170 (UNIX-type
|
|||
|
|
operating systems).<div class="note"><span class="notetitle">Note:</span> The root, QOpenSys, and user-defined file systems
|
|||
|
|
are functionally equivalent. The QOpenSys file system is case-sensitive. The
|
|||
|
|
root file system is not. User-defined file systems can be defined as case-sensitive.
|
|||
|
|
Because these file systems have the same security characteristics, you can
|
|||
|
|
assume in the topics that follow that their names are used interchangeably.</div>
|
|||
|
|
When
|
|||
|
|
you access the root file system as an administrator from a PC session, you
|
|||
|
|
can set object attributes that the PC uses to restrict certain types of access:<ul><li>System</li>
|
|||
|
|
<li>Hidden</li>
|
|||
|
|
<li>Archive</li>
|
|||
|
|
<li>Read-only</li>
|
|||
|
|
</ul>
|
|||
|
|
These PC attributes are in addition to, not replacements for, iSeries server
|
|||
|
|
object authority values.</div>
|
|||
|
|
<p>When a user attempts to access an object in
|
|||
|
|
the root file system, OS/400<sup>®</sup> enforces all of the object authority values
|
|||
|
|
and attributes for the object, whether or not those authorities are ″visible″
|
|||
|
|
from the user’s interface. For example, assume that the read-only attribute
|
|||
|
|
for an object is set on. A PC user cannot delete the object through a iSeries Access
|
|||
|
|
interface. An iSeries server
|
|||
|
|
user with a fixed function workstation cannot delete the object either, even
|
|||
|
|
if the iSeries server
|
|||
|
|
user has *ALLOBJ special authority. Before the object can be deleted, an authorized
|
|||
|
|
user must use a PC function to reset the read-only value to off. Similarly,
|
|||
|
|
a PC user might not have sufficient OS/400 authority to change the PC-relevant
|
|||
|
|
security attributes of an object.</p>
|
|||
|
|
<div class="p">UNIX-type applications that run on iSeries servers
|
|||
|
|
use UNIX-like application programming interfaces (APIs) to access data in
|
|||
|
|
the root file system. With UNIX-like APIs, applications can recognize and
|
|||
|
|
maintain the following security information:<ul><li>Object owner</li>
|
|||
|
|
<li>Group owner (iSeries server
|
|||
|
|
primary group authority)</li>
|
|||
|
|
<li>Read (files)</li>
|
|||
|
|
<li>Write (change contents)</li>
|
|||
|
|
<li>Execute (run programs or search directories)</li>
|
|||
|
|
<li>S_ISVTX mode bit (restricted rename and unlink attribute)</li>
|
|||
|
|
</ul>
|
|||
|
|
The system maps these data authorities to existing iSeries server
|
|||
|
|
object and data authorities:<ul><li>Read (*R) = *OBJOPR and *READ</li>
|
|||
|
|
<li>Write (*W) = *OBJOPR, *ADD, *UPD, *DLT</li>
|
|||
|
|
<li>Execute (*X) = *OBJOPR and *EXECUTE</li>
|
|||
|
|
</ul>
|
|||
|
|
The concepts for other object authorities (*OBJMGT, *OBJEXIST, *OBJALTER,
|
|||
|
|
and *OBJREF) do not exist in a UNIX-type environment.</div>
|
|||
|
|
<div class="p">However, these
|
|||
|
|
object authorities do exist for all of the objects in the root file system.
|
|||
|
|
When you create an object using a UNIX-like API, that object inherits these
|
|||
|
|
authorities from the parent directory, resulting in the following:<ul><li>The new object’s owner has the same object authority as the parent directory’s
|
|||
|
|
owner.</li>
|
|||
|
|
<li>The new object’s primary group has the same object authority as the parent
|
|||
|
|
directory’s primary group.</li>
|
|||
|
|
<li>The new object’s public has the same object authority as the parent directory’s
|
|||
|
|
public.</li>
|
|||
|
|
</ul>
|
|||
|
|
The new object’s data authority for owner, primary group, and public
|
|||
|
|
are specified on the API with the mode parameter. When all of the object authorities
|
|||
|
|
are set ’on’, you get the authority behavior that you would expect in a UNIX-type
|
|||
|
|
environment. It is best to leave them set ’on’, unless you do not want the
|
|||
|
|
POSIX-like behavior. </div>
|
|||
|
|
<p>When you run applications that use UNIX-like APIs,
|
|||
|
|
the system enforces all object authorities, whether or not they are ″visible″
|
|||
|
|
to UNIX-type applications. For example, the system will enforce the authority
|
|||
|
|
of authorization lists even though the concept of authorization lists does
|
|||
|
|
not exist in UNIX-type operating systems. </p>
|
|||
|
|
<p>When you have a mixed-application
|
|||
|
|
environment, you need to ensure that you do not make authority changes in
|
|||
|
|
one environment that will break your applications in another environment.</p>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
<div>
|
|||
|
|
<ul class="ullinks">
|
|||
|
|
<li class="ulchildlink"><strong><a href="rzamvifssecrootfile.htm">Security commands for the root, QOpenSys, and user-defined file systems</a></strong><br />
|
|||
|
|
IBM provides a set of commands for working with objects in multiple file systems.</li>
|
|||
|
|
<li class="ulchildlink"><strong><a href="rzamvifsrootdir.htm">Public authority to the root directory</a></strong><br />
|
|||
|
|
When your system ships, the public authority to the <span class="q">"root"</span> directory
|
|||
|
|
is *ALL (all object authorities and all data authorities).</li>
|
|||
|
|
</ul>
|
|||
|
|
|
|||
|
|
<div class="familylinks">
|
|||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamvplanifssec.htm" title="The integrated file system provides you with multiple ways to store and view information on the server.">Plan integrated file system security</a></div>
|
|||
|
|
</div>
|
|||
|
|
</div>
|
|||
|
|
</body>
|
|||
|
|
</html>
|