On Friday 28 December 2007 19:07, Adriano dos Santos Fernandes wrote:

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

problem understood.

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

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

Let me begin with this question which is very simple. No problems with such
connections. They pass through remote layer, which strips all internal (like
you have correctly called them) tags from DPB. Therefore - no, it can't.

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

If we use same VM as for embedded connections - yes, it can. And that's not
good. Therefore such VM which may be called trusted for use as server plugin,
should itself strip internal tags from DPB. I'm absolutely sure it's
possible.

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

Sorry, looks like now I myself do not remember well what was it all about...

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

The only thing that we say when enable to the user (or service, if account
name is something like 'apache') embedded access to databases (in current
posix implementation it means user becomes a member of 'firebird' group) is
that we completely trust to that user/service, and see no problems if it
becomes SYSDBA at any moment he wants. Existing in current posix embedded
authentication in security database is just a mirage.

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

Yes.

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

Agreed. And it should watch Java code, running on it, not to do bad things
too.

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

Absolutely agreed.

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

I do not see something bad if we add such configuration, though on the other
hand do not see big use in it.

Another idea - to be able to configure untrusted plugins as running not in
firebird server process context. Imagine them placed in separate process,
using something like XNET (or OLE) to call external functions. Themself such
external functions will be able to connect back to firebird server usign any
remote protocol available. Doing so we let people choose between performance
and safety.