What are the things one DBA can do that the other DBA cannot do?

[VolkerBarth]

Based on some discussions on the power of the DBA authority lately in this forum, I have the impression that there's a general rule for SQL Anywhere like the following (to cite Justin😞

By definition DBA can do anything - they are the owner of the database.

So I would like to know what exactly DBA1 can do that DBA2 cannot undo or drop?

Some more discussion on this can be found in the newsgroups, e.g. in these threads:

• Untouchable DBA account

• Protect one DBA from another

---

I should add that this question is not dealing with topics like "Do users of my application need DBA authority to do backups or create other users?" - For these cases, it's a widely accepted best-practise to give particular users execute permission on according stored procedures (and the like) to allow these DBA actions, but to do not grant them DBA authority.

This question is more focussed on enterprise/in-house databases with more than one DBA account.

[Breck_Carter]

Well, there's Dogbert the patron saint of DBAs... he can perform miracles.

[VolkerBarth]

Hmm, I hope the list below could be improved over time to count as "actual issues", Saint Breck?

[VolkerBarth · Accepted solution]

I'd like to attempt to make a list of the things DBA2 can or can not do - and I would invite anyone to add/comment on this - consider this just a starting point...

Basically, I will assume there are two users with DBA authority named DBA1 and DBA2, and would assume that DBA2 might turn into malicious intentions:

---

I. What DBA2 can do:

• DBA2 can alter or drop any database object any other user (including DBA1) has created.
• DBA2 can alter (grant/revoke) any permissions on any database object.
• DBA2 can revoke DBA1's DBA authority - and vice versa.
• DBA2 can drop DBA1's user account or change its password (or set it to an empty string to disallow any connection from DBA1) - and vice versa.
• DBA2 can modify/drop any login procedure that would try to enforce particular login logic.
• Encrypted tables/columns are just stored in encrypted form, but are decrypted when accessed - therefore any user with access to such data can read the "plaintext", including DBA2.

---

II. What DBA2 cannot do:

• As anybody else, DBA2 cannot read the source of any object SET HIDDEN by DBA1 (and cannot set it UNHIDDEN, as there no such statement - but DBA2 can still ALTER the object).
• Strong database encryption is beyond database authorities: In case DBA1 knows the DBKEY whereas DBA2 does not know it, DBA2 won't be able to start the database if this requires the entering of the DBKEY. The same is true for translating encrypted logs.
• In case the database server runs with secured features, and a key is specified to allow secured features in particular cases, and only DBA1 knows this particular key for this (dbsrv12 -sk key), DBA2 cannot re-enable these features. (However, DBA2 might be able to start the database - or a copy - on his own without securing these features or with a different key).
• In case the database contains data that is encrypted on an application level (i.e. outside the database), and DBA2 does not know about that encryption, then he cannot read the decrypted data (but could change it to anything else).

[Breck_Carter · Accepted solution]

Isn't this true for all user ids, DBA or otherwise? "cannot read the source of any object SET HIDDEN"

[VolkerBarth · Accepted solution]

Yes, it is, but in contrast to others a DBA2 could still alter these objects...

But to clarify, I'm gonna change this to "anybody cannot" - as even DBA1 cannot un-do that operation.