Subject | Database Security, or lack thereof |
---|---|
Author | lance8086 |
Post date | 2005-05-08T00:06:06Z |
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?
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?