179 lines
13 KiB
HTML
179 lines
13 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 integrated file system security" />
|
||
<meta name="abstract" content="The integrated file system provides you with multiple ways to store and view information on the server." />
|
||
<meta name="description" content="The integrated file system provides you with multiple ways to store and view information on the server." />
|
||
<meta name="DC.Relation" scheme="URI" content="rzamvplanrscsec.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzamvifsapproach.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzamvifsrootfiles.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzamvifsqsyslib.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzamvifssecdirectory.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzamvifssecnewobject.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzamvifsqfilesvr.htm" />
|
||
<meta name="DC.Relation" scheme="URI" content="rzamvifsnetwork.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="planifssec" />
|
||
<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 integrated file system security</title>
|
||
</head>
|
||
<body id="planifssec"><a name="planifssec"><!-- --></a>
|
||
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
<h1 class="topictitle1">Plan integrated file system security</h1>
|
||
<div><p>The integrated file system provides you with multiple ways to store
|
||
and view information on the server.</p>
|
||
<div class="p"> The integrated file system is a part of the i5/OS™ operating system that supports stream
|
||
input and output operations. It provides storage management methods that are
|
||
similar to (and compatible with) personal computer operating systems and UNIX®
|
||
operating systems. With the integrated file system, all objects on the system
|
||
can be viewed from the perspective of a hierarchical directory structure.
|
||
However, in most cases, users view objects in the way that is most common
|
||
for a particular file system. For example, ″traditional″ objects are in the
|
||
QSYS.LIB file system. Typically, users view these objects from the perspective
|
||
of libraries. Users typically view objects in the QDLS file system from the
|
||
perspective of documents within folders. The root (/), QOpenSys, and user-defined
|
||
file systems present a structure of hierarchical (nested) directories. As
|
||
a security administrator, you need to understand the following:<ul><li>Which file systems are used on your system</li>
|
||
<li>The unique security characteristics of each file system</li>
|
||
</ul>
|
||
The following information provides some general considerations for the
|
||
security of the integrated file system.</div>
|
||
<p><strong>The integrated file system approach to security</strong></p>
|
||
<p>The root file system acts as an umbrella (or a foundation) for all other
|
||
server file systems. At a high level, it provides an integrated view of all
|
||
of the objects on the system. Other file systems that can exist on servers
|
||
provide varying approaches to object management and integration, depending
|
||
on the underlying purpose of each file system. The QOPT (optical) file system,
|
||
for example, allows applications and servers (including the iSeries™ Access
|
||
for Windows<sup>®</sup> file
|
||
server) to access the CD-ROM drive on the server. Similarly, the QFileSvr.400
|
||
file system allows applications to access integrated file system data on remote
|
||
servers.</p>
|
||
<p>The security approach for each file system depends on the data that the
|
||
file system makes available. The QOPT file system, for example, does not provide
|
||
object-level security because no technology exists to write authority information
|
||
to a CD-ROM. For the QFileSvr.400 file system, access control occurs at the
|
||
remote system (where the files are physically stored and managed). For file
|
||
systems like QLANSrv, the Integrated xSeries<sup>®</sup> Server for iSeries provides
|
||
access control. Despite the differing security models, many file systems support
|
||
consistent management of access control through the integrated file system
|
||
commands, such as Change Authority (CHGAUT) and Change Owner (CHGOWN). </p>
|
||
<div class="p">Here are some tips related to the nooks and crannies of integrated file
|
||
system security. The integrated file system is designed to follow POSIX standards
|
||
as closely as possible. This leads to some interesting behavior
|
||
where server authority and POSIX permissions are ″blended″:<ol><li>Do not remove the private authority for a user to a directory owned by
|
||
that user, even if that user is authorized through the public authority, a
|
||
group, or authorization list. When working with libraries or folders in the
|
||
standard server security model, removing the owner’s private authority would
|
||
reduce the amount of authority information stored for a user profile and would
|
||
not affect other operations. But, because of the way the POSIX standard defines
|
||
permission inheritance for directories, the owner of a newly-created directory
|
||
will have the same object authorities to that directory as the owner of the
|
||
parent has to the parent, even if the owner of the newly-created directory
|
||
has other private authorities to the parent. <p>That may be difficult to understand,
|
||
so here is an example: USERA owns directory /DIRA, but USERA’s private authorities
|
||
have been removed. USERB has private authority to /DIRA. USERB creates directory
|
||
/DIRA/DIRB. Because USERA has no object authorities to /DIRA, USERB will have
|
||
no object authorities to /DIRA/DIRB. USERB will be unable to rename or delete
|
||
/DIRA/DIRB without further action to change USERB’s object authorities. This
|
||
also comes into play when creating files with the open() API using the O_INHERITMODE
|
||
flag. If USERB created a file /DIRA/FILEB, USERB would have no object authorities
|
||
AND no data authorities to it. USERB could not write to the new file.</p>
|
||
</li>
|
||
<li>Adopted authority is not honored by most physical file systems. This includes
|
||
the root (/), QOpenSys, QDLS, and user-defined file systems.</li>
|
||
<li>Any objects are owned by the user profile which created the objects, even
|
||
if the OWNER field of the user profile is set to *GRPPRF.</li>
|
||
<li>Many file system operations require *RX data authority to every component
|
||
of the path, including the root (/) directory. When experiencing authority
|
||
problems, make sure to check the user’s authorization to the root itself.</li>
|
||
<li>Displaying or retrieving the current working directory (DSPCURDIR, getcwd(),
|
||
etc.) requires *RX data authority to every component in the path. However,
|
||
changing the current working directory (CD, chdir(), etc.) only requires *X
|
||
data authority to every component. Therefore, a user may change the current
|
||
working directory to a certain path and then be unable to display that path.</li>
|
||
<li>The intent of the COPY command is to duplicate an object. The authority
|
||
settings on the new file will be the same as the original except for the owner.
|
||
The intent of the CPYTOSTMF command, however, is simply to duplicate data.
|
||
The authority settings on the new file cannot be controlled by the user. The
|
||
creator/owner will have *RWX data authority, but the group and public authorities
|
||
will be *EXCLUDE. The user must use another means (CHGAUT, chmod(), etc.)
|
||
to assign the desired authorities.</li>
|
||
<li>A user must be the owner or have *OBJMGT object authority to an object
|
||
to retrieve authority information about the object. This pops up in some unexpected
|
||
places, like COPY, which must retrieve the authority information on the source
|
||
object to set the equivalent authorities on the target object.</li>
|
||
<li>When changing the owner or group of an object, the user must not only
|
||
have appropriate authority to the object, but also must have *ADD data authority
|
||
to the new owner/group user profile and *DELETE data authority to the old
|
||
owner/group profile. These data authorities are not related to the file system
|
||
data authorities. These data authorities can be displayed using the DSPOBJAUT
|
||
command and changed using the EDTOBJAUT command. This also pops up unexpectedly
|
||
on COPY when it tries to set the group ID for a new object.</li>
|
||
<li>The MOV command is prone to puzzling authority errors, especially when
|
||
moving from one physical file system to another, or when performing data conversion.
|
||
In these cases, the move actually becomes a copy-and-delete operation. Therefore,
|
||
the MOV command can be affected by all of the same authority considerations
|
||
as the COPY command (see 7 and 8 above) and the RMVLNK command, in addition
|
||
to other specific MOV considerations.</li>
|
||
</ol>
|
||
</div>
|
||
<p>When using the integrated file system APIs, you can restrict access to
|
||
objects as you can when using data management interfaces. Be aware, however,
|
||
that adopting authorities is not supported. An integrated file system API
|
||
uses the authority of the user profile under which the job is running. </p>
|
||
<p>Each file system may have its own special authority requirements. NFS server
|
||
jobs are the only exception to this rule. Network File System server requests
|
||
run under the profile of the user whose user identification (UID) number was
|
||
received by the NFS server at the time of the request. Authorities on your
|
||
server are the equivalent of permissions on UNIX<sup>®</sup> systems. The types of permissions
|
||
are read and write (for a file or a directory) and execute (for a file) or
|
||
search (for a directory). </p>
|
||
<p>The permissions are indicated by a set of permission bits, which make up
|
||
the "mode of access" of the file or directory. You can change the permission
|
||
bits by using the "change mode" functions chmod() or fchmod(). You can also
|
||
use the umask() function to control which file permission bits are set each
|
||
time a job creates a file. </p>
|
||
</div>
|
||
<div>
|
||
<ul class="ullinks">
|
||
<li class="ulchildlink"><strong><a href="rzamvifsapproach.htm">Considerations for integrated file systems security</a></strong><br />
|
||
The <span class="q">"root"</span> (/) file system acts as an umbrella
|
||
or a foundation for all other file systems on the server. At a high level,
|
||
it provides an integrated view of all of the objects on the system.</li>
|
||
<li class="ulchildlink"><strong><a href="rzamvifsrootfiles.htm">Root, QOpenSys, and user-defined file systems</a></strong><br />
|
||
These are security considerations for the root, QOpenSys, and user-defined file systems.</li>
|
||
<li class="ulchildlink"><strong><a href="rzamvifsqsyslib.htm">Restrict access to the QSYS.LIB file system</a></strong><br />
|
||
You can use this information to restrict access to the QSYS.LIB file system.</li>
|
||
<li class="ulchildlink"><strong><a href="rzamvifssecdirectory.htm">Secure directories</a></strong><br />
|
||
To access an object within the root file system, you read through the entire path to that object.</li>
|
||
<li class="ulchildlink"><strong><a href="rzamvifssecnewobject.htm">Security for new objects</a></strong><br />
|
||
When you create a new object in the <span class="q">"root"</span> (/)
|
||
file system, the interface that you use to create it determines its authorities.</li>
|
||
<li class="ulchildlink"><strong><a href="rzamvifsqfilesvr.htm">QFileSvr.400 file system</a></strong><br />
|
||
With the QFileSvr.400 file system, a user (USERX) on one iSeries system (SYSTEMA) can access data on another connected iSeries system (SYSTEMB).</li>
|
||
<li class="ulchildlink"><strong><a href="rzamvifsnetwork.htm">Network file system</a></strong><br />
|
||
The Network File System (NFS) provides access to and from systems that have NFS implementations.</li>
|
||
</ul>
|
||
|
||
<div class="familylinks">
|
||
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamvplanrscsec.htm" title="This topic describes each of the components of resource security and how they all work together to protect information on your system. It also explains how to use CL commands and displays to set up resource security on your system.">Plan resource security</a></div>
|
||
</div>
|
||
</div>
|
||
</body>
|
||
</html> |