Who Can, Who Cannot... [ Understanding Your System ] MPE/iX 5.0 Documentation
Understanding Your System
Who Can, Who Cannot...
Capabilities are assigned, and they determine the extent to which you, or
any other user, can make full use of the computer's facilities.
Capabilities are assigned to these elements:
* users (user names)
* accounts (account names)
* groups (group names)
* certain commands, programs, and processes within the computer
On most MPE/iX computers, you will find that there is a hierarchy of
capabilities. Some users have more capabilities, or more powerful
capabilities, than others.
This arrangement of capabilities can be tailored to meet the needs of
your organization.
As a generalization, the range of capabilities, from low to high, is
likely to be something like this:
* Someone who can log on to only one group in an account generally
has the smallest set of capabilities.
* Someone who can log on to several--or all--of the groups in an
account generally has a larger set of capabilities.
* Someone who can log on to several different accounts generally has
an even larger set of capabilities.
* Someone who can log on at the console as OPERATOR.SYS or as
MANAGER.SYS has the largest set of capabilities.
________________________________________________________________________
|It is possible to give every person using the computer almost full and|
|equal capabilities on the system. |
| |
|The potential for confusion and disruption of the system is too great |
|to make this practical or desirable. Equally troubling, such an |
|arrangement would reduce the security of files and programs on the |
|system. |
________________________________________________________________________
In charge of the entire system
At the highest level, capabilities are assigned by the person who plays
the role of system manager on your system. This is the person who knows
how to log on as MANAGER.SYS. Strictly speaking, the system manager is
not a person. Rather it is a user (user name) that has been granted
system manager capability within the SYS account. The computer code for
this capability is SM.
As you might infer, the user that has SM capability has a high "status"
on the computer system and has access to the widest range of programs and
functions. It is the system manager who creates accounts and assigns
them passwords. The system manager can log on to any group in any
account on the system and is able to discover the passwords assigned to
every account, every group, and every user. In addition, the system
manager has the authority to analyze and fine tune the performance of the
system.
In charge, day to day
A less extensive set of capabilities is assigned to the user (user name)
who plays the role of system supervisor or system operator, for which the
computer code is OP. This user can log on as OPERATOR.SYS.
The system operator has day to day responsibility for the functioning of
the system. That may include the creation of accounts. If yours is a
small-size or medium-size organization, the roles of system manager and
system operator may be combined in one person (user).
Other tasks that fall to OPERATOR.SYS may include these:
* monitoring the console to read and respond to messages from users
* controlling the efficient use of peripheral devices, such as
printers, disk drives, and the like
* managing sessions--allowing or restricting activity on the
computer
* managing jobs
* backing up files and restoring them
* starting up and shutting down the system (when that is necessary)
* trouble-shooting problems
In charge of an account
Every account on the system has an account manager (code AM). AM
capabilities are different from OP capabilities, but they include such
things as the creation of users and groups within the account, and the
assignment of passwords and capabilities to users and groups within the
account.
Figure 4-1. Your Account Manager
If yours is a small-size or medium-size organization, the system operator
or system manager may serve as the manager of one or many accounts.
At the group level
Users (user names) that are assigned no extensive capabilities acquire
the abilities that are assigned to the group (within the account) to
which they log on.
As a generalization, groups have the least extensive set of capabilities
in the hierarchy of capabilities. However, the creator of the group (the
account manager, system operator, or system manager (AM, OP, or SM
capability) determines the capabilities that the group will have.
It would make little sense to give to a group capabilities that are
greater than the capabilities of the account in which it resides. In
fact, it is impossible to do so.
Users
For users, these are the default (standard) capabilities:
Code Capability
---------------------------------------------------------------------------------------
IA Interactive Access
This capability allows you to log on and start a session on the computer.
BA Batch Access
This capability allows you to start (batch) jobs on the computer.
SF Save Files
This capability allows you to save your work in a file on the disk.
ND Nonshareable Devices
This capability allows you to send information (files) to printers, tape
drives, and other nonshareable devices. These devices are described as
"nonshareable" because they accept only one file at a time.
If you log on in...
Imagine an account called MYACCT. One of its users is JOHN. Imagine that
this user happens to have only the standard (default) capabilities.
Imagine, too, that this account has these three groups and that they have
minimal capabilities:
* PUB
This is the shared group in MYACCT. The logon is: HELLO
JOHN.MYACCT,PUB.
* MYGROUP
This your home group. The log on is: HELLO JOHN.MYACCT. (You can
log on to your home group without specifying the group name.)
* OTHERGRP
Some other group. The log on is: HELLO JOHN.MYACCT,OTHERGRP
Finally, suppose that there is a file called MYREPORT that you can put
into any one of these three groups to show what happens.
The tables that follow illustrate what you can and cannot do with
MYREPORT if you log on to any one of the three groups.
In each case, you could try to do these things:
* Read the file (the TEXT command found in EDIT/3000);
* Save the file (the KEEP command found in EDIT/3000)
* Erase the file (PURGE)
User JOHN logs on in PUB.
-----------------------------------------------------------------------------------------------
| | | |
| If MYREPORT is in | Read file from PUB? | Save or Erase file from PUB? |
| this group | | |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| PUB | Succeeds | Succeeds |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| MYGROUP | Succeeds | Succeeds |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| OTHERGRP | Fails | Fails |
| | | |
-----------------------------------------------------------------------------------------------
User JOHN logs on in MYGROUP.
-----------------------------------------------------------------------------------------------
| | | |
| If MYREPORT is in | Read file from | Save or Erase file from MYGROUP? |
| this group | MYGROUP? | |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| PUB | Succeeds | Fails |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| MYGROUP | Succeeds | Succeeds |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| OTHERGRP | Fails | Fails |
| | | |
-----------------------------------------------------------------------------------------------
User John logs on in OTHERGRP.
-----------------------------------------------------------------------------------------------
| | | |
| If MYREPORT is in | Read file from | Save or Erase file from OTHERGRP? |
| this group | OTHERGRP? | |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| PUB | Succeeds | Fails |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| MYGROUP | Succeeds | Succeeds |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| OTHERGRP | Succeeds | Succeeds |
| | | |
-----------------------------------------------------------------------------------------------
| | | |
| another group | Fails | Succeeds |
| | | |
-----------------------------------------------------------------------------------------------
Other capabilities
There are other capabilities in addition to the ones mentioned thus far.
Many of these other capabilities serve to restrict the use of very
specialized user names, programs, and processes. In particular, two
special capabilities prevent the unauthorized use of sensitive or
extremely powerful programs: PH (process handing) and PM (privileged
mode).
Whoever manages your computer system, or your account, should be sure to
give you the capabilities you need to do your day to day work. In
general, the specialized and powerful capabilities are reserved for those
who must manage or run your computer system, and in some cases for those
who manage accounts. Unless you have such responsbilities, you are not
likely to need specialized capabilities.
Access control definitions (ACDs)
ACDs are ordered lists of pairs. These pairs consist of access
permissions and user specifications that control the ability to access
and change MPE files, hierarchical directories, and the files within
them. ACDs are applied using the ALTSEC command and take precedence over
other security features, such as lockwords and file access control, such
as read/write access.
For more information on ACDs, refer to Chapters 3 and 9 of the
manual, New Features of MPE/iX: Using the Hierarchical File System,
(32650-90351). For more information on the ALTSEC command, refer to the
Commands Reference (B3813-90011).
User and Group IDs
Each MPE/iX user has an associated user ID (UID). The UID is a string (in
the form user.account) and a corresponding integer value. Additionally,
one or more users can be organized into groups (distinct from MPE groups)
to simplify file sharing. Each group has an associated group ID (GID).
UIDs and GIDs are used in conjunction with other security mechanisms to
control access to objects. Objects are entities that contain or receive
information, such as files, directories, and devices. When files or
directories are created, they are assigned their parent directory's GID
and the UID of the process creating them.
UIDs and GIDs are stored in two databases: HPUID.PUB.SYS holds UIDs and
related user information in a user ID database, and HPGID.PUB.SYS holds
GIDs and related information in a group ID database.
...
MPE/iX 5.0 Documentation