A quick visit to the FAQ, knowledge base or a search of this forum
would alert you to these restrictions. You are not uncovering anything
unknown.

Here are some more:

Copy the fdb file from the database server to an install of the
database on a different machine, and you can use the sysdba account on
that machine to compromise security.

It is quite possible to create a secure environment using Firebird,
but you must go in using the Firebird mindset. I highly suggest that
you read the article by Geoff Worboys. It has concerns that must be
addressed if you are to take security seriously regardless of your
chosen rdbms.

http://firebird.sourceforge.net/index.php?op=doc&sub=contrib&id=fb_meta_security

By the way, I do agree with you that FB security does lack features
available to other databases. I suggest you read the plans for
Firebird 2 and 3 to see.

http://firebird.sourceforge.net/index.php?op=devel&sub=engine&id=roadmap

Also, nothing official here, but certainly of interest.

http://firebird.sourceforge.net/index.php?op=devel&sub=engine&id=secur_diary01

and when this is actually completed it will be a good reference too.
http://firebird.sourceforge.net/index.php?op=devel&sub=engine&id=security

Hope that helps
Adam




--- In firebird-support@yahoogroups.com, "lance8086" <lance8086@y...>
wrote:

> I come from an MSSQL development environment. We're evaluating the
> possibility of replacing MSSQL with FB to cut costs for our new
> clients. I've been playing with it for a few days now, Firebird-
> 1.5.2.4731-Win32.exe
>
> The first thing I discovered was that the FB design lets any user get
> into any database, but the MSSQL design restricts the user to
> specific databases. That has the potential to cause a lot of
> possible security problems.
>
> For example, a user with access to the 'sales' database could also
> connect to the 'personnel' database. Even though the user can't see
> the data, they can get at the schema (select * from rdb$relations,
> etc). They can also create and fill new tables in the database.
>
> And here's a really scary scenario:
> SQL> create database 'localhost:c:\fb\foobar.fdb' user 'sysdba'
> password 'masterkey';
> SQL> commit;
> SQL> connect 'localhost:c:\fb\foobar.fdb' user 'user2'
> password 'pass2';
> Database: 'localhost:c:\fb\foobar.fdb', User: user2
> SQL> delete from rdb$pages;
> SQL> commit;
> SQL> connect 'localhost:c:\fb\foobar.fdb' user 'user2'
> password 'pass2';
> Statement failed, SQLCODE = -902
> database file appears corrupt ()
> -wrong page type
> -page 0 is of wrong type (expected 6, found 1)
>
> In my opinion (and in MSSQL), user2 shouldn't even be able to open
> the foobar database unless explicitly given permission, let alone
> destroy it. And I shouldn't even have to worry about stuff like
> this - that's the db engine's job, not mine.
>
> Did I miss something?