At 05:21 PM 24/05/2005 -0700, Sam Hunt wrote:

>as far as I know, a user who happens to have IBOConsole cannot do
>anything to a FB database, unless they have sufficuent network rights
>and know the server's (security.fdb) password.

By "the server's (security.fdb) password" I assume you mean the SYSDBA
password. The security database (security.fdb) contains the usernames and
passwords of all users on the server, including SYSDBA. SYSDBA is a
user. It happens to be the only user that has full destructive rights on
every database on the server and on every object inside every database.

Databases that were created or restored by SYSDBA shouldn't be deployed
into production. Db's and the objects within them should be created and
restored by a user that is created for exactly the purpose of owning a
specific database. As Owner of both the database and the objects within
that database, that user has *almost* the same power of life of death over
*that* database as SYSDBA has over *all* databases.

In the atmosphere of "freedom" that Richard's customers aspire to, any user
on the server can create objects inside a database he doesn't own, and can
grant and revoke privileges to/from those objects. The problem for the
Owner of that database is that he can't do anything with objects he didn't
create, because he doesn't own them. Here's where SYSDBA and Owner rights
differ.

>I suppose they "could" snoop around a DB, IF they got a copy of it, but
>what good would it do them, unlerss they can erase/replace the original,
>which they shouldn't be able to do, if they don't have complete netwotk
>righjts to the db
>dir.

You're getting confused between filesystem rights and database
privileges. Any user defined in security.fdb can log into any
database. However, only bona fide users of a particular database - those
that have access privileges defined for them in that database - can see or
do anything. What they can see or do with ad hoc tools is defined by the
privileges that have been granted to them. What they can see or do with
bespoke applications might be additionally restricted, by custom access
code, but those particular restrictions obviously don't apply if the users
are using third-party tools to access databases.

Only the database Owner or SYSDBA can drop a database.

Any user defined in security.fdb can create a database.

However, at filesystem level, anyone at all, whether defined in
security.fdb or not, can steal database files if the filesystem security
doesn't stop them. Under the same filesystem security conditions, this
rogue user can also delete or overwrite the database if there are no active
connections.

>I'm certainly open to learning. I'm new at this.

:-)

./heLen