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
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
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
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
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
>> 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
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
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
>> 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
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
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
> 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: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
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 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 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
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 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
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 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/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 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 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 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: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, 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 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 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
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
>> 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
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
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 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
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 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
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 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
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
>>> 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 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
>> 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 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
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
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.
44 matches
Mail list logo
