Multics Technical Bulletin                                MTB-670
Ring 1 PNT

To:       Distribution

From:     Benson I. Margulies

Date:     07/26/84

Subject:  Moving the PNT to Ring 1


     To meet  the requirement for a  B2 security rating, and
     in  so  doing improve  system security,  integrity, and
     assurance, we  have to provide ring  protection for the
     Person Name Table (PNT).  This MTB describes the design
     changes required.

Comments should be sent to the author:

via Multics Mail:
   Margulies at either System-M, MIT, or CISL-SERVICE.

via Forum:
   >udd>m>mtgs>B2 on System-M

via telephone:
   (HVN) 261-9333, or
   (617) 492-9333


Multics  project  internal  working  documentation.   Not  to  be
reproduced or distributed outside the Multics project without the
consent of the author or the author's management.

MTB-670                                Multics Technical Bulletin
                                                       Ring 1 PNT


     This MTB  is an experiment at  writing something that hasn't
always  been  written lately  --  a design  proposal.   While the
latter section does specify the  user interface changes, they are
small and could have been the subject of an MCR.

     My  intent is  to describe the  changes to  the programs and
databases   to   a  sufficient   level   of  detail   that  other
knowledgeable contributors can understand and review them.

     This  MTB  is  the  product  of  a  fair  amount  of initial
implementation.  In the Answering  Service environment, where the
design of  almost anything is highly  constrained by the existing
modularization,   it  is   very  difficult  to   get  a  complete
understanding of a design without starting the implementation.

     Until now,  I have convened  various rump design  reviews of
one  or  two  people  to   discuss  particular  issues.   Now,  I
understand the design well enough to present it to others.  It is
certainly  possible that  a major  flaw in  our thinking  will be
found.   If that  happens, we  will rework  the implementation as

     In short, this  is an experiment in finding  a middle ground
between "Always  complete all review  before implementation," and
"We'll write the MCR two weeks before the submission deadline."


3.1 Introduction

Moving the  PNT to ring  1 will provide  the following functional

   * Secure audit trails of changes to the PNT.

   * Protection  from  user-ring bugs  in the  various subsystems
     that need to read the PNT.

   * Better separation  of privilege:  fewer  processes will have
     enough access to do exhaustive  scans of the PNT looking for
     passwords.   Currently, all  of the card  input daemons have
     read access to the PNT, with  which they can scan it looking
     for  users  whose  passwords encrypt  identically  to common

     The remainder of the MTB describes the specific changes.

Multics Technical Bulletin                                MTB-670
Ring 1 PNT

3.2 ms_table_mgr_

The  PNT,  URF,  and  MAIL_TABLE  all  use  the  common interface
ms_table_mgr_ to maintain their databases.

The ms_table_mgr_  has no real  data integrity.  Were  a crash to
damage  an  mstb,  the only  evidence  would be  faults  taken by
referencing programs.   Even that is  not reliable.  This  is not
acceptable  for   the  PNT.   If   a  crash  corrupts,   say,  an
authorization, we want to be able to detect it.

In  the  long  run,  FAMIS   facilities  will  be  available  for
high-integrity   administrative   databases.   Until   then,  the
strategy is to detect errors and  to rely on timely copies of the
entire database for recovery.

To this end, we will add checksums to each entry of the mstb, and
keep  a  checksum of  the  data in  the  header that  defines the
structure of  the table.  We  will retain the  existing date-time
updated  fields  in  the  components  of  the  table  as  a quick
validation that there has been no wholesale destruction.

ms_table_mgr_ provides no locking.   The mail table primitives do
their own  locking, but the existing  pnt_manager_ does none.  We
will  add a  conventional set_lock_ lock  to the  mstb to protect
writers  from each  other, and  a change  pseudo-clock to protect

To make  this locking and  checksumming work, we  must change the
calling  sequences  of ms_table_mgr_.   For the  entrypoints that
retrieve entries (find_entry, find_entry_case_ins, abs_entry), we
will add a two parameters:  a write_flag, and a change_clock.  If
the write_flag is on then the caller intends to modify the entry.
In  this case,  ms_table_mgr_ locks  the table,  finds the entry,
sets  the "inconsistent"  bit in  the entry,  and returns  to the
caller under the lock.  Setting the inconsistent bit guarantees a
checksum failure.   When the caller  has completed the  update it
calls ms_table_mgr_$update_entry.  This clears the "inconsistent"
bit, recalculates the checksum, and unlocks the database.

If  the  write_flag is  off,  then no  locking  is done,  but the
current value of the change p-clock is returned.  When the caller
has      finished      with      the      entry      it     calls
ms_table_mgr_$get_change_count to get the new value of the change
clock.  If it is different than the value returned from the first
call, then the caller must retry.

The  entrypoint ms_table_mgr_$unlock  allows cleanup  handlers to
unlock the database.

MTB-670                                Multics Technical Bulletin
                                                       Ring 1 PNT

The entrypoint ms_table_mgr_$check_lock is  for use by inner ring
subsystems that  can NEVER legitimately return  to the outer ring
with their  table locked.  The caller  supplies their lock_id and
the  table pathname.   ms_table_mgr_ unlocks  the table  if it is
locked, and  returns a bit  flag that indicates that  it has done
so.  The caller can then log the event.

The checksum of the permanent information is checked at each call
to  ms_table_mgr_.   The  entrypoint  ms_table_mgr_$validate will
check  this  checksum and  the  date-time updated  fields  in the
component  headers.   This  quick  check can  be  used  at system
initialization time  to check the PNT.   Searching the entire PNT
for entries with checksum failures is much more time consuming.

If the checksum  fails for an entry, a  predictable error code is
returned from the find entrypoints.

3.3 Ring 1 crawlout handling

     It would be disasterous for a process to crawl out of ring 1
with the  PNT lock held.   Because this is  just as true  of some
other ring  1 subsystems, like  RCP, we will  implement a general
mechanism to allow for non-ring 0 crawlout handlers.

     The  gate_macros  macro  "gate_info" will  take  an optional
parameter, the name of a procedure  to call on crawlout.  If this
procedure is  supplied, an any_other handler  will be established
to call it and then continue to signal.

3.4 mail_table_mgr_

     Since  the mail_table_mgr_  already has its  own locking, we
will  make  the minimal  change, which  is to  call the  new find
calling sequence  with the write_flag  off and ignore  the change
clock  and  the  checksum  failure indication.   We  must convert
mail_table_mgr_ to the new version 3 ms_table_info structure, and
provide a conversion tool.

At  a future  time, the  mail_table_mgr_ can  be changed  to take
advantage of the data integrity offered by the new facilities.

3.5 urf_manager_

     We  will  change the  urf_manager_  to use  the  new calling
sequences.  We will add the  create_urf command to create a fresh

Multics Technical Bulletin                                MTB-670
Ring 1 PNT

3.6 pnt_manager_

     We will  change the program pnt_manager_  to an ALM transfer
vector to three different gates to ring 1.

     pnt_login_gate_  will  take  as  input  a  user  name  and a
scrambled login password.  It will  return the PNT entry with the
passwords  blanked  out.   It must  do  this whether  or  not the
password is  correct, to allow the  Answering Service to continue
to   maintain   the   "last  bad   password"   information.   The
pnt_manager_ entrypoint "login_get_entry" will call this gate.

    pnt_network_gate_  will  take  as  input a  user  name  and a
network, or  "card-input" password.  If the  password is correct,
the  pnt_entry is  returned with  the passwords  blanked out.  In
addition,  this  gate  provides  an  entrypoint  to  retrieve the
network password  of a user.   This is used  by IMFT to  obtain a
password  to send  across the link  to interauthenticate systems.
It would be better if IMFT was using special "site" registrations
and  could  be prevented  from  obtaining arbitrary  user network
passwords.  The pnt_manager_  entrypoints "network_get_entry" and
"get_network_password" will call this gate.

    pnt_admin_gate_ will return the entry  for any user with both
passwords blanked out, and will  update all fields (including the
passwords)  of  any entrypoint.   A user  may be  given read-only
access to the  PNT, and access to this gate,  in order to see the
other  fields  of  PNT  entries.   The  pnt_manager_  entrypoints
"get_entry", "abs_get_entry",  "update_entry", and "remove_entry"
will call this gate.

     pnt_priv_gate_  will return  the complete entry  for a user.
The only legitimate use of this would be a trusted application to
do analysis  on the quality  of passwords.  (How many  are in the
dictionary,  etc.).  The  default access  to this  gate should be
null to *.

    All  of these  gates will  manipulate only  the standard PNT,

    The  text   of  the  program   pnt_manager_.pl1  will  become
pnt_db_interface_.pl1 We will make  the neccessary changes to use
the new ms_table_mgr_ entrypoints.

     We will expand  the space available for each  password to 32
characters, and  create a flag to  indicate whether each password
was  scrambled with  an 8  character scramble  or a  32 character
scramble.    This   makes  the   conversion  to   long  passwords
transparent to the users.

MTB-670                                Multics Technical Bulletin
                                                       Ring 1 PNT

     We  will  add  a  version to  the  pnt_entry  structure, and
padding space  at the end.   This will allow  future enhancements
without table conversion.

3.7 Other PNT management interfaces

     The  gate  pnt_fs_gate_  will  provide  the  interfaces  for
creating, deleting,  renaming, copying, and  rebuilding PNT's.  A
suffix_pnt_  will  allow the  standard  commands to  be  used for
delete, rename, and copy.

     We  will  create  the  create_pnt  command  to  create PNT's

     We will create the rebuild_pnt command to compact/expand the
PNT.  This command  will copy the PNT to  a new file, potentially
of a different size.  This cleans up after deleted entries, which
eventually degrade the hash efficiency, and allows a site to make
space for more users.

     We will  add a pnt_status  command, to return  statistics on
how full the PNT is.

3.8 Auditing

     All PNT  database operations will be  audited via the syserr
log.   We  will  depend  on ring  zero  auditing  of  file system
operations to audit name changes, deletes, and the like.

For updates  to entries, a  binary message structure  will record
both the old and the new pnt_entry.  Scrambled passwords will not
be left in the log, but we will note the fact that one or both of
the passwords changed.

3.9 pnt_manager_ callers

     We will change  all callers of pnt_manager_ to  use the new,
more restrictive  calling sequences.  A list  of them is provided


Multics Technical Bulletin                                MTB-670
Ring 1 PNT


     We will, of course, delete the command make_MR8_PNT_URF.



    Syntax: create_pnt Pathname {-size Nentries}

The  create_pnt  command create  a  pnt segment.   If  the ".pnt"
suffix is  not included it is  supplied automatically.  Access to
the pnt_fs_gate_ is required to perform this operation.

If  you supply  the -size  control argument  the new  PNT will be
created  with  enough  space  for  Nentries  "entries".   A  user
registration uses one entry, and an alias uses another.

Ordinarily, you use this command create  a new PNT at a new site,
and not otherwise.


  Syntax: rebuild_pnt OldPath NewPath {-size Nentries}

Use the rebuild_pnt command to recover dead space in your PNT, or
to expand it  to have room for more  user registrations.  You can
use the pnt_status command to see how mush dead, or wasted, space
you have, and how close to full you are.  Since the command makes
a new copy of the PNT, you  must use it in special session before
starting  the  answering  service.  Otherwise,  any  changes that
happen between the rebuild and the time that you copy the rebuilt
PNT into >sc1>PNT.pnt will get lost.

For example:

        boot stan
        Multics .......
        r ... ... ...

MTB-670                                Multics Technical Bulletin
                                                       Ring 1 PNT

        rebuild_pnt >sc1>PNT >udd>sa>dir_with_much_quota>NEW_PNT
        r ... ... ...
        move >sc1>PNT.pnt >udd>sa>a>before_rebuild.[date]
        r ... ... ...
        copy >udd>sa>dir_with_much_quota>NEW_PNT.pnt >sc1>PNT.=
        r ... ... ...


     Syntax: pnt_status Path

Use this command to find out  about space utilization of the PNT.
It will tell you  the how close to full the PNT  is, and how many
deleted entries it has.  Deleted entries use up space, and reduce
the efficiency of searches.


      pnt_status >sc1>PNT.pnt


   Syntax: check_pnt Path

This  command  makes  a complete  scan  of the  PNT  checking for
damaged  entries.   All  damaged  entries  are  reported  on your
terminal.  This command takes a LONG time.


The  system  checks  the  PNT  for  damage  at  answering service
initialization.   If  it finds  damage, it  prints a  message and
answering service initialization fails.  In this case, you should
rename >sc1>PNT.pnt,  and copy the saved  PNT from >udd>sa>a into

During operation, the system may discover that individual entries
in the PNT are damaged.  This  will result in error messages from
the  "new_user"  command,  and  logged  errors  in  the answering

Multics Technical Bulletin                                MTB-670
Ring 1 PNT

service and  card input daemon  logs.  When an  entry is damaged,
you can use new_user$cga to correct its contents.

The  check_pnt  command  will  make an  exhaustive  check  of all
entries in  the PNT.  Since  this is a  very expensive operation,
you should only do it if you have had a serious no-ESD crash.