NOMAD's permissions system is based on the UNIX model: each user has a user
ID and group ID; each personal piece of data is owned by a UID and GID (each
unique integers), and has a three-digit octal permission set (2 = write and
4 = read).

the security layer consists of inbound and outbound checkpoints. security
for output (SELECTs) is handled by a special WHERE clause (from function
perm_clause()) that matches based on either UID, GID, or world-readability.
security for input is handled by a function, can_i(), called whenever a
relevant change is presented by the user.

my biggest concern with this scheme is that SELECTs will be slower. we can
minimize this impact by indexing on UIDs.

the UI we need to construct includes mechanisms to:

	change permissions on a set of data
	add/delete users in groups
	view by default one's own data, with other readable data listed

special considerations:

	we have no use for the execute bit - yet.
	we are disallowing people from making their own data unreadable, and
		from making data publicly writable.

rationale:

	since mysql's user table is not portable (does not exist in the same
	form in other databases), we need to keep track of users ourselves,
	and use those UIDs to indicate ownership of each piece of data. this
	means that NOMAD must be the only manner in which users can access
	their rows; the tables will be unviewable by other entities (such as
	the database client shell). the tables will be readable only by one
	database user, who will be NOMAD's superuser.  its password will be
	randomly generated at install time.

aside:

	it would be nice to supply the user with a manner in which to make
	SQL queries, since they will not be able to use the client shell; of
	course, that SQL must feature (*1) to describe only personal records.