Re: [Firebird-devel] User semantics vs authentication

[Geoff W. <ge...@te...>]

Hi Dmitry,

> My own vision is presented below.
> User should become a database object, like tables, roles,
[etc]

I am pleased to see that I was not too far off base with
my earlier email.  From my limited understanding of the issues
involved, something along the lines of what you suggest seems
very appropriate.

One particular issue that I can see arising from such an
arrangement is the problem of multi-database applications.

Its one of those "catch-22" situations.  The current single
security database per server enforces a single set of users
for all databases on that server - even when some of the
databases belong to different applications, and then neglects
to provide any way to keep the databases in sync.

However having user details inside each database makes it more
difficult to implement applications that do make use of more
than one database at a time.  For example an application that
has "archived" information made available from separate
(possibly read-only) databases.  I do implement a system along
similar lines to this, not because FB has trouble with the
database size, but because there are many administrative
reasons to keep the changing/production database as small as
practical.

(Note:  The above highlights a more specific issue, how to
give access to a read-only database if the user definitions
are inside the database?)

I am not sure how this situation can be resolved, unless we
can somehow differentiate between databases that carry such
user details and databases that carry only role information
for which the permissions are presumed to be managed via some
separate database.  (Or something to this effect.)


I do have other ideas about all this stuff, but...  well it
gets very involved and when I posted an email related to these
ideas (a few months ago) there was not much interest.  So lets
see what can develop with a less radical approach.

-- 
Geoff Worboys
Telesis Computing