Hi Alfred,

> A few points still remain unclear to me:

> * I design a database and grant access to a user other than SYSDBA
> e.g. MASTERUSER

If you want MASTERUSER to be the owner of the new database, you:

- Connect to the Firebird server as MASTERUSER.
- Create the database.

If you create the db as SYSDBA, you can grant any rights you want to
MASTERUSER but that's more work. And everytime you add objects to the
database, you mustn't forget to grant MASTERUSER rights to those new
objects. So better create it as MASTERUSER and save yourself a couple
of headaches :-)

> When the user installs FireBird they don't have a user MASTERUSER,
> so they won't be able to connect before SYSDBA creates MASTERUSER.

Correct. If you or your user can get the SYSDBA password, you can do
it yourself (or your app can do it, if you let the user type in
SYSDBA's password somewhere).

If whoever has the sys pwd won't let you have it, that person must
create user MASTERUSER, and you or your user must know MASTERUSER's
password, before you can log as MASTERUSER and create the db.

> BUT should I give the SYSDBA password to the DBA of the one system,
> he can also access the data on different systems, hosted on the same
> machine.

What do you mean by "systems" here? Normally there is only one
Firebird server running on a machine. And a Firebird server can only
have one SYSDBA with one password. On other machines, SYSDBA may have
the same or another password. That depends on who's installing and
managing Firebird on those machines.

Oh, by the way: a Firebird server can be reached over a network from
lots of machines. But since the user management is centralized, once
you know a username and password, it doesn't matter from what machine
you log in to that server, you still use that one user+pass to access
the database. Another thing: the database must be _physically_ located
on the server machine (not via a network path).

> He can also change the passwords for other systems.

Only if he knows the current password(s) for those systems. In which
case he can probably be trusted with that knowlegde. Anyway, changing
SYSDBA's password doesn't have an effect on how normal users connect
to their databases!

> Should I not give the SYSDBA password to anyone and handle user
> management myself?

Well, it depends. If you keep the SYSDBA password to yourself, that
means you make yourself DBA. Are you around those machines if
something must be done that requires SYSDBA rights? Then you could
do it.

> * When the database is backed up, should security.fdb also be backed
> up to make sure that the user information aren't lost?

No. You can make regular backups of security.fdb, but better not to
the same location as the user databases. And after all, lost users can
be recreated in a pinch.

> * Would a better solution be to have a single user which everyone
> uses to log in and a seperate USER table to validate user etc.

That's a lot of work to implement reliably. If already it's possible.
After all, if everybody logs in as the user who owns the database,
everybody can change the structure, grant themselves rights to tables
etc., so there would be no way to keep individual users from
accessing, altering or deleting whatever data they want.

Also note that if you do this, you're building a complete extra level
of (crummy) user security in each and every database! Why not use the
user security that's already there, and that's reliable?

> This would mean that every user can have the same username for
> every different system.

If you want to create the same users on different systems you can
still do that. You need SYSDBA rights anyway, whether you create 1
user or a hundred. The only problem may be that if someone won't give
you the SYSDBA pasword, he may be willing to create 1 user for you but
not a hundred. But in that case you can write a little app or script
and let him run it, supplying the sys pwd in an input field.

I really don't see what your big problem is with the current security
model - except that it's different from what you expected. Maybe you
should concentrate on the concrete task you have to carry out, and ask
questions about that if and when you get stuck.


Greetings,
Paul Vinkenoog