DBM Access Control Lists (ACLs)
The I2A2 DBMs control access to
restricted facilities with private access control lists.
While a good case might be made that such control should be provided by the general I2A2 facilities, a separate mechanism
was chosen for reasons of efficiency and ease of development.
The implementation that resulted consists of a flat file for each DBM, listing
PUIDs and bits that identify the
facilities they may use.
ACL Identification
The DBM ACL lists control access using the PUID as the key. (Alias is not a key.)
ACL Authorization
PUIDs in the DBM ACL have associated with them a bit value, comprised of values associated with PUIDNETD_ACL_M symbols, that identifies the DBM facilities the PUID may use.
Getting a PUID Added to a DBM ACL List
Contact I2A2 Administration to learn how a PUID can be added to a DBM ACL.
Establishing the PUID
There is only one way a client system application can establish a PUID identity to a DBM via the servant net daemon. The
client application must use client-side
SSL -- i.e., it must supply a valid Purdue certificate, containing a PUID.
Once the net daemon has validated the Purdue certificate, it forwards the PUID in all transactions it conducts with
the DBM. The DBM validates the PUID's rights by finding it in its ACL list.
ACL Facilities
DBM ACL facilities are expressed as bits in an ACL value. The bits are represented by these PUIDNETD_ACL_M symbols and values. Bit values are stated in hexadecimal (0x) notation.
PUIDNETD_ACL_M_RD -- 0x1 -- read permission
PUIDNETD_ACL_M_WRM -- 0x2 -- write or modify permission
PUIDNETD_ACL_M_DIS -- 0x4 -- disable or enable permission
PUIDNETD_ACL_M_BKR -- 0x8 -- backup and rebuild permission
PUIDNETD_ACL_M_CR -- 0x10 -- create permission
PUIDNETD_ACL_M_DBM -- 0x20 -- can run DBM
PUIDNETD_ACL_M_PDMP -- 0x40 -- can dump a person's record
PUIDNETD_ACL_M_SLKU -- 0x80 -- can look up by or display HRID or SID
PUIDNETD_ACL_M_MINE -- 0x100 -- can "mine" a person's record, but not necessarily its HRID or SID (that requires PUIDNETD_ACL_M_SKLU)
PUIDNETD_ACL_M_CH -- 0x200 -- can replace global characteristics
PUIDNETD_ACL_M_DEL -- 0x400 -- delete permission
PUIDNETD_ACL_M_CNMR -- 0x800 -- can get multiple results from a reflector common name search (currently not used)
PUIDNETD_ACL_M_CCRL -- 0x1000 -- can raise regular expression lookup limits above the defaults
PUIDNETD_ACL_M_EPUID -- 0x2000 -- can set an effective PUID
PUIDNETD_ACL_M_GETACL -- 0x4000 -- can get a PUID's ACL bits
PUIDNETD_ACL_M_RDRLM -- 0x10000 -- can read realm information
PUIDNETD_ACL_M_LTSCH -- 0x20000 -- can read others' characteristic lists
PUIDNETD_ACL_M_ALL -- 0x3ffff -- all of the above
Special Notes
Here are some special notes about a few PUIDNETD_ACL_M values.
PUIDNETD_ACL_M_SLKU -- looking up a person's HRID or SID is a significantly restricted operation. Even when a PUID has permission to "mine" a PUID's information, it will not be able to mine the HRID or SID information unless it also has this permission.
PUIDNETD_ACL_M_PDMP -- a person's record is dumped to the standard error file descriptor of the DBM process, so this permission is only useful for developers running a private DBM.
PUIDNETD_ACL_M_CNMR -- early reflector DBM designs has severe restrictions on common name searches that have since been relaxed. This particular permission applies to all common name lookup requests sent to the reflector DBM.
PUIDNETD_ACL_M_EPUID -- a PUID that has identified and authenticated itself can change its identity to another PUID if this
permission is present. This is used by the I2A2
secure web interface
as it serves as a proxy for different PUIDs. It authenticates the PUIDs it serves via client-side
SSL.