On Friday 28 December 2007 12:50, Adriano dos Santos Fernandes wrote:

> Alex Peshkov escreveu:
> > On Thursday 27 December 2007 19:17, Jim Starkey wrote:
> >> Adriano dos Santos Fernandes wrote:
> >>> I also need to communicate y-valve handles to engine, as Vlad does in
> >>> exec. stmt branch. But the solution Vlad is using doesn't work with
> >>> CONNECT and TRANSACTION START triggers, as he said.
> >
> > What do you mean here? There is no new conection and no new transaction.
> > How are triggers related with it?
>
> User attach to database, connection trigger is executed and call an
> external function that want to access the database.
> This will not work.

If existing connection is used in external engine, there is no new attachment.
Or may be you want that triggers to be executed with each EXECUTE STATEMENT?

> >>> I think these handles could be communicated to the engine via internals
> >>> DPB/TPB. BTW, isn't the isc_dpb_trusted_role an internal DPB? Should
> >>> not we create a generic mechanism for internal DPB/TPB?
> >
> > Generic mechanism is too loud word for very simple thing - removing a set
> > of tags from parameters block in remote listener. As soon as we start to
> > talk about embedded access word 'internal' looses any sense.
>
> I'm not sure if this is correct after the recent changes related to
> trusted auth.
>
> If an external function tries to attach to another database direct by
> the engine provider, can't it access this database with elevated (from
> user POV) rights?

Well, lets start from the very beginning. If we let some code to be executed
in server context, we trust that code? It it right?
I think that such code must be trusted. If we suspect it to be able to try to
violate server rules, we must also suspect it to be able to directly access
database file (which it can open cause it works in server process context)
and modify as it wants. Am I wrong here?

> It may be good to know how trusted auth. is going to work with external
> engines and "data links" (as Vlad documented something about trusted
> auth. being used there).

With existing security architecture it means that if user once connected to
any database on server as user Adriano with password Alex, it means he will
be able to connect to any database on same server with that pair of login and
password. I.e. there is no need to force some password validation when
connecting to other databases. When some more generic architecture will be
used, it will only mean that use of trusted connection in described manner
will be possible only inside a group of databases with same security
database.

> >>> And yes Virginia :-), this is one more thing that violates y-valve
> >>> layering, but it's how Firebird current works.
> >>
> >> Let me say that you are making a very serious mistake that Firebird
> >> developers will regret for years to come and leave it at that.
> >
> > I'm completely agreed with Jim here.
> > Instead of thinking how to violate providers architecture
>
> Main objective is not break the "providers architecture".
>
> But let's realize that what Jim planned more than 20 years ago were not
> implemented the way he wants. Period.

As far as I understand (correct me of I'm wrong) it was implemented in
pre-Borland period and worked fine.

> We have three layers of code (y-valve, dsql, jrd) with very bad
> integration, that can be extended for new features and (as always) I
> propose things trying to thinking in future development.

I would better say "can't be extended", at least without adding more and more
hacks.

> > may be it's better to discuss how to implement new features, not breaking
> > it?
>
> What it breaks, please? The architecture?
>
> Maybe we can starting fixing from EXECUTE STATEMENT? :-)

Please take into an account that when writing EXECUTE STATEMENT code 7 years
ago I've never heard about providers architecture at all. It was the very
first feature I've added to firebird, and from existing at that time source
code it was far not clear that something like OSRI exists at all. Please
agree, that all that are not what we have today. Certainly, it's not an
excuse for me, I only explain a reason why it was written in such a way.

What about fixing - need to work with yValve handles is present in EXECUTE
STATEMENT code only due to bad DSQL layring. For historical reasons it's kept
as standalone from the rest of engine subsystem. As soon as we have correct
DSQL+JRD integration (i.e. no separate dsql and jrd handles, but same single
handle for engine), it will not take me more then a few hours to remove all
yValve related hacks from EXECUTE STATEMENT - actually yValve handles are not
needed for it.

On contrary (may be I missed something?) in external engines you need to pass
yValve handle to external program to let it be used there, and this will be
required no matter of internal engine structure. And that is what I do not
like.