> Probably you should consider special rights for: CREATE DATABASE:
> some (or several?) people run IB on its default account.

In going open source, we nix licensing, thus we loose
the ability to govern functionality via the license
file (eg. The Metadata License, Client License).

I do not think it is unreasonable, well at least worth
considering, the idea of enhancing SQL security to
encompass areas like:

Server Wide Security

CONNECT <database> -- you may want to have a valid
system user but restrict connect access by database
or maybe we rethink isc4.gdb and move it into each
database.

(eg. GRANT | REVOKE CONNECT ON <db> TO <user>)

CREATE <database> -- we definately need a mechanism
to keep rogue, malicious users from creating
databases.

(eg. GRANT | REVOKE CREATE_DB ON <server> TO <user>)

Database Wide Security

CREATE/ALTER/DROP <object> -- should be under SQL
security. While we all enjoy hacking the system
tables, I think in our new OSS world it might be
good to put them under SQL security like user
tables too.

(eg. GRANT CREATE <object_type> ON <object> TO <user>)

> In NT, no more than the operating system itself. Running IB as a service
> under another account with permissions only on the database directory and
> the temp directory should alleviate things.

In my experiences working with customers, this is the rare
case (at least with NT). Most customers don't even have a
routine database backup plan or a UPS for their db server.
This blows my mind but, its the first question I ask when
taking a support call and the answer is almost always "We
dont have a backup, or what do you mean -- a backup??".
Most that do backup use file level method and backup the
database file, which IMHO is next to worthless. The later
issue needs to be heavily documented in BOLD pronto. Its
our fault for not being more forthcoming about why its
important to backup the backup file not the database file.

InterBase is so easily embeddable it often gets installed
without an NT admin knowing its there thus, unless instructed,
they don't know they need to protect the associated files with
OS level security. Perhaps an enhacement to the install API?

> - EXTERNAL FILES: the other day I mapped an already extant HTML file on my
> machine as an external table with a long varchar and I was able to read it.
> There must be some restriction on such declarations. What if I was able to
> rewrite a file by this means?

Even scarier (is that right?), think about mapping a UNIX
security file as an external file. You cannot update/delete
but, you can add to the file.

> - GENERATORS: let's assume for a moment my name is Disgruntled Employee. I
> want to cause havoc. I investigate metadata and discover the name of some
> generators.

Out of curiosity, how many people reading think a database
server should have intelligence to protect against a disgruntled
employee (eg. a DBA who knows all there is to know about IB)?
Maybe I am just thick headed but, it seems like a waste of
energy to me. If someone has access to the system and their
pissed off enough to trash your data, your bummed if you can't
smash thier fingers before they smash your database. InterBase
is not Santa, it cant know who's naughty or nice. I believe
that the OS and the system admin must take some responsibility
here. I think security can be improved but, the angry employee
scenario bugs me. If you've have a defective employee, you
remove their network access and then terminate them. Not the
other way around.

Adding SQL security to system tables could eliminate the
GENERATOR issue (plus other similar ones), minus the defective
DBA or employee.

> In the general functionality, I would love to see a
> read_only/read_committed txn that doesn't stop the OAT advance.

I'll let the experts comment here but, I think the functionality
already exists and just isn't published. Txn 0, I think.

Markus