Simon Says

There was a bit more dialog today about impersonating the DB2 instance owner.  It’s a quick way to get around controls that newer versions of DB2 and tighter Windows and network security have brought us.  The extra step is annoying, but trying to convince the system you don’t need it is often worse.

Impersonation and elevation have become the “new normal” these days.  I’ve grown so accustomed to opening “run as administrator” shells in UAC Windows (7/Vista/2008), typing runas commands in XP, and using sudo in Ubuntu that these have become second nature.  And that level of user acceptance usually translates into approval to expand the practice, rather than a mandate to remove the inconvenience.  Enhancing security usually includes putting up new barriers.

A former co-worker has often said that what we really need is software that determines whether a user’s intentions are honorable.  Perhaps then security would become seamless.  But it’s more likely that its implementation would also test our manners and fading patience.

Share This:
  • Print
  • Digg
  • StumbleUpon
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • Google Buzz
  • RSS

One thought on “Simon Says

  1. Derek Post author

    Today, Wayne pointed out that one authorization challenge of late was caused by recent domain/directory changes which blocked retrieval of group information for network user IDs. So, domain IDs (like our per-user IDs) could not be authenticated, while local admin IDs (residing in local groups) could. His work-around to return DB2 admin rights to domain IDs was to tell it to just use the local group lookup:


    Which can be verified with:

    db2set -all | find /i “grp”

    For a good description of the merits of this setting, see, How to Develop DB2 Applications on an Airplane.

    I savored this new trick a few minutes until Jack pinged me for help correcting a failed DB2 9.5 install on a Windows 2008 R2 server. Upon launching DB2’s setup.exe, Windows presented the UAC elevation prompt, which gave the false sense that it had the admin rights it needed and all would be well. But, alas, the installation gave several obscure error messages and did not work. Fixing it was quick, however, and you can probably guess what I did: yes, I started setup.exe in a “run as administrator” command window. The “sudo sledgehammer” is quite a golden hammer.

Comments are closed.