HELLO! What is the minimum privilege for dbbackup -x?

[Breck_Carter]

Still wanting an answer... MANAGE ANY DBSPACE is not acceptable from a security point of view, when it comes to a user id and password that is used only for backups... it's too powerfuld.

---

Apparently the 16.0.0.1512 BACKUP DATABASE system privilege is not sufficient to run dbbackup with the -x option; it produces the error message "unable to delete transaction log".

What is the minimum required?

Granting the MANAGE ANY DBSPACE system privilege does allow dbbackup -x to run, but that seems... rather ... excessive.

Might as well GRANT NSA privileges, er, GRANT DBA 🙂

[VolkerBarth]

FWIW, here's the link to this question's prequel:

How do I diagnose dbbackup -x "unable to delete transaction log"?

[graeme_perrow · Accepted solution]

The privilege we check during the delete transaction log operation is indeed MANAGE ANY DBSPACE. Whether it should be or not is debatable (it should probably be BACKUP DATABASE), but that's the one we currently check.

[Breck_Carter · Accepted solution]

I can guess how it happened: at the micro (engineer) level it "makes sense" since deleting a log is indeed "managing a dbspace". At the macro (user) level, not so much 🙂

IMO if the log is being deleted as part of a backup operation, then the privilege checked should indeed be BACKUP DATABASE (or nothing, since presumably BACKUP DATABASE is known to be in effect since it IS, after all, a backup 🙂

If there is some other context in which the log is deleted, then perhaps some other privilege is required.

If this is the only goofiness in the massive privilege overhall, then good on ya... a better record than healthcare.gov 🙂

[VolkerBarth · Accepted solution]

Just to add:

In case you are re-thinking the granularity of the privileges, one further issue with MANAGE ANY DBSPACE may be the following:

Currently ALTER DBSPACE ADD [SYSTEM | TRANSLOG] 100 MB etc. requires that privilege, too. In my experience this is often much more of a simple "prevent database file fragmentation" maintenance task than a database design decision - in contrast to the creation, dropping or renaming of additional dbspaces.

Therefore I would think it could be changed to require less or different privileges, say SERVER OPERATOR.

(Of course one could create a particular STP to allow non-privileged users to pre-grow the database/translog...)