Re: [Firebird-devel] A couple of questions about why.c and implem enting database alias es

[John B. <bel...@cs...>]

Sean,

On Thursday, June 7, 2001, at 08:32 AM, Leyne, Sean wrote:

> John,
>
> Thanks for your comments.
>
> Actually, I was under the impression that this change would actually
> take effect for both the client and server sides -- although I really
> only want to support server side aliases (hoping that this can be
> determined through ifdefs).  Actually this approach would allow someone
> to use both client and server side aliases if they were that way
> inclined (read: insane)

Not more ifdef's :)  The flexibility offered by both client/server side 
alias resolution is good.  My response was thinking more about security 
though.  Since the source code is free for everyone, the jrd8_* 
functions (engine backend) needs to assume all data received through the 
Y-valve is untrusted, at least until the sender is authenticated.  This 
goes for both CS and SS.  The problem with placing alias resolution on 
the application side of the Y-valve is then the back-end has to *trust* 
the alias resolution performed by the application.  There is no reliably 
secure method to force users to only use aliases.  Alias resolution on 
both local/remote machine could be achieved by adding the resolution to 
the remote back-end code as well.

>
> I understood the function of the Y-valve (why.c) from a message that Jim
> Starkey posted to the IB-Architecture about the client data access model
> (April 25th @ 3:07pm EST).  The point was that both the client and
> server use the Y-valve function and therefore it could be leveraged for
> my purposes.
>
> Perhaps, I misunderstood Jim message or haven't found the right location
> for the server Y-valve logic.

I too have most of my understanding from that message.  Perhaps my 
terminology is confusing.  When talking about the front-end or 
application side of the Y-valve I'm referring to the code that is 
calling into the Y-valve.  Examples are any end user application, and 
the gds_inet_server (or ibserver for SS, but be careful because ibserver 
is statically linked with the back-end as well) code.  When I talk of 
back-end code I'm referring to code that the Y-valve dispatches to in 
response to a call from the front-end.  Examples of back-end are the DB 
engine (jrd8_* entrypoints) and the remote back-end (rem_* entrypoints, 
I believe).  For SS it would give us (FE is front-end, BE is back-end):

app [FE] <=> Y <=> remote [BE] <-net-> remote [FE] <=> Y <=> engine [BE]

Looking at security again if the engine is to trust data (before the 
user is authenticated) then it needs to validate it (ie, do the 
expansion, or at least verify it).  Anything less is asking for trouble, 
unless documented in big bold print.  But if we take that route we will 
still get some bug reports followed by feature requests :)

>
> By the way, I'm advocating/proposing that alias names be without
> punctation of any type, or at least not contain "/\." characters ("foo"
> or "foo_gdb").  The reason for this is to minimize the performance
> penalty in checking if the filename specified in the gds_database_attach
> is an alias, by scanning the filename before reading the alias 'table'
> from disk -- maybe I'm worrying too much about this.

Using the proper data structure we should be able to do expansion in 
close to log(n) time in the length of the alias list.  But if we are 
just trying to get the feature out the door the proper data structure 
might not be attractive....  I can envision a setup where subspaces in 
the alias space would be useful.  For example the alias scheme 
"<user>/<db>" might allow users to create DB's without alias conflicts.  
If we disallowed punctuation the users would latch onto a different, 
allowed separator (ex. "<user>Z<db>") and we would have yet another 
directory separator to remember :(

-John