Multics Technical Bulletin                             MTB-670-01
  Ring 1 PNT

  To:       Distribution

  From:     Eric J. Swenson

  Date:     08/28/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.

       This  is revision  1 of MTB670  previously published by      |
       Benson  Margulies.   Change  bars   are  used  to  note      |
       differences between this revision and the original MTB.      |

  Comments should be sent to the authors:                           |

  via Multics Mail:                                                 |
     Swenson at either System-M, MIT, or CISL-SERVICE               |
     and Margulies at either System-M, MIT, or CISL-SERVICE         |

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

  via telephone:                                                    |
     (HVN) 492-9365, or                                             |
     (617) 492-9365                                                 |


  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-01                             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-01
  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-01                             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.

| The  current  version number  of  MSTBs will  become  3.  Version
| numbers less than three will no longer be supported.  This should
| not  be  any problem  since  MSTBs are  an  undocumented internal
| interface.  Since the field currently has Version 1 and Version 2
| PNTs, URFs, and MAIL_TABLEs,  conversion routines will be written
| to perform  the conversion in  Initializer admin mode  before the
| answering  service is  booted.  The  new routine convert_v2_mstb_
| will convert  a version 1 or  2 MSTB to Version  3.  The commands
| convert_MR10_2_pnt,            convert_MR10_2_urf,            and
| convert_MR10_2_mail_table  will  call  convert_v2_mstb_  (through
| gates in the cases of the lower ring PNTs, and MAIL_TABLEs).

| The  commands display_mstb  and salvage_mstb will  be modified to
| support  the new  format MSTBs.   The new  routine mstb_checksum_
| (ALM) will calculate and validate checksums for MSTB entries.

  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.

  Multics Technical Bulletin                             MTB-670-01
  Ring 1 PNT

  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.   We  must convert  mail_table_mgr_ to  the new  version 3 *
  ms_table_info  structure.  The  command convert_MR10_2_mail_table |
  will         call        the         new        gate        entry |
  mail_table_priv_$convert_v2_mail_table to perform the conversion. |
  The   subroutine  convert_v2_mail_table_   will  do   the  actual |
  conversions and call upon convert_v2_mstb_ for table conversion.  |

  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

  3.6 pnt_manager_

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

       pnt_login_gate_$login_get_entry  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_$network_get_entry 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.  pnt_network_gate_$get_network_password provides an entry 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.   While  the old  pnt_manager_  support for  these routines |
  manipulated  an unscrambled  password passed as  a parameter, the |
  new interface will expect the  supplied password to be scrambled. |
  This  implies  that  the  callers of  these  entrypoints  will be |
  modified to scramble the password before calling pnt_manager_.    |

  MTB-670-01                             Multics Technical Bulletin
                                                         Ring 1 PNT

|     The entrypoints in 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",
| "add_entry",  "table_data",  and  "remove_entry"  will  call this

       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_util_.pl1.  We will make the  necessary changes to use the
| new  ms_table_mgr_  entrypoints  and  to  support  the  new  gate
| entries.  The target of all the pnt_manager_ gate entries will be
| the new program pnt_db_interface_.  This program will provide the
| gate-level  parameter  copying  and checking  as  well validation
| level  manipulation.  It  will call upon  pnt_db_util_ to perform
| the work.  This program will assume it is being called in Ring-1.

       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.   No administrative  support  for 32
| character passwords will be provided at this time, however.

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

|      The  new PNT  entry will  also maintain  a PNT authorization
| range.   Currently  it  only  contains  a  maximum authorization.
| lg_ctl_ will be modified to ensure processes are logged in within
| the PNT AIM range.
| The  new_user  command  (and  its  various  entrypoints)  will be
| modified  to  understand minimum  and maximum  authorizations and
| keywords will be added to manipulate them.  Support for PDT, SAT,
| and CDT AIM  ranges has been a subject of  a previous MTB and the
| software  to  support  them  is  a  prerequisite  to  the changes
| proposed here.

  Multics Technical Bulletin                             MTB-670-01
  Ring 1 PNT

  3.7 Other PNT management interfaces

       The  gate  pnt_fs_gate_  will  provide  the  interfaces  for
  creating, deleting, renaming, copying, and rebuilding PNT's.  The |
  target  of  this gate,  pnt_fs_interface_  will perform  the gate |
  parameter  copying  and  checking  as  well  as  validation level |
  manipulation.   Pnt_fs_util_ will  do the  actual inner-ring file |
  system functions.  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.

       We  will  add  the check_pnt  command  to scan  the  PNT for |
  damaged entries and report the results.                           |
       The convert_v2_pnt_ subroutine,  called through pnt_fs_gate_ |
  will perform the actual conversion of a pre-MR11 PNT to a version |
  2 PNT.  In addition to MSTB version changes, the PNT entries will |
  be upgraded.  The command convert_MR10_2_pnt will call this gate. |

  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.

  The  actions to  be audited  will be  the subject  of another MTB |
  which will  outline all the  changes necessary to  fulfill the B2 |
  audit requirement.                                                |

  MTB-670-01                             Multics Technical Bulletin
                                                         Ring 1 PNT

  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


       We will, of course, delete the command make_MR8_PNT_URF.

       The  programs cards_overseer_,  read_cards_, remote_driver_,
  and iodd_ will be modified to scramble passwords as they are read
  before  calling  validate_card_input_, which  will be  changed to
  expect scrambled passwords.



      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}

  Multics Technical Bulletin                             MTB-670-01
  Ring 1 PNT

  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 ... ... ...
          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

  MTB-670-01                             Multics Technical Bulletin
                                                         Ring 1 PNT

  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.

| ----------
| create_urf
| ----------
|    Syntax: create_urf Path {-size Nentries}
| This  command creates  a urf  segment.  If  you supply  the -size
| control argument, the  new urf will be created  with enough space
| for Nentries "entries".  A user registration uses one entry.
| This  command is  normally only  called by when
| bringing up a Multics site for the first time.
| ------------------
| convert_MR10_2_pnt
| ------------------
|    Syntax: convert_MR10_2_pnt Path
| This command upgrades a pre-version 2 PNT to Version 2.  It moves
| the PNT  to ring-1, upgrades  the MSTB to version  3, and updates
| the PNT  entries to accommodate  the 32 character  passwords, PNT
| authorization ranges, and a version number.
| This command is intended to be run in Initializer admin mode when
| the  site first  brings up  MR11.  The  old PNT  is saved  with a
| shriekname suffix is case reversion is necessary.
| -------------------------
| convert_MR10_2_mail_table
| -------------------------
|    Syntax: convert_MR10_2_mail_table Path
| This  command converts  a Version 2  MSTB format mail  table to a
| Version 3 MSTB mail table.  No other changes are made.
| This  command is  intended to  be run in  admin mode  when a site
| first brings up MR11.
| ------------------
| convert_MR10_2_urf
| ------------------
|    Syntax: convert_MR10_2_urf Path

  Multics Technical Bulletin                             MTB-670-01
  Ring 1 PNT

  This command  converts a Version  1 or Version 2  MSTB format URF |
  into a Version 3 MSTB URF.  No other changes are made.            |
  This  command is  intended to  be run in  admin mode  when a site |
  first brings up MR11.                                             |
  5 BRINGING UP MR11                                                |
  When  a site  brings up MR11  for the first  time, several tables |
  must be converted  in admin mode before the  answering service is |
  brought  up.  An  exec_com will  be provided  to aid  the site in |
  doing this.                                                       |
  This       exec_com      will       call      convert_MR10_2_pnt, |
  convert_MR10_2_mail_table, and convert_MR10_2_urf.                |


  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
  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 non-ESD crash.

  The  new_user  command  (and  the various  entrypoints)  will now |
  accept the new keywords minauth and maxauth to select the minimum |
  and  maximum  authorization  for modification.   The  old keyword |
  "auth" will be  retained for compatibility and will  refer to the |
  maximum authorization.                                            |