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.

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

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

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

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.


Adriano