Firebird News

[See remaining text...] 

Remove security2.fdb and related authentication tools at all, and use OS native authentication instead. Avoid sending passwords over the wire (use a kind of CHAP instead). Optionally encrypt all data, transferred over the wire.
BTW, almost all of this, but with optional backward compatibility support, is planned for FB3.

4) A recurrent question in discussion lists is how to protect your database from being accessed by SYSDBA. What is your answer for this question? Can we expect any improvement in this area with FB 3.0?

This is a kind of wrong question. This is almost as asking to protect some file in unix from root access:-) But, taking into an account, that too many badly administered servers with firebird installed exist in the world, there will be one answer to this question in FB3 – per database configurable security database. One will be able to even setup database itself to store logins to it. This is supposed to be done in aliases.conf file in this way:

SomeAlias = /path/to/database/file.fdb
{
 SecurityDatabase=$(self)
}

Side note – you will be able to add a lot of (but not all) parameters from firebird.conf here, making them have different values for different databases.

Interviewer: But this wouldn’t solve the problem of having a “stolen” database being accessed by SYSDBA of another Firebird server, since he would have full control of the aliases.conf in his own server.

Yes, certainly – it will not work. Moreover – even if you add ANY other protection (except serious data encrypting), database can anyway be stolen. Suppose we add a flag to database header – it can be accessed only using internal users table, i.e. no control from aliases.conf. But a person who has stolen that database has a variety of choices:

- Remove that flag with any hex editor
- Build engine which ignores such flag
Do not forget, this is open source!

Well – imagine we have the ability to crypt database data using some crypt plug-in.

Old InterBase even has some code to handle database page level encryption.]
It has serious disadvantage – crypt key is passed via DPB, making it necessary (in case of direct use) store it on all workstations, which is definitely not secure. On the other hand, one can write plug-in which will ignore that key, and do the job itself.

But main problem remains – if database can be stolen, what prevents crypt plug-in itself to be stolen? Therefore on my mind (and that’s mind of all developers) the only way to protect your database from being stolen is to have correctly administered OS on your server.

5) What was the most difficult task you have done for Firebird up to now, and what one made you more proud?

Very hard to answer… There were too many various bug fixes, and which one is the most hard – do not know. Some happen to be trivial, some – complex. May be the most hard to fix are bugs that are not easy to reproduce, specially if they show themselves on some rare type of CPU, not available to me except remote connection (like HPPA/PARISC for example).

When famous Russian poet and singer Vladimir Vysotsky was asked “What is your favorite song?” he used to answer – one that I’m writing currently. In the same way I hope that the most interesting tasks with firebird will be in the future versions

6) What are the major challenges for FB in the near future?

The major one is common pages cache for multiple connection (also called SMP-friendly superserver). At the same time we plan to have COM-like plugins’ interface and reanimate OSRI architecture, all of this in FB3.0. On this basis it will be possible to talk about making something like 3.5 version as SQL standard compatible as possible.

7) Working with security is something that you enjoy, or it is kind of “ok, if nobody wants to do this, I’ll take care of it”?

It’s interesting to work in some area (here I understand it more wide than firebird only related question), when you need to solve some problems, that did not have a solution before you. From this POV security in firebird is still interesting area – there are still remaining problems to be solved before it becomes not interesting. And I have plans to make it not interesting in FB3 development cycle

What do you think is missing to Firebird become more visible in the global media? Seems that some people still thinks FB is a RDBMS just for small volume of data or connections. How to change this (wrong) perception?

Sorry, I can’t answer this question. Technically even firebird 2.1 classic is capable to handle about one thousand of connections or even slightly more. Superserver can handle much more, but even in 2.5 it does not have good SMP support. In FB3 we plan to have superserver’s abilities to handle connections and classic’s to support SMP to be present together in the single engine.

Database size limitations were removed in FB2.0, therefore talking currently about ‘small volume of data’ is totally incorrect. Firebird is also ideally scalable system – from ARM and Renessas SH with x86/x64 in the middle up to UltraSparc, IA64 and S390X. Have a look such companies use firebird: I will mention only SAS institute in the USA (they compared performance of firebird with a lot of other database engines and chosen firebird) and MICEX in Russia (they’ve primarily started to use InterBase due to its unique events delivery feature and currently successfully use firebird). Could ‘small volumes’ be firebird’s reality, such companies would never-never use it.

Therefore why do some people think that firebird is ‘for small volume of data or connections’ I really do not know… May be because it works in such cases also very well?

9) Based on past discussions, it seems that, being FB an Open Source project, the major problem in implementing extended data security is about handling the crypto “key”, in a effective and not too difficult way for the user. What are your considerations about this, any solution?

This is almost like a question about untrusted sysdba

There are a lot of tools, keeping data encrypted in database file, starting with TrueCrypt – free open source on-the-fly disk encryption. I absolutely seriously suggest all of you to build layered systems, and disk encryption layer is definitely not one which should be mixed with RDBMS. Layering is a way how unix was always designed / implemented – on contrary with windows, where a way of creating single all-purposes monsters is traditional. Please, do not go wrong ways.

10) What features you would like to develop for Firebird, but for some reason weren’t able to do so yet (and what is holding you)?

That I very much wish to see in firebird is derived tables – an ability to (sorry, DDL syntax is invited on the run, and I prefer this sample to long description):

CREATE TABLE BASE_TABLE (X BIGINT NOT NULL PRIMARY KEY, Y VARCHAR(255));
CREATE TABLE DERIVED_TABLE BASED ON BASE_TABLE (Z TIMESTAMP);
COMMIT;

INSERT INTO BASE_TABLE VALUES (1, 'abc');
INSERT INTO BASE_TABLE VALUES (2, 'def');
INSERT INTO DERIVED_TABLE VALUES (3, 'xyz', CURRENT_DATE);
COMMIT;

After this DERIVED_TABLE contains 1 record and BASE_TABLE – 3 records. This can be a great improvement to handle a lot of real word information.
What’s holding me – a lot of everyday work with firebird: posix ports, security, bug fixes, etc.

Note: The feature that Alex called as “derived table” is more known as “Table Inheritance”. Don’t confuse it with the Derived Tables feature already introduced in Firebird 2.1.

I wish to thanks  Alex for taking the time to answer all the questions in this interview. We know our developers are always very busy working for FB

« Hide it