Hello.
We haven't exhausted our discussion on hardcoded accounts inside IB. Back
in December, I received a call from an engineer working for a consultancy
company. She was having problems with a database. Apparently, the "donkey"
customer sent to them the zipped gdb and not the gbk so I suggested a
backup/restore to solve possible side effects.
To my surprise, she was forced to provide user & pw to be able to use gbak
and isql. Knowing that she was using the administrative account on the same
NT Server machine were IB was running, I was going to suggest a restart of
the OS. I wasn't aware of this limitation. However, I remembered that I'm
one of the few here not using NT in Spanish (my native language) but the
original version in English. Contrary to UNIX's root, MS decided to localize
the administrative account in each national language, so in Spanish it's
administraDor, not administraTor and so on. As you know, IB maps
root/administrator to sysdba automatically.
When I asked in firebird-devel, Mark O'Donohue answered that a nice chunk
of code was present and confirmed my guess:
«
It is true jrd/isc.c is where it all happens, and when they say it needs to
be reengineered especially on super server I think they are pretty much on
the money.

/* This check is not internationalized, the security model needs to be
* reengineered, especially on SUPERSERVER where none of these local
* user (in process) assumptions are valid.
*/
if (!strcmp(name, "ADMINISTRATOR"))
{
»
The letter in such thread (still available through the logs of
firebird-devel, in December) took on other aspects of security that are
interesting, too. Worth reading. In this particular case of Windows with
Administrator, I think that there are some security implications for
MS-based networks. An account name is not a guarantee.

C.
---------
Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente
http://www.cvalde.com