-----Original Message-----
From: Adriano dos Santos Fernandes <adrianosf@...>

> Alex Peshkov escreveu:
> >> 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.
> >
> But engine needs to know y-valve handle of user connection... Current
> implementation in exec_stmt2 branch pass the handles after the attach
> call and consequently after the external function is executed.

Yes, and this may be discussed separately, is it good or bad
and how much does it break OSRI. But how is it related with triggers?

> > 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?
> >
> No, from data access POV.
>
> The code may be in trusted JVM or may be called from another database...

If it runs in trusted JVM, it may also be trusted.
But in the _trusted_ JVM code should not be able to elevate rights.

> > 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?
> >
> This is not true for above cases.

How can we guarantee this for code from another database?

> > 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.
> Current implementation will pass y-valve handle to external code that
> will access database though y-valve.
>
> Future implementation will pass engine handle to external code that will
> access database direct through the engine.
>
> I see no future problem here. And that was explained in the previous thread.

OK, in that case (passing yValve handles is just a temporal measure due to wrong
DSQL encapsulation) I also do not see too big problems here.

The main remaining for me problem with external engines is
that we bring a lot of foreign code into firebird server process.
Doing it we have 2 choices.
We must have means to guarantee that this code is safe and is not
going to violate internal rules of our server. This is (for example)
how correctly written PHP program works with requests coming to web
server from outside world. Else (ion cas ewhen we can't guarantee
correct behavior of external code), we will have to accept the fact
that security of firebird server is not OK, cause it may be
violated by external code.
Security measures should be taken in that external code. I.e. it must be
trusted by us, cause not trusted code running in same process always
has enough ways to violate normal firebird server operation. That is what
we were fighting with when limiting access to UDF libraries and external
files.