Александр Пешков escreveu:

>> 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?
>

ON CONNECT triggers may call external function or use data links (exec.
stmt2 branch).

>>> 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.
>

Let me explain my doubts... If trusted auth. is enabled in a server,
attachments from *this* server may not need password and may be SYSDBA,
correct?

In this case, if a remote user calls an external function that goes to
Java plugin and calls Jaybird that try to connect to another database,
won't this connection be able to log as SYSDBA?

And the same question for C plugin that tries to connect to localhost
via fbclient.

>
>>> 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?
>

I did not understood you.

>
>>> 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.
>

Yes.

> 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),

External code running in the server is the same as embedded engine
running in the client.
We can't "guarantee" much things.

> 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.

We should trust the plugins we deploy.

If we deploy trusted Java plugin, code running inside JVM should not do
bad things to the server, for example.

If we deploy C plugin that should not be accessible by any user and one
grant usage to public, we can do nothing.

That's why I'm in favor of trusted/untrusted configuration per language.


Adriano