Hi FreePascal and Firebird people,
(Cross-posted to the FPC and Firebird Development mailing lists)
1. Background
=
For the upcoming Firebird 3.0 database server release, developers are
working on allowing external languages (at first Java) for writing
stored procedures and functions.
Jim,
> Would it be possible and desirable to have FreePascal as an embedded
> stored procedure/trigger language in some future release of Firebird?
> (I
> can't recall this having been brought up before, so I just start the
> ball rolling).
I did not check the current state of Java "plugin", but
On 07/27/11 12:23, Roman Rokytskyy wrote:
> So, considering this all, there should be (theoretically) no problem of
> compiling the code in Free Pascal as long as it will produce binaries
> with appropriate entry points. That should be possible out-of-the-box
> (at least it was discussed that w
>> So, considering this all, there should be (theoretically) no problem
>> of
>> compiling the code in Free Pascal as long as it will produce
>> binaries
>> with appropriate entry points. That should be possible
>> out-of-the-box
>> (at least it was discussed that way few years ago).
>
> Is prob
On 07/27/11 13:40, Roman Rokytskyy wrote:
>>> So, considering this all, there should be (theoretically) no problem
>>> of
>>> compiling the code in Free Pascal as long as it will produce
>>> binaries
>>> with appropriate entry points. That should be possible
>>> out-of-the-box
>>> (at least it
>>> Is problem with exceptions processing in windows and FP is solved?
>>> It
>>> was noticed sometimes that FP UDFs block exception handling in
>>> firebird.
>> No clue, never used FP at all. But I would classify that as a bug
>> which
>> should be eliminated when such integration is implemented
On 27-7-2011 11:46, Alex Peshkoff wrote:
> On 07/27/11 13:40, Roman Rokytskyy wrote:
>>> Is problem with exceptions processing in windows and FP is solved? It
>>> was noticed sometimes that FP UDFs block exception handling in
>>> firebird.
>> No clue, never used FP at all. But I would classify th
On 27/07/2011 05:23, Roman Rokytskyy wrote:
> Jim,
>
>> Would it be possible and desirable to have FreePascal as an embedded
>> stored procedure/trigger language in some future release of Firebird?
>> (I
>> can't recall this having been brought up before, so I just start the
>> ball rolling).
> I d
JIm,
A very interesting proposal. Having recently ported IBX from
Delphi/InterBase to Free Pascal/Lazarus/Firebird, I know that both
Firebird and Free Pascal are great products and could and should work
well together for server side as well as client side functions. The
question is what benefit do
On 07/27/11 15:11, Tony Whyman wrote:
> 6. Just in time compilation of the embedded procedure on first use
> (after create/alter) into a shared library/DLL which is then effectively
> a dynamically generated UDF library. A JIT approach is important because
> the database can be moved between proce
27.07.2011 13:40, Alex Peshkoff wrote:
> Before doing JIT, we must think about related security issues. How can
> we prevent pascal procedure from doing bad things with firebird runuser
> access rights?
Leave it to DBA/sysdmin? In trade-off security vs speed Firebird used to
vote for speed.
-
On 27/07/2011 08:40, Alex Peshkoff wrote:
> On 07/27/11 15:11, Tony Whyman wrote:
>> 6. Just in time compilation of the embedded procedure on first use
>> (after create/alter) into a shared library/DLL which is then effectively
>> a dynamically generated UDF library. A JIT approach is important b
On Wed, Jul 27, 2011 at 2:40 PM, Alex Peshkoff wrote:
> On 07/27/11 15:11, Tony Whyman wrote:
>> 6. Just in time compilation of the embedded procedure on first use
>> (after create/alter) into a shared library/DLL which is then effectively
>> a dynamically generated UDF library. A JIT approach is
On Wed, Jul 27, 2011 at 2:55 PM, Adriano dos Santos Fernandes
wrote:
> On 27/07/2011 08:40, Alex Peshkoff wrote:
>> On 07/27/11 15:11, Tony Whyman wrote:
>>> 6. Just in time compilation of the embedded procedure on first use
>>> (after create/alter) into a shared library/DLL which is then effect
>> 6. Just in time compilation of the embedded procedure on first use
>> (after create/alter) into a shared library/DLL which is then
>> effectively
>> a dynamically generated UDF library. A JIT approach is important
>> because
>> the database can be moved between processor architectures/platform
This is really a general UDF problem and another reason why you need to
be very careful about deploying them. The only difference between an
embedded function and UDF one is that theoretically a System Admin
should check the UDF before installing it
Otherwise, it has the same potential to dama
On 07/27/11 15:45, Dimitry Sibiryakov wrote:
> 27.07.2011 13:40, Alex Peshkoff wrote:
>> Before doing JIT, we must think about related security issues. How can
>> we prevent pascal procedure from doing bad things with firebird runuser
>> access rights?
>Leave it to DBA/sysdmin? In trade-off se
On Wed, Jul 27, 2011 at 15:35, Tony Whyman
wrote:
> This is really a general UDF problem and another reason why you need to
> be very careful about deploying them. The only difference between an
> embedded function and UDF one is that theoretically a System Admin
> should check the UDF before inst
On 07/27/11 16:05, Roman Rokytskyy wrote:
>>> 6. Just in time compilation of the embedded procedure on first use
>>> (after create/alter) into a shared library/DLL which is then
>>> effectively
>>> a dynamically generated UDF library. A JIT approach is important
>>> because
>>> the database can
On 07/27/11 16:42, ik wrote:
> On Wed, Jul 27, 2011 at 15:35, Tony Whyman
> wrote:
>
>> This is really a general UDF problem and another reason why you need to
>> be very careful about deploying them. The only difference between an
>> embedded function and UDF one is that theoretically a System Ad
On 07/27/11 16:05, marius adrian popa wrote:
> On Wed, Jul 27, 2011 at 2:40 PM, Alex Peshkoff wrote:
>> On 07/27/11 15:11, Tony Whyman wrote:
>>> 6. Just in time compilation of the embedded procedure on first use
>>> (after create/alter) into a shared library/DLL which is then effectively
>>> a
On 07/27/11 16:09, marius adrian popa wrote:
> On Wed, Jul 27, 2011 at 2:55 PM, Adriano dos Santos Fernandes
> wrote:
>> On 27/07/2011 08:40, Alex Peshkoff wrote:
>>> On 07/27/11 15:11, Tony Whyman wrote:
6. Just in time compilation of the embedded procedure on first use
(after create
On Wed, Jul 27, 2011 at 3:45 PM, Alex Peshkoff wrote:
> On 07/27/11 16:05, Roman Rokytskyy wrote:
6. Just in time compilation of the embedded procedure on first use
(after create/alter) into a shared library/DLL which is then
effectively
a dynamically generated UDF library. A
On 27/07/2011 09:45, Alex Peshkoff wrote:
>
> If we can provide such restrictions (probably the best will be to have
> fixed list of acceptable "uses"), this can be enough.
>
And just an invalid pointer access will turn down your server who tried
to be secure.
Adriano
-
On 27-7-2011 14:45, Alex Peshkoff wrote:
> On 07/27/11 16:05, Roman Rokytskyy wrote:
6. Just in time compilation of the embedded procedure on first use
(after create/alter) into a shared library/DLL which is then
effectively
a dynamically generated UDF library. A JIT approach
On 27-7-2011 14:50, Alex Peshkoff wrote:
> On 07/27/11 16:42, ik wrote:
>> On Wed, Jul 27, 2011 at 15:35, Tony Whyman
>> wrote:
>>
>>> This is really a general UDF problem and another reason why you need to
>>> be very careful about deploying them. The only difference between an
>>> embedded funct
On 07/27/11 16:56, Adriano dos Santos Fernandes wrote:
> On 27/07/2011 09:45, Alex Peshkoff wrote:
>> If we can provide such restrictions (probably the best will be to have
>> fixed list of acceptable "uses"), this can be enough.
>>
> And just an invalid pointer access will turn down your server w
27.07.2011 15:05, Alex Peshkoff wrote:
> BTW, how is it solved in Java?
There is no pointers in Java, AFAIK.
--
SY, SD.
--
Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don't ask for
On 27/07/2011 10:00, Jim wrote:
> "Of course, an alternative, as Alex Peshkoff mentioned:
> If we vote for speed, the best choice will be use of precompiled
> libraries - like with UDFs.
> And like UDFs we leave it to sysadmin - not DBA."
> ... we could just trust sysadmins to only upload proper co
On Wed, 27 Jul 2011 17:05:39 +0400, Alex Peshkoff wrote:
> On 07/27/11 16:56, Adriano dos Santos Fernandes wrote:
>> On 27/07/2011 09:45, Alex Peshkoff wrote:
>>> If we can provide such restrictions (probably the best will be to have
>>> fixed list of acceptable "uses"), this can be enough.
>>>
>>
On 07/27/11 17:08, Dimitry Sibiryakov wrote:
> 27.07.2011 15:05, Alex Peshkoff wrote:
>> BTW, how is it solved in Java?
>There is no pointers in Java, AFAIK.
>
What a wonderful language! :-)
--
Got Input? Slashdot
On 27/07/2011 10:08, Dimitry Sibiryakov wrote:
> 27.07.2011 15:05, Alex Peshkoff wrote:
>> BTW, how is it solved in Java?
> There is no pointers in Java, AFAIK.
>
Sure. The language don't allow such malicious things.
And the Java plugin security works like a Java applet running in your
browse
> And the Java plugin security works like a Java applet running in your
> browser.
>
> It's by default configured to allows nothing that can danger the
> machine.
>
> But say you need to access the network, you put a record in the java
> security database saying the user or role has the permission
On 27/07/2011 10:57, Roman Rokytskyy wrote:
>> And the Java plugin security works like a Java applet running in your
>> browser.
>>
>> It's by default configured to allows nothing that can danger the
>> machine.
>>
>> But say you need to access the network, you put a record in the java
>> security
Hello Adriano,
AdSF> Sure. The language don't allow such malicious things.
Yes, but JVM is written by humans, and "errare humanum est" ;-)
AdSF> And the Java plugin security works like a Java applet running in your
AdSF> browser.
And this not protect you from Java Trojan downloader for example
>> Oh, so you have implemented a proper security manager for the Java
>> ESPs? You are great man! :)
>
> It was difficult and initially was failing only in Linux. But after
> changes it worked ok as far as I can test.
Will it accept also a default security manager with java.policy file?
So that a
On 27/07/2011 10:43, Sergey Mereutsa wrote:
> Hello Adriano,
>
> AdSF> Sure. The language don't allow such malicious things.
>
> Yes, but JVM is written by humans, and "errare humanum est" ;-)
As long there is no current serious public know vulnerability in a
years-old technology, I'd say it's se
Hi!
>> And this not protect you from Java Trojan downloader for example.
AdSF> What do you mean?
I mean, that if you miss something in the security model, it will be
possible to use this vulnerability, but I was written before your
answer :)
Anyway, if it works - it is really good feature in FB3
>> And this not protect you from Java Trojan downloader for example.
> What do you mean?
If I remember correctly, that was a JAR with "manipulated" byte-code
which exploited some particular JVMs when the code was executed (at
least it was able to download malware from the network and execute the
On 27/07/2011 11:16, Roman Rokytskyy wrote:
>>> Oh, so you have implemented a proper security manager for the Java
>>> ESPs? You are great man! :)
>> It was difficult and initially was failing only in Linux. But after
>> changes it worked ok as far as I can test.
> Will it accept also a default sec
On Wed, 27 Jul 2011 17:24:30 +0300, Sergey Mereutsa
wrote:
> Hi!
>
>>> And this not protect you from Java Trojan downloader for example.
> AdSF> What do you mean?
>
> I mean, that if you miss something in the security model, it will be
> possible to use this vulnerability, but I was written befo
while trying to build fb3 on linux using gcc-4.5.1 and glibc-2.13, I
encountered some small problems.
The following patches fix these problems.
diff --git a/src/common/call_service.cpp b/src/common/call_service.cpp
index cada721..50fbbb4 100644
--- a/src/common/call_service.cpp
+++ b/src/common
I am trying to build the latest checkout of fb3
on amd64 linux-2.6.39.3 , using gcc-4.6.1 and glibc-2.13
if NO_NFS is not set
/var/git/firebird3/src/common/isc_file.cpp: In member function 'bool
{anonymous}::Mnt::get()':
/var/git/firebird3/src/common/isc_file.cpp:1478:12: error: 'buffer' was no
On 07/27/11 17:10, Adriano dos Santos Fernandes wrote:
> From FB POV, signed code for sysadmin means nothing. Sysadmin should
> just be able to put files where it wants and like UDFs, if it's in the
> right place it should be used.
>
> What I see good about code signing is that sysadmin could d
44 matches
Mail list logo
