123 lines
8.6 KiB
HTML
123 lines
8.6 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="Considerations for integrated file systems security" />
|
||
<meta name="abstract" content="The root (/) 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." />
|
||
<meta name="description" content="The root (/) 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." />
|
||
<meta name="DC.Relation" scheme="URI" content="rzamvplanifssec.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="ifsapproach" />
|
||
<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>Considerations for integrated file systems security</title>
|
||
</head>
|
||
<body id="ifsapproach"><a name="ifsapproach"><!-- --></a>
|
||
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
<h1 class="topictitle1">Considerations for integrated file systems security</h1>
|
||
<div><p>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.</p>
|
||
<p>Other file systems that can exist on iSeries™ 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 iSeries applications
|
||
and servers (including the iSeries Access for Windows<sup>®</sup> file server) to access the CD-ROM
|
||
drive on the iSeries server.
|
||
Similarly, the QFileSvr.400 file system allows applications to access integrated
|
||
file system data on remote iSeries servers. The QLANSrv file server allows access
|
||
to files stored on Integrated xSeries<sup>®</sup> Server for iSeries or
|
||
other connected servers in the network.</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 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 intricacies 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 iSeries server
|
||
authority and POSIX permissions are used together:<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 iSeries 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. For example: <p>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 <span class="q">"root"</span> (/), 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 <span class="q">"root"</span> (/) directory. When experiencing authority
|
||
problems, make sure to check the user’s authorization to the <span class="q">"root"</span> (/)
|
||
directory.</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>
|
||
For more information about a specific file system on your iSeries server,
|
||
you will need to consult the documentation for the licensed program that uses
|
||
the file system.</div>
|
||
</div>
|
||
<div>
|
||
<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> |