CSCF Access to Public Data

In general, access to data that is public (to whatever extent), is best mediated by some system. E.g. it's not considered ideal to provide a login to a database system for everyone, even if the visible data is (in theory) quite limited. Doing so would leave it more open to attack than is necessary.

So, to provide access to the data for the mediating system, we need an account/userid to control access. The recent (2014-08) direction is to use the userid cscf-dat (cscf-data) to control access to files that contain database passwords.

There can be variants, depending upon the security and source of the data. E.g. we have userid cscf-ona which controls access to a password for access to part of the ONA (campus network) data.

The Postgres role of _cscf_web is expected to be used in general for data that is public, even when it resides in a database that contains private data. E.g. the OAT database mostly contains private data, however it also contains data such as course titles. That's made available to _cscf_web for reading via a "view" with very limited data access. The CSCF public data is on a different server, and also uses the same role to control read access.

An example of direct _cscf_web usage is the tools used for Start of Term Email to Instructors. It's done that way primarily to avoid having to make a setuid interface to the Perl program involved.

An example of cscf-dat usage is the CSCF Points of Contact data, which uses cscf-dat to control access to the password for the _cscf_web database role in the CSCF public database, as well as in the OAT database (in order to determine course titles).

Write access to the CSCF public data is available to those with a database account that's a member of the _cscf_root role. Write access to the public OAT data is unavailable directly, as the data is obtained from other source (e.g. the Registrar).