I got a question today from a co-worker who was painted into a corner trying access a database he had restored on his Windows development machine. He stumbled over DB2 9.7’s new security twists, such as not having dbadm authority by default. I rattled off my familiar quick fix:
db2 connect to <dbname>
db2 grant dbadm on database to <userid>
However, his default Windows user ID didn’t have secadm or sysadm authority, so that failed with an error. So, I had him impersonate the one that did:
runas /user:<adminuser> db2cmd
Repeating the grant command from this new command shell did the trick. It could have also been done with:
db2 connect to <dbname> user <adminuser> using <adminpassword>
And so it goes. No matter how refined security policies become, they can usually be circumvented with a little impersonation. For example, think of how many times we quickly and mindlessly sudo under Ubuntu. In this case, impersonation was a fast route to giving a developer the access he should have had by default anyway. Today’s technology cannot solve the impersonation problem, but sometimes we consider that more a feature than a bug.