12/17/75  Using the Access Isolation Mechanism

This segment contains notes and suggestions for users who plan to use the
Access Isolation mechanism.


Segment Restrictions: A process cannot write into any segment whose access
class is not equal to the authorization of the process. Since some commands and
subsystems create permanent data segments (in the user's home directory and
elsewhere), with the expectation that they can always write into them, some
care must be taken when logging in greater then system_low.


Directory Restrictions: Since the Access Isolation rules do not permit an
upgraded process (one whose authorization is greater than system_low) to create
subdirectories under directories whose access classes are less than its
authorization, and since your home directory (probably) is system_low, you must
plan ahead and create empty, upgraded subdirectories, at the authorizations you
wish to work at, before you actually login at those authorizations (or new_proc
to them). If you just login an upgraded process without having created a place
to work, you will find that the only directory in which you can create segments
in your process directory...not very useful for permanent work.
See the info file for the create_dir command for information on how to create
empty, upgraded directories.


Quota Restrictions: Upgraded directories must have terminal quotas.
To move more records of quota to an upgraded directory requires that the
authorization of the process be equal to the access class of the parent of the
upgraded directory. Thus, if you run out of quota while in a upgraded
directory, you are stuck. You must new_proc down to the level of its parent,
move more records of quota, and then new_proc back up. The only way to regain
quota which has been moved to the upgraded directory is to (1) delete it, or
(2) get the System Security Administrator to move it back using the
priv_move_quota command.


Mail Restrictions: In order to send and receive mail at various
authorizations, the access class of your ring 1 mailbox (User.mbx) must be
raised to your maximum authorization. This is automatically performed whenever
a mailbox is created; thus, the easiest way to raise the access class is to
delete it and re-create it. Alternatively, the System Security
Administrator may execute the reclassify_sys_seg command to change its access
class.


Command Restrictions: Some commands do not work at all in an upgraded process,
therefore, you must change your start_up.ec to avoid the following commands:
    accept_messages
    check_info_segs
    estimate_bill
    print_motd
  You must be careful when using other commands. Some will work in a limited
fashion when running at greater than system_low. The following is a partial
list of the commands and their restrictions. These commands all create a
segment in your home directory, named User.suffix. The ones which allow you to
specify an alternative segment (abbrev and memo) can be used fully in an
upgraded process by specifying a segment whose access class is the same as the
authorization of the process.
    abbrev (cannot add or delete abbreviations)
    debug (cannot set or reset breaks)
    probe (cannot set or reset breaks)
    memo (cannot add, delete or repeat memos)


Subroutine Restrictions: Some subroutines and I/O modules will not work in all
cases in an upgraded process. For example, the vfile_ I/O module requires write
permission to a file when it is opened for shared use, even if it is only
opened for reading.


                                          -----------------------------------------------------------


Historical Background

This edition of the Multics software materials and documentation is provided and donated
to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. 
as a contribution to computer science knowledge.  
This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology,
Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL
and BULL HN Information Systems Inc. to the development of this operating system. 
Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970),
renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership
of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture 
for managing computer hardware properly and for executing programs. Many subsequent operating systems 
incorporated Multics principles.
Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., 
as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. .

                                          -----------------------------------------------------------

Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without
fee is hereby granted,provided that the below copyright notice and historical background appear in all copies
and that both the copyright notice and historical background and this permission notice appear in supporting
documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining
to distribution of the programs without specific prior written permission.
    Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc.
    Copyright 2006 by BULL HN Information Systems Inc.
    Copyright 2006 by Bull SAS
    All Rights Reserved