Permissions

All databases will be world-readable.

Table of write-permissions:

Configuration Database	Experiment Calibration Database	Detector ("Cross-experiment") Calibration Database
OPR accounts (don't need kerberos ticket, only if active experiment)	per-experiment logbook groups (need a kerberos ticket)	expert groups (only ps-data)
expert groups	expert groups (e.g. ps-tmo and ps-data)

all write access requires a kerberos ticket, except the OPR accounts
all configdb api's will use hutch/instrument in the api which will be used for authentication
all cnf files will access ConfigDB using the opr-account style
expert groups means unix groups like ps-xpp, ps-data
there will be cross-hutch-expert protection: e.g. ps-xpp won't have permission to write to the TMO databases
Murali has said experts may have to do an extra step (e.g. set an environment variable) in order use a different URL/end-point for expert-group access (Feb. 25, Murali says since we use kerberos everywhere, don't need different URL).

Calibration Database Access Patterns

segment-specific calibrations will access run-dependent constants using detectorType_segmentSerialNumberString, where segmentSerialNumber is either read from the detector hardware by the daq (ideal, like epix) or managed administratively (more difficult)
detector-specific calibrations (e.g. geometry, hexanode roentdek algorithm, "pop" electron image inversion algorithm) will access run-dependent constants using detectorType_allSegmentSerialNumberString, where both halves of that field are administratively managed.
if a detector has only one segment the segment-specific/detector-specific calibrations are the same (but we should only have one copy)
could put segment hardware version number information as xtc payload
this means that multi-segment detectors will need to do multiple database fetches (bad) but that detector segments can be shuffled around without changing the calib database (good)