Hi All,

It seems to me that this discussion has been bouncing around
without really getting very far. Indeed it has spun off about
how to implement roles/groups - and perhaps that topic needs
resolution before the issue of the hardcoded SYSDBA can be
finally resolved. But if we come back to the original question
of what to do about a SYSDBA user...


The early responses to this subject seemed to think that
replacing the SYSDBA user with a set of privileges (whether
they be a role or whatever) was appropriate - and I concur.

FB already has "PUBLIC" as an implied role that can be used
when assigning privileges, it would seem appropriate to have
"OWNER" - where the actually owner of a database/object could
give owner privileges to other users (there is AFAIK know way
to do this at this time).

But does that really solve the question of a SYSDBA user?


One of the issues here is that we dont have the concept of a
central server (see my comments to the topic
"Strategic Replacement for Services API"). This means that
we currently have no way of telling the server that user "x"
has "OWNER" privileges on database "y" - or even that user
"x" has "OWNER" privileges on all databases (as does SYSDBA).

So when I copy an existing database to a new server how do
I get full access to that database without a central SYSDBA
user?

Presumably I know the user name that is the actual owner so
I can add that to the server. (And if I dont know some hex
viewing of the database can probably let me discover it.)
But somehow this method seems inappropriate - perhaps it is
just me?


Is there a simple/better solution this requirement? Can we
go back to the replacement for services API topic and comment
on my suggestion that there should be "server" based privileges
for users (the ability to create databases, the ability to
change certain server configuration options etc - AND the
ability to have "OWNER" privileges on one or more databases).

--
Geoff Worboys
Telesis Computing