Subject Re: Database Security, or lack thereof
Author Adam
>
> > It is quite possible to create a secure environment using
Firebird,
> > but you must go in using the Firebird mindset.
>
> If so, I'd like to see an example that's not going to take a lot of
> time to set up and maintain.
>

Hehehe. The not long to set up is the key, and this can be hard
depending on whether your application(s) are already multi-tier. Here
are some options to consider. They may not be possible or practical,
but we can only try :)

It will be quite hard if you have to convince people to change the
way they design the applications architecture (or that they actually
need to design it).

There are two aspects to security IMO. OK, there are a lot more, but
I will focus on two.

Firstly, there is the protection of access of the data. This is not
about preventing people from doing bad stuff to your data, but rather
to avoid them getting the data in the first place. Basically you need
to make sure the fdb file is not accessible. For this, hosting the
application over a terminal server or using a product like Zebedee
can allow you to lock down the fdb file.

Secondly, there is the protection of the data itself. On this point,
I want to make one thing clear. If you give me access to insert data
(or even update in FB), I can your fill your database and possibly
exhaust the system resources. In fact, even with select queries, you
could probably do it. If you allow anyone to execute anything within
the bounds of their user security, you are asking for trouble. We do
not allow our customers to execute any SQL statement that we have not
written (ie. They fill parameters).

Create a data access layer to your application, and don't have your
application access the database directly. Then you can firewall off
the database from the client machines, and there is no risk of rogue
ddl being executed.

>
> It also lacks other features I would consider standard for a
> production dbms, like builtin transaction logging and recovery.
>

I agree it is not ideal that FB lacks these features, I would argue
they are all *needed* for a dbms to be considered production ready.
There are third party options for logging by the way.

> >I suggest you read the plans for Firebird 2 and 3 to see.
>
> Small consolation for today.

FB2 is now in its second alpha. Not production ready yet, but also
not that far off.

>
> Firebird seems to be on the right track, but its not even close to
> there yet. Hopefully I'll be able to work around its current
> shortcomings.

I hope so. The good thing about FB as compared to the sausage (I had
to use that reference once) is that you know what goes into it. You
are not mislead into any false sense of security. Only you know your
requirements in this area. If FB can not be used, don't use it. If
there are only a few mounds to climb, try and find a way.

Adam