HP 3000 Manuals HP 3000 Manuals
Managing a 5.0 POSIX HP 3000 System
Jeff Vance
Commercial Systems Division
Release 5.0 marks a significant change for MPE--POSIX system calls are
now part of the operating system. But POSIX is more complex than
additional C library intrinsics. To support the POSIX APIs, major
enhancements were made to the file system, directory, process management,
Store/Restore, C library and the Command Interpreter. The result is that
for the first time UNIX and POSIX applications can run on MPE/iX with
little or no changes. It also means that system managers need to know
how to manage the POSIX extensions to MPE.
This article will discuss some of the systems management issues related
to POSIX: system backup, disk space management, security, file transport,
system logging, and third-party software. A glossary contains the
definitions of the terms used throughout the article.
POSIX /iX System Management
The evolution of POSIX on MPE/iX places new demands on System Managers.
MPE has become more complex and consequently more difficult to manage.
Today, System Managers have a full workload without extra time to learn
the new POSIX concepts. This section addresses some of the System
Management concerns related to running a production system on MPE/iX
Release 4.5 or later.
It should first be mentioned that the topics below mostly apply to sites
that will be running both MPE and POSIX applications. If your shop has
no immediate interest in POSIX you have several options:
* You can update to Release 5.0 and take advantage of the new
SETCLOCK command or wildcarded PURGE, but not use the POSIX
extensions. If most of your users are trapped into applications
at logon, they will not notice any difference. More importantly,
they cannot create any HFS objects, which means the System Manager
doesn't really need to be POSIX knowledgeable. You can take
comfort in knowing that HFS named files are not created
automatically by the operating system (other than those on the FOS
tape), and users need to take deliberate action to build a POSIX
named object. Remember that BUILD a still creates the file
uppercase "A" in your logon group (as long as you have not changed
your CWD, which would not likely be accidental). Production jobs
and programs will behave the same. You can restrict use of the .2
shell by adding a lockword; however, a better approach to limit
access to the shell and utilities is to add ACDs to all program
files in the HPBIN.SYS group.
* You can stay on Release 4.0.
* You can update to 5.0 and purge all of the FOS HFS files and the
HPBIN.SYS group. This will save you some disk space, but will not
prevent a user from creating an HFS object.
System Backup.
The most popular concern shared by System Managers is "what if someone
accidentally creates an HFS file or directory?". They are usually afraid
that it won't get backed up by their standard backup procedures. On
Release 4.5, the STORE program reported a warning and required an
operator reply if it determined that a system backup was requested but
MPE syntax was specified.
The easiest case is to understand is STORE @.@.@. Clearly a full backup
is desired, however the "@.@.@" signifies (to 4.5) only MPE legal
filenames. This excluded all HFS objects on the system, including the
files and directories supplied by HP. In this situation, STORE tried to
warn the operator that not all files on the system would be backed up.
The 4.5 System Manager was encouraged to change all of her backup jobs to
use STORE / rather than @.@.@, where "/" means root and all objects below
it.
For customers that really intended to only backup MPE named files, the
4.5 version of STORE also contained a new option called NOHFSWARN to
suppress the warning and operator reply.
In Release 5.0 STORE was changed to recognize that @.@.@ means all files,
including directories, lowercase named files, symbolic links, etc.
Production store jobs do not need to be modified to account for POSIX
filenames or directories. Of course, HFS syntax is fully supported by
STORE too. Following shows the name translations done by STORE in
Release 5.0.
@.@.@ -----> /
@.@.account -----> /ACCOUNT/
@.@ -----> /LOGON_ACCT/
@.group -----> /LOGON_ACCT/GROUP/
@.c@v -----> /LOGON_ACCT/C@V/
@ -----> ./@/
j@ -----> J@ (not translated)
The translation rule is simple: if the first component of an MPE name is
"@" then the full MPE name is converted to an HFS name, with logon
account and group filled in if necessary.
The trailing slash ("/") at the end of the HFS pathname is
significant--it indicates a recursive operation. In the case of STORE, a
trailing slash means to store the target object and all objects below it.
This behavior is consistent with the DISKUSE, LISTFILE and PURGEDIR
commands. The 4.5 NOHFSWARN option is recognized but ignored in Release
5.0. This option should no longer be used and will be phased out.
What if you want to backup all of your MPE-named files? @.@.@ will be
translated to "/", and /@/@/@ will match directories and lowercase
files--so neither works. The trick is to cause the first component of
the MPE filename to not equal "@", but still match all files. This is
accomplished by: :STORE ?@.@.@.
STORE tapes created on 4.5 and 5.0 can be RESTOREd to earlier systems.
In Release 4.5 the STORE tape format changed such that as soon as the
first HFS-named object is encountered, a file named HFSMAP is written to
tape. This file contains the mapping of all hierarchical names to the
simple, three tier MPE name space.
For example, the HFS file "/users/selmer/bin/4.7/temp.a" might map to
"F0000001._HFSGRP._HFSACCT". There is one entry in the HFSMAP file for
each HFS object selected by STORE.
If a 5.0 store tape is restored to a 4.0 system via RESTORE ;@.@.@, the
F0000001 through F00n files are not restored because their group
("_HFSGRP") and account ("_HFSACCT") names are illegal. However, the
HFSMAP file can be restored locally and the desired HFS files can be
restored by wildcarding the group and account names.
For example, suppose F0003729 is the MPE name for the desired HFS file,
RESTORE ;f0003729.@hfsgrp.@hfsacct will restore the file. Similarly, all
HFS files can be restored to earlier systems via
RESTORE ; f#######.@hfsgrp.@hfsacct; local. The HFSMAP file can be used
to see the actual HFS filename that was restored.
When HFS named files are restored to pre-POSIX systems the data is
intact, with one exception. Most likely the HFS named files were
protected by ACDs, and STORE has preserved the ACDs on tape. However,
systems prior to Release 4.5 do not understand these ACDs since the
internal ACD version number has rolled in 4.5. These files are restored
with their Release 4.5 version ACDs, but these ACDs are not recognized on
earlier systems, and therefore are considered corrupt. ALTSEC ;DELACD
can be used to remove the ACDs.
The above discussion pertains to the unexpected moving of HFS files to
pre-POSIX systems. If you are planning on transporting POSIX named files
to Release 4.0 or earlier then you should use the new TRANSPORT=MPEXL
parameter. When MPEXL transport method is specified, STORE converts the
ACD (which may contain $OWNER and $GROUP subjects) to a pre-POSIX ACD
version. The HFS name mapping described above is still relevant, but the
ACDs will be functional after the file is restored. Please refer to the
article "Creating Pre-POSIX Compatible Tapes" in this chapter of the
Communicator.
Disk Space Management.
As with most new versions of the MPE operating system, the POSIX release
requires additional disk space. The new HPBIN.SYS group, which contains
the .2 shell and utilities, uses approximately 105,000 sectors (27
Megabytes) of disk space. The hierarchical directories and files
supplied with FOS consume an additional 179,000 sectors (46 Megabytes) of
space. There is an effort being made to reduce the disk space
requirements for future releases, but this is the current situation.
(These measurements were taken after installing the Alpha version of 5.0
(FOS SLT only).)
If all files in the HPBIN.SYS group and all objects in the hierarchical
directory are purged, approximately 73 Megabytes of disk space can be
reclaimed. HP does not recommend this action in the long run because
business applications may rely on the services provided by these files;
however, currently the operating system has no dependencies on any of
these files. Release 5.0 requires approximately 500 Mb of disk space on
LDEV1. If you are using HP 7933 or 7935 disk drives for LDEV1 they will
need to be replaced with newer drives. The SCSI disks, HP-FL C22x
drives, HP C2202(3)A drives and HP 7937s are all supported. Some HP 3000
Series 950s, 955s, 960s and 980s manufactured prior to June 1991, may not
support SCSI disk drives without an Input/Output Dependent Code (IODC)
firmware upgrade.
To see all of the new HFS objects use the LISTFILE command:
:LISTFILE /[a-z]@/ ,6
This displays all lowercase file and directory names under root, and for
directories, it will list all files and subdirectories. The trailing "/"
induces this recursive behavior and is equivalent to specifying the TREE
command line option. This LISTFILE fileset shows all FOS HFS files
because there are currently no FOS HFS files with uppercase names, and
account names don't match the lowercase pattern. (Remember MPE-escaped
syntax is case sensitive.) An alternate method, which does not rely on
upper versus lowercase names, is:
:LISTFILE / ,6; seleq=[object=hfsdir]
However, this command only lists HFS directory names--the files in the
directories do not match the selection equation.
The REPORT command is a familiar way to determine how much disk space has
been consumed by each MPE group. The current REPORT command could not be
enhanced to support POSIX directories, and since these directories have
no user connection (e.g., no CPU limits), a new command was designed to
report disk space used for all directories, including MPE accounts and
groups. The new DISKUSE command accepts a directory name in either MPE
or MPE-escaped syntax, and reports the number of sectors of disk space
used by that directory. The name can be wildcarded, and the output is
always in HFS format. For example:
:NEWACCT a,mgr
:NEWGROUP g1.a
:NEWGROUP g2.a
:COPY editor.pub.sys, .g1.a
:COPY catalog.pub.sys, .g2.a
:DISKUSE /A
SECTORS
TREE LEVEL DIRECTORY
BELOW
4720 96 /A/
This shows the A account using 4,720 sectors of disk space, of which, 96
sectors are consumed by the three groups under A. REPORT @.A shows 4,592
sectors. The difference of 128 sectors is the space used by the
directory nodes themselves--the 96 sectors used by the three groups and
32 sectors consumed by the account entry.
:DISKUSE /A ;tree
SECTORS
TREE LEVEL DIRECTORY
BELOW
336 + 304 /A/G1/
4320 + 4288 /A/G2/
32 + 0 /A/PUB/
4720 96 /A/ (32 +)
The TREE option (which is equivalent to supplying a trailing "/" in the
directory name) displays information for all directories under the A
account. The first line shows that 304 sectors are used for all files
and directories under G1 (namely EDITOR). A LISTFILE /A/G1,2 reveals that
G1 uses 32 sectors itself, and so the total amount of space used by G1
and all objects under it is 336 sectors. The second line of output can
be similarly analyzed. Line three shows that the PUB group has no
objects under it, but still contributes 32 sectors to the total. The
final line reports the same totals as the previous DISKUSE command, and
shows that the directory entry A consumes 32 sectors itself. The "+"
indicates a subtotal for each directory one level below the target name.
Also all "+" values add up to the total under the TREE column.
MPE System Managers are accustomed to setting limits on the amount of
disk space that a particular account can consume. Each account can also
partition disk space among its groups. POSIX does not define any disk
space limits, and thus this concept is not part of the POSIX hierarchical
directory specifications. hnical reasons, MPE/iX has also not
implemented directory based disk space limits. There are significant
performance implications if limits are not carefully designed.
Meanwhile, what is the impact of having directories without limits?
First, all directories created under MPE groups are bounded by the group
limit, so this space is easily controlled. Second, only users with SM
capability can create directories directly under root. So the exposure
is reduced but not eliminated for two reasons:
1. The System Manager can alter the ACD on a directory under root,
giving CD access to one or more users, and there is no way to
restrict the space used by these users.
2. POSIX, by convention, defines a directory named /tmp which needs
to grant all accesses to all users. /tmp is supposed to be
managed as a temporary work space.
The first problem is solved by taking care when altering the ACDs on
files and directories. Perhaps products like SECURITY/3000 from VESoft
will become ACD aware and report all directories that give away CD
access. Command files can be written to parse the output of a LISTFILE
,-2 command looking for access violations. The second problem is
probably easier to solve. Simply stream a job each night that purges all
files under /tmp. For example, the commands CHDIR /tmp followed by
PURGEDIR /tmp/ ;noconfirm deletes all objects under, but not including,
/tmp. A job can also be streamed at system start up that shows the
amount of disk space in /tmp, e.g., use the DISKUSE /tmp/ command. It is
also possible to alter the ACD on /tmp to restrict access to everyone
except the users of POSIX applications that rely on /tmp.
If the above ideas are not suitable for limiting disk space consumption,
and your site will be running POSIX applications, symbolic links may be
an attractive work around. The essence of this approach is to trick
POSIX applications into seeing all files as residing in the hierarchical
file system, but, in fact, these files actually live in MPE groups with
disk space limits. The following steps show you how:
1. Backup your HFS files, for example:
:STORE /[a-z]@/
2. Purge these files via the PURGEDIR /[a-z]@ and PURGE /@ commands,
which remove all HFS objects.
3. Create an account and some groups to partition disk space for your
POSIX applications. Assume the account is named PXACCT and the
groups are APP1 and APP2. For each directory directly under root
create a symbolic link of the same name that points to one of the
APPx groups. For example,
:NEWLINK /tmp, /PXACCT/APP1 and
:NEWLINK /usr, /PXACCT/APP2, etc.
Symbolic links are discussed in the article "Symbolic Links on
MPE/iX" in this chapter of the Communicator.
4. Restore all files and directories one level below root, for
example,
:RESTORE ; /@/@/;create
These files will actually be restored to one of the MPE groups
defined above. One problem is that a LISTFILE /[a-z]@ ;tree only
shows the symbolic link files; whereas, previously it listed all
HFS files. Also, if HFSDIR objects are selected via the SELEQ=
parameter the symbolic links under root will not match. However,
LISTFILE /[a-z]@/@/ does display all the HFS objects with their
original names.
User volumes are recommended as a safe and speedy way to perform backup
and recovery operations. Unfortunately user volume sets are not yet
fully supported in POSIX/iX. The good news is that all files and
directories created at any level under an MPE group which is linked
(HOMEVS'd) to a user volume are built on the user volume set, not the
system volume set. However, all objects created directly under an
account or under root reside on the MPEXL_SYSTEM_VOLUME_SET and cannot be
directed to a user volume set. POSIX.1 mentions the concept of a
mountable file system as a mountable subset of a complete file hierarchy,
but leaves its full definition implementation specific. MPE has deferred
the design of mountable file systems, but we envision it as a super set
of today's user volume sets.
In the meantime, symbolic links can be used to force all files under an
arbitrary directory node to reside on a user volume set in the same
manner as symbolic links were used to apply limits to directories in the
hierarchical name space. The idea is to create MPE groups that are
HOMEVs'd to user volume sets. Then, rather than building a directory
named /usr/app1, create a symbolic link of the same name which "points"
to a group linked to a user volume set. For example:
:NEWGROUP g1.a1;onvs=user_vs1
:NEWGROUP g1.a1;homevs=user_vs1
:NEWLINK /usr/app1, /A1/G1
Now when a POSIX application creates a file named /usr/app1/xyz it will
actually be created on the USER_VS1 volume set as /A1/G1/xyz. One caveat
is that the filename component cannot exceed 16 characters since the name
is actually directly under a group.
Security.
The two biggest concerns for System Managers regarding POSIX security
are:
1. Lack of a comfortable understanding of ACDs
2. The inability of ACDs to provide mandatory control vis--vis matrix
security.
The MPE/iX ACD enhancements are discussed in the article "MPE/iX File
Access and Security Enhancements" article in this chapter of the
Communicator.
The second problem already exists since a released file is exempt from
matrix security policies. However, security conscious sites have worked
around this "feature" by disabling the RELEASE command (including
programmatic calls via the COMMAND intrinsic), and monitoring the system
for released files. Similar solutions may be needed for files and
directories protected by ACDs.
The first problem is equally challenging to solve. Even though ACDs have
been available since Release 3.0, few customers use them. Part of the
reluctance is the sense that ACDs are separate from the core operating
system and not well integrated with subsystems. Release 5.0 marks the
beginning of better ACD integration--COPY, RENAME, STORE and EDIT/3000
are ACD aware. Another reason that ACDs are not popular is that most
third-party software does not support ACDs. Since ACDs are seldom used,
most System Managers have little knowledge of or experience with ACDs,
and this represents a hurdle for System Managers who need to run a mixed
MPE and POSIX shop.
The following HP manuals contain information on ACDs:
* Security Monitor/iX User's Guide (32650-90454)
* Security Monitor/iX: Manager's Guide (32650-90455)
These two manuals are new for Release 5.0.
The 5.0 manual New Features of MPE/iX: Using the Hierarchical File System
(32650-90351) also describes ACDs and the POSIX security extensions.
The rules for purging files need to be understood since MPE now supports
directories and the POSIX unlink() function, which is invoked by the
Shell's rm command. The MPE PURGE command still FOPENs the target file
and then removes it via FCLOSE(,4). All security rules apply such that
if the file is already opened, is being STOREd, is allocated, the user
lacks write access, etc., it will not be purged. If the file has a
lockword then the lockword must be supplied with the filename or it will
be prompted for. Because PURGE calls FOPEN, individual file access rules
must be obeyed before the file can be deleted, regardless of the access
permissions of the file's parent directory. PURGE is the most secure way
to delete a file and, even though it accepts POSIX pathnames, it will not
remove directories.
PURGEDIR is the CI command to delete one or more directories. In fact,
PURGEDIR, PURGEGROUP and PURGEACCT all behave the same for deleting files
under the target object. Since none of the files under a group, account
or directory are individually opened, each file will be deleted
regardless of its individual file security, unless it is already
opened by another process, or is being STOREd. For example, if
/ACCT/GROUP/DIR1/DIR2/F1 has an ACD which prevents Mike from deleting it
(which it does by default assuming he is not the owner) then he will get
CIERR 384 if he attempts to PURGE F1. On the other hand, if DIR1
and DIR2 grant TD and DD access for Mike then he can PURGEDIR
/ACCT/GROUP/DIR1/DIR2 ;tree successfully and in the process delete F1.
An interesting point is that even though Mike has DD permission for DIR1
he cannot PURGEDIR /ACCT/GROUP/DIR1 ;tree since, in this example, the
parent to DIR1 is an MPE group, and he does not have DD access to GROUP,
unless he has save access to the group. PURGEDIR is able to delete
lockworded, privileged and protected files. The same mechanism applies
to PURGEGROUP and PURGEACCT with the additional requirement that AM or SM
capabilities are necessary in invoke these commands, since accounts and
groups cannot be protected by ACDs.
The POSIX unlink() function, and hence the Shell's rm command, are
somewhere in between PURGE and PURGEDIR[ACCT/GROUP] in terms of file
security. Since unlink() does not open the target object, the object's
individual access rules are ignored and thus unlink() is potentially less
restrictive than PURGE. Also, since the file is not opened, it cannot be
protected by a lockword or unlink() will fail--there is no lockword
prompting.
To unlink a file requires TD access to the entire pathname and DD access
to the file's parent directory, or the equivalent if the file's parent is
an MPE group (see the article "MPE/iX File Access and Security
Enhancements" in this chapter of the Communicator. Lockworded,
privileged or protected files cannot be unlinked.
This implication of PURGE versus rm versus PURGEDIR to system managers is
that PURGE is the preferred way to delete a file. If that fails then use
the Shell's rm command. Rm can also to delete directories via the -r
option. Both PURGE and rm accept wildcards. If the file still cannot be
purged then the directory contents (minus the file in question) can be
copied or STOREd, followed by a PURGEDIR. If your CWD is the target
directory then it will not be purged, but all other objects under it will
be deleted, given the caveats mentioned above. This is analogous to
changing your group to G1 then issuing a PURGEGROUP G1 command--all files
in the group are purged but the group remains intact.
File Transport.
Network Services (NS) is not POSIX aware in Release 5.0. Therefore, to
transfer POSIX-named files from one machine to another requires a little
creativity:
1. The HFS-named files can be copied to legal MPE filenames in MPE
groups, and then your site's standard procedures can be followed.
2. A file equation can be created for each HFS named file to be
transferred. For example:
:FILE x=/test/filex
:DSCOPY *x; filex:nodename
3. FTP.ARPA.SYS can be used to transfer files. FTP is HFS aware on
MPE/iX, but using FTP may change current system management
procedures.
4. STORE can be used to transfer files via tape.
System UDCs.
A UDC file named HPPXUDC.PUB.SYS is part of the Release 5.0 FOS tape.
This file is not automatically cataloged. It contains several useful
UDCs such as:
* FINDFILE which locates a filename at any depth in the directory.
* FINDDIR is similar to FINDFILE but finds directories rather than
files.
* LISTDIR shows information about a directory.
* PLISTF UDC supports the MPE-escaped syntax for both the fileset
and output listfile parameters.
The four UDCs mentioned above were implemented by invoking the LISTFILE
command, and are worth reading to learn more about LISTFILE. For
customers habituated to typing "disk" as "disc", there is a DISCUSE UDC
that executes the DISKUSE command.
System Managers may choose to catalog HPPXUDC at the system, account or
user level. The file may be modified to better support your specific
requirements.
System Logging.
The new system logging events mentioned in the "System Logging Changes"
article in the "System Management" chapter are enabled via SYSGEN and are
available only in Release 5.0.
Event 155 controls whether or not to recognize the file open (144) and
file close (105) events when the target file is an HFS directory. If the
file is root, an account, or an MPE group no logging occurs regardless of
the setting for event 155. If event 155, 105 and 144 are all enabled
then every time a directory is opened and closed two log records are
generated. The shell's ls command, LISTF and LISTFILE open and close
each directory listed, so there is potential for large log files. Note:
not all directories in the pathname are logged, only directories that
need to be "officially" opened. For example,
:LISTFILE /a/b/c ;tree
only has to open directory "c" in order to read its entries (object
names); whereas,
:LISTFILE /a/b@/c ;tree''
must open directory "a" (to find if a has any "b@" entries), in addition
to directory "c".
Event 127 enables chdir logging. This may be important since the
filenames logged for the other events may not be absolute pathnames.
With chdir logging operative, these relative pathnames can be "qualified"
with the user's CWD. Chdir logging takes place for the POSIX chdir()
function and the CHDIR command.
Event 129 enables chown logging. This event is triggered whenever the
POSIX chown() function or the ALTFILE command are successful. Event
129 should be enabled for all systems that currently log other
security-related events. The POSIX chmod() function and the ALTSEC
command are captured via the ACD change logging event (138).
Some HFS events do not log fully qualified (absolute) filenames.
Specifically, ACD change (138), file open (144), chdir (127) and chown
(129) do not qualify any of the logged filenames. If your site will be
using HFS names, and will enable any of the above logging events, and
will require absolute pathnames, independent of how the user specified
the names, then you will need to interrogate the log files for
job/session logon (102), and chgroup (143) events. This is necessary in
order to construct absolute pathnames for any relative filename logged by
events 138, 144, 127 or 129.
Third-Party Software.
A concern of System Managers is that the third party tools that they rely
on for their production work will not function correctly in an HFS
environment. HP has been working with many software vendors to teach
them about our POSIX release, and to help them make their products POSIX
aware. Obviously, many of the tools will not be fully operative in a
POSIX environment in the 5.0 time frame. The important question to ask
is "Does this tool need to handle HFS objects for my business to be
successful?". For most customers the answer is "no", since most sites do
not have immediate POSIX requirements. Those customers dependent on
POSIX need to ensure that their corresponding business tools work
satisfactorily in a POSIX atmosphere. HP will be able to provide
information about third party products that are POSIX aware.
Conclusion
The POSIX release of MPE/iX is of significant value to customers that
desire to further protect future software investments by developing and
purchasing opens applications. For MPE users who have always wanted
another group under a group, or have complained that they need just a few
more characters for a meaningful filename, or need to prevent ordinary
users from being able to do a LISTF and see every file on the system, the
POSIX enhancements to MPE should be welcomed.
POSIX on MPE/iX benefits from the strengths of MPE: excellent
price/performance, high availability, superior OLTP, and number one in
support..
POSIX doesn't come for free though. System Managers need to understand
the fundamental concepts discussed in this paper. Additional disk space
is required. Third-party software suppliers need to be told your
expectations for POSIX support. The transition to taking advantage of
POSIX and the hierarchical file system may not be easy; however, for most
customers it will be worth the effort.
Glossary
$GROUP - A new ACD subject for which access control can be specified.
$GROUP differs from an @.account subject because a file's group ID (GID)
can be altered, and thus $GROUP access control can refer to a different
collection of users over time.
$GROUP_MASK - A new ACD subject needed to make ACDs a viable POSIX
alternate security mechanism. $GROUP_MASK is an additional filter for
determining a file's group class access. It may be set explicitly via
:ALTSEC, or indirectly via the POSIX chmod() function.
$OWNER - A new ACD subject for which access control can be specified.
$OWNER differs from a user.account subject because a file's owner ID can
be altered, and thus $OWNER access control can refer to a different owner
over time.
ACD - Access Control Definition - A security mechanism whereby all access
control to an object is defined as part of that object. ACDs are more
expressive than matrix security since certain accesses can be granted to
individual users or groups of users. ACD is a proprietary name for
Access Control Lists (ACLs) which will be the key security component of
POSIX.
account - An MPE directory directly under root. All account names follow
traditional MPE name rules (e.g., 8 character maximum length, begins with
a letter, no special characters, etc.). Accounts still contain
capabilities, matrix access and limits.
AM capability - Account Manager - Users with AM capability can create
user and groups within their logon account. They can also access all
files in their account. In POSIX terms, the Account Manager can access
all files whose file group ID matches their user GID.
API - Application Programming Interface - An external, documented
procedure.
byte-stream file - A file without any formal record structure. Each
logical "line" in the file is terminated by the newline (linefeed)
character.
chmod - A POSIX.1 function to change read, write and execute access for a
file or directory.
chown - A POSIX.1 function to change the ownership and group ID of a
file.
CI - Command Interpreter - A program (CI.PUB.SYS) created at logon time
which is the MPE equivalent of the POSIX shell. The CI is responsible
for prompting, reading command input, command execution, servicing break
and error handling.
compatibility mode (CM) - A CM program or procedure emits classic 3000
instructions which are emulated or translated to the native instructions
set.
component (of a pathname) - A name delimited by a "/". Typically a
component is a directory name, except when it is the last component,
where it could also be a filename. "Last" refers to the rightmost
component of a POSIX pathname.
CWD - Current Working Directory - The directory, which often is your
logon group, where you are currently located. Moving your CWD has no
affect on your file access--it is only a naming shortcut.
device link - A file that is linked to an LDEV number such that opening
the device link is identical to opening a device via its LDEV number.
directory - A file that has a directory record structure. Generically,
MPE groups, accounts and root are directories. In fact these directories
have special name length restrictions (16 characters vs. 255) since
these objects are part of the traditional directory structure. HFS
directories must be protected by an ACDs, but in 5.0, root, accounts and
MPE groups cannot have ACDs.
FIFO - A type of file with the property that data is always read and
written in a first-in-first-out manner..
file - File can be used to describe a directory, byte-stream, symbolic
link, device link, etc. Basically all objects in the HFS are implemented
as files.
file group - The class of users who are not a file's owner, but match one
of the $GROUP, user.account, or @.account ACD subjects. These user's GID
match the GID of the file. In MPE terms they are in the same account as
the file.
file owner - The class of users whose UID match the owner ID of the file.
In MPE terms they are the creator of the file.
file other - The collection of users who are not file owners nor members
of a file's group class. In an ACD pair "@.@" is the file other subject.
FOS - Fundamental Operating System - The core operating system without
any optional subsystems.
GID - Group IDentification - A GID identifies users as members of a
file's group class. These users can have unique file access defined for
them. POSIX defines a GID as a number. It is simulated as a number in
MPE, but the user's account name is currently the basis for security.
group - An MPE directory directly under an account. MPE groups have
access rules and capabilities associated to them. For the POSIX group
definition see file group and GID.
HFS (Hierarchical File System) - The MPE/iX directory and file system
which allows files and directories to be at an arbitrary level under the
root directory. HFS is often used synonymously with "POSIX-named" to
indicate that the object is not part of the traditional MPE file, group
and account structure.
HPGID.PUB.SYS - The name of the POSIX group database file. This is where
all account names and their associated GID are stored. This file is
automatically created when updating to 5.0. In 4.5 a utility program
(PXUTIL) is used to synchronize the databases with the actual directory.
This synchronization is not needed in 5.0.
HPUID.PUB.SYS - The name of the POSIX user database, where the
user.account names and associated UID numbers are stored.
matrix security - A mandatory security mechanism where access is
established at the account, MPE group and file levels. Typically, access
is more restrictive as you move down from account to group to file.
Matrix security allows a System Manager to shut off a certain access to
all users by disallowing it at the account level. A released file is
exempt from matrix security.
native mode (NM) - Native mode execution means that a program or
procedure directly calls the machine's native instruction set.
NL.PUB.SYS - The operating system's XL (executable library). The NL is
the final point for binding external procedures.
object - A generic term for files, directories, root, MPE groups and
accounts.
owner - See file owner and UID.
pathname - The POSIX equivalent to a filename. Pathname can refer to the
complete, "fully qualified" name (absolute pathname), or the name
relative to your CWD (relative pathname).
pipe - A pipe consists of two file descriptors connected such that data
written to one can be read by the other in a first-in-first-out manner.
released - a file is released via the RELEASE command, which disables
group and account level security. The inverse operation is performed by
the SECURE command.
root (/) - The origin of the directory structure. Root cannot be
protected by an ACD. Object names under root cannot exceed 16 characters
in length. Only SM can create objects under root. If a pathname begins
at root it is an absolute pathname.
shell (.2 Shell) - A program that serves the purpose of the Command
Interpreter, but is POSIX compliant. Currently the shell must be run
from the CI.
SM capability - System Manager - Users with SM capability are in charge
of the entire system. They can create accounts and directories under
root. They can access all files on the system.
streams - A streams device is a bi-directional, character oriented
connection between a file and typically a device driver.
subject (of an ACD) - The target of an ACD rule. For example, :ALTSEC
file1; repacd=(R:mgr.test) restricts all users logged on as mgr.test to
being granted only read access to FILE1. Mgr.test is the ACD subject.
symbolic link - A file that "points" to another object (e.g., file,
group, account, directory, symbolic link). When a symbolic link name is
encountered in a pathname it is substituted with its target name.
type manager - A file system module responsible for handling all file
system operations for a particular type of file. Operations include:
read, write, control, close, etc.
UDC (User Defined Command) - A collection of zero or more CI commands
given a name, which must begin the first line of the UDC. One or more
individual UDCs are placed in the same file, which is "cataloged" by the
SETCATALOG command. The CI searches for UDCs before built-in commands
and command files.
UID (User IDentification) - A unique identification for every user on the
system. POSIX implements this as a number. MPE/iX currently maintains
both a number in the HPUID.PUB.SYS database for use by POSIX applications
(and process signals), and a string ID in the form of user.account for
all other needs.
user id - see UID.
wildcard - Traditional MPE wildcard characters are: "@"- match zero or
more of any legal character, "?" - match a single legal character, and
"#" - match a single numeric character. POSIX syntax expands the range
of legal characters to include lowercase, "_", "." and "-". A range or
group of characters is expressed as "[abc]" or "[a-c]", which both
indicate to match the letters "a", "b" or "c".
1. The access defined by $GROUP_MASK is bit ANDed with the access
defined for the matching file group subject to determine the final
access. This is necessary because a file's group class contains
both MPE and POSIX elements. For instance, user.account and
@.account are MPE subjects, whereas, $GROUP is a POSIX subject.
In order for the POSIX chmod() function to be compliant,
$GROUP_MASK is set when any of the MPE forms of a file's group
class already exist in the ACD. For example, assume the ACD for
FILE1 is:
R, X : @.myacct
R, W, X : you.myacct
R, L, X : $group_mask
The three ACD pairs above contain subjects that make up a file's
group class of accessors. In this example, the file owner and
"other" classes have not been defined. "Other" refers to all
potential accessors who are not the file's owner and do not belong
to the file's group class. "Other" is the @.@ ACD subject. Any
user logged on to MYACCT is given read and execute access to
FILE1--the $GROUP_MASK does not restrict access. However, if the
user you.myacct tries to access FILE1 he will not get write access
because $GROUP_MASK denies write access. The result of the
specific you.myacct access ANDed with $GROUP_MASK is read and
execute access only. So, $GROUP_MASK acts as a filter that can
further restrict access for the file's group class of users.
2. If the target directory is an MPE group, CD access is defined as
the user possessing SF capability and having save access to the
group. MPE groups do not support ACDs and thus cannot directly
grant CD access.
3. If the target directory is an MPE group, DD access to the group is
defined as having write access to a particular file within the
group. MPE groups do not support ACDs and thus cannot directly
grant DD access.
4. In general, an ACD is required whenever a file's GID does not
match the GID of the account the file is located under. If a file
is not under an account an ACD is always necessary.
5. Technically, the user's GID must match the GID of the MPE group's
account.
6. The distinction between directories and symbolic links versus
files for granting DD access to an MPE group is for backwards
compatibility. We would prefer a rule that states that save
access to a group grants both CD and DD access to the group for
all objects contained within the group. However, in all MPE
releases, files within a group cannot be deleted without the user
having write access to the target file. So to ensure that the
write access rule is not broken, the distinction is made between
"old" file types (including byte-stream files) and the new POSIX
files such as directories and links.
7. These measurements were taken after installing the Alpha version
of 5.0 (FOS SLT only).