Access Controls

[cbbrowne@ntlug.org]

Derek Atkins writes:
> David Merrill <dmerrill@lupercalia.net> writes:
> > From *my* perspective (me, the database, that is), it is all based on
> > the user_name under which you are logged on. The database doesn't know
> > anything else on which it can base things. So the calling layer has to
> > translate from URL or virtual home or whatever into a user_name in the
> > database.
> > 
> > Providing for multiple everythings is decidedly nontrivial, but I'll
> > start on it.
> 
> Would it be possible, if we do go the gnc_server/gnc_client route, to
> allow the gnc_server to login to the database and have _that_ do
> access control on the data?

Ah, yes, this is indeed a Pretty Appropriate Approach.  Further, it's
something that CORBA would support _really_ nicely; effectively, you
set up a "Security Server," which has access to the authentication
info, and use that as a "gatekeeper" that permits or denies access
to the data.  

The Engine and the Security Server sit on the same host, so latency
is very low [thinking in advance of the immediate objection!]; in the
more paranoid approach to this, the Engine asks the Security Server,
for each request, "Should I pass this information on?"

This is elliptically discussed in the book "Professional Linux
Programming" [Wrox Press] in the chapters on CORBA.  [Guess the
author?]  :-)

I will immediately acknowledge that this sort of approach 
introduces an extra server, and excellent opportunity for new
deadlocks and some slowdowns.  So long as Engine and Security
Server are on the same host, the costs should be not _too_ 
excessive.  And by localizing security control to one process,
there can be quite spectacular control over what is permitted
and forbidden.