Vlad Khorsun wrote:

>> 2) We are defining a public plugin interface or something only the FB
>> project may use and can change in each version?
>>
>
> I see no relation between this question and subject of discussion.
>

It's related, as a "second version" of Java plugin may not have
necessary foundations to work.

>
>> 3) Should it be harder to use or easy?
>>
>
> I prefer easy ;)
>

Good. :-)

>> Vlad, if official Java plugin allows only to execute classes that user
>> should invent a way to put in the server, it will certainly not be very
>> usable.
>>
>
> Why ? Why Java classes is better than current UDF's ? It is safe ?
> Really ?

Yes it's safe because it runs in JVM, or in a managed environment in MS
words for .NET.

It's safer as PSQL. One could do bad things with both, for example,
writing endless loop.

> Or sysadmin (not dba !) must configure Java on his computer
> first to make is safe ?

It seems we agreed to deliver default configuration file to runs Java
classes with untrusted applet permissions.

I don't worry to use my browser with this on, why a sysadmin may block a
DBA, please?

> And made it not usable at the same time if classes
> want to do something forbidden ;)
>
> Correct me where i'm wrong :
>
> I'm ISP\sysadmin. I'm allow you (dba) to run your database on my
> computer. I configure JVM and disallow any Java code to write into FS.
> You (dba) can't configure JVM instance hosted by database engine to do
> something i'm not allow. I (ISP) don't want to approve any of your UDF's
> independent on which language you write it. I (ISP) don't trust you (dba)
> to configure security on my machine. All i can allow you to do is to run
> database engine which is more or less trusted to me.
>

Master configuration file (edited by ISP sysadmin) or security
permissions created by a SYS user (SYS = sysadmin, different from
SYSDBA) is the definitive authority, nobody can give more privileges
than it.

But DBA will can revoke privileges per user.

>> Possible good Java plugin would allow to upload
>> JAR/class/resources/sources, or write inline Java code that will be
>> compiled in the server.
>>
>> What you're suggesting (a global permission to define external
>> procedures)
>>
>
> This is widely approved practivce, i believe, - every action must have
> corresponding permission. EXECUTE, CREATE, DECLARE, etc - every
>

We do want different permission per language for DECLARE.
Sorry, but reasons is in all mails and you may read again, I'll not
insist on this.

>> doesn't make sense because:
>>
>> 1) If well configured, Java code is safe as PSQL
>>
>
> I (ISP) don't trust you (dba). Remember it ;) Hence there is no sence
> to configure Java security through database.

ISP/sysadmin is the master, remember?

> But it is still required to allow\
> disallow users to execute procedures. Independent of language. And this is
> required by dba, not ISP.
>

No problem, we already have EXECUTE permission and I don't thing we
should change it.

>
>> 2) No matter how good configured, binary machine code is not safe - I
>> see no comments from you about "security by obscurity" that I told
>>
>
> Because it's not "security by obscurity". Nobody can override FS
> permissions. And if you don't know allowed directory - you can't write
> anything anywhere.
>

Really? What about /tmp or FB directory installation?

> Again, please, define goals and problems. Imagine i know nothing
> about Java, JMV, Java security etc...
>

I imagined, as that seems to be true. :-)))


Adriano