At 10:02 AM 5/04/2004 +0200, you wrote:

>Hi
>
> > I may be overlooking something obvious here, but if you alter the password
>for SYSDBA to something only you know then no-one else can connect to the
>database via any management tools as the connection needs the password and
>username to be valid.
>
>No.
>Reinstall firebird. You get a new sysdba default password. The database
>remains accessable.
>There seem to be some steps to make it harder, as i heard about some tricks
>using a role "sysdba". But I havn't tried.
>
>Anyway, Firebird isn't designed for such things.
>If you need to secure access to the database, store it on a dedicated
>server, block port 3050, use ssh to connect to it encrypted, somehow connect
>an ssh client to your fbclient.dll and store the ssh key on a smartcard.
>This should be secure. Forget about sysdba passwords in this scenario, keep
>"masterkey".
>Afaik it is relatively easy connect to a firebird database if you can see
>every traffic on the network.

Sure; but if you are a lazy developer and can not be bothered with things
like installing roles and security privileges in the database, connecting
to the database won't actually get a non-sysdba access to anything. Still,
if you are that lazy, you probably wouldn't bother to protect the sysdba
access either, so anyone in the world could hit your database.

What does need fixing currently is that an authenticated user of the server
can access any database on it and create new objects. No non-sysdba user
can drop or alter objects it doesn't own; but a malicious person could
create a table and pour data into until it exhausted the system.

Some of the questions and observations coming from these guys makes me
wonder whether they are aware that Firebird is not a desktop data
engine...and also that there is no such generic thing as "an SQL data
engine". Firebird and MySQL, for example, both talk SQL, but they are
apples and oranges when it comes to what they do and how they do
it. Access talks an SQL-ish language to the public but there's a different
language beneath (that probably should be fed to swine).

SQL is not an architecture. It's not a data management specification. SQL
is a query language and only a query language. It has a multi-voluminous
standard associated with it that RDBMS vendors try to comply with (or try
to pretend they comply with...). The standard says "if you want to do
this, say it like this and produce results like this without breaking this
or this or this". That's all there is to it.

SQL is not even Firebird's "mother tongue". Under the blankets, it talks
another language that can interpret SQL, GDML (another query language) and
Mickeymousian, too, if it ever got to be a query language.

On the surface (the bits we are seeing) those guys seem pretty ill-informed
in some of the sweeping statements they make about "SQL RDBMSs". I'm
curious about why they do that...

/heLen