Re: [Firebird-devel] Authentication and Security in Vulcan

[Jim S. <ja...@ne...>]

Alex Peshkov wrote:

>
> Both firebird 1.5 and 2.0 use second part of described mechanism long 
> and happily. It differs in details (flag is set in TLS, I know you 
> don't like it, but it makes absolutely no difference from algorythm 
> point of view), but in general works exactly like you've described. 
> With "authenticating" set (flag is called thread_security_disabled, 
> but I try to use new names), firebird bypasses security check in both 
> SCL_init() and SCL_check_access(). This makes no need in any builtin 
> or configured pseudo-accounts, single mechanism works fine in both cases.

Firebird 1.5 and 2.0 break the layering.  Each requires a special check 
for internal handle that is incompatible with the architecture.  That's 
OK for Firebird 2.0, but it isn't OK going forward.

The Vulcan security architecture is based on fb_authenticate_user call 
that is passed to the security plugin, which returns yea or nay (if yea, 
it returns a user information packet).  The security plugin doesn't know 
beans about special internal attachments, nor should it.  If a security 
database is configured, the security plugin does a vanilla 
isc_attach_database followed by an fb_authenticate_user call.

Security plugins are one reason for this architecture.  Another is the 
requirement to support rolling upgrades where the target database and 
security database may be different versions or even different ODSes.

This was discussed at great length about a year ago.

-- 

Jim Starkey
Netfrastructure, Inc.
978 526-1376