From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 11-JUL-1992 05:28:22.57
To:	info-vax@kl.sri.com
CC:	
Subj:	rights database organization

Someone asked why it is that the GRANT/ID command in AUTHORIZE demands that an
identifier associated with the target account's UIC exist in order for the
command to work.  This is an interesting question.  The short answer is that it
is due to the particular method that was chosen to organize the information
contained in the rights database file.  This file contains the name-to-number
identifier mappings and serves as the list of who holds what identifiers.  The
current organization was chosen both for ease of coding and for performance
considerations having to do with the rights identifier system services.  

What follows is a description of the current organization of RIGHTSLIST.DAT,
taken from one of the VMS source modules: 

!++
! A note on the structure and usage of the rights database.
!
! The rights database is an indexed file which holds two kinds of records
! (excluding the maintenance record). The primary key, common to both
! records, is the longword identifier value.
!
! The records themselves are as follows:
!
! 1) Identifier records:
!    Of size KGB$K_IDENT_RECORD, (currently 48 bytes), contains
!    the following fields:
!      - longword identifier value, also primary key
!      - longword identifier attributes
!      - always 0 (but corresponds to holder)
!      - longword unused, always 0
!      - 32 bytes ASCII, identifier name, also second auxiliary key
!
! 2) Holder records:
!    Of size KGB$K_HOLDER_RECORD, (currently 16 bytes), contains
!    the following fields:
!      - longword identifier value, also primary key
!      - longword attributes of the holder
!      - longword holder, never 0, also first auxiliary key
!      - longword unused, always 0
!
! Note. The holder field is strictly a quadword where the second longword
!       is required to be 0.
!
! Duplicate primary keys are allowed so that for a given identifier there
! may be an identifier record and a number of holder records. Program
! logic prevents the case of multiple duplicate identifier type records.
!
! Access to the holder records other than by holder auxiliary key is
! by virtue of primary key access by the identifier and then sequential
! access to the holder records for that identifier. There is no need to test
! whether a holder record or identifier record has been read. The identifier
! record will always be the first record obtained, that by the primary key
! access, because RMS guarantees sequential access of duplicate primary keys
! will be by order of creation.
!
! To make this work, identifier records must always be created before their
! holders, and care should be taken in the case where an identifier value
! is changed. This requires records be deleted and re-written, so once
! again, an identifier record must be processed before its holders.
!
! When searching by second auxiliary key for identifier name, then RMS will
! never return holder records.
!
! When searching by first auxiliary key for holder, then RMS will never
! return identifier records.
!
! This is because the auxiliary keys are defined such that when a null
! key is present for the record, that record will not be indexed for
! that key. An all zero value is forced into the holder field
! of an identifier record to meet this condition.
!
!--

If you followed all this, you'll see the implication that all general
identifiers are grouped under other identifiers.  In principle, even other UIC
identifiers could be held by other IDs, although this has always been arbitarily
disallowed by the identifier services.  Roughly the same functionality is
available using general identifiers anyway, and we did not want to encourage the
further use of UICs as a grouping mechanism.  Group management using UICs has
not turned out to be one of VMS' strong points due to the implicit group
qualified namespaces associated with several of our security relevant objects
(e.g. global sections).

I hope this was mildly enlightening or at least entertaining.  Note also the
liberal use of "we".  I did not design or implement any of this...

------------------------------------------------------------------------------
Derrell D. Piper		                      piper@bilbo.enet.dec.com
VMS Development
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
-------------------------------------------------------------------------------