467,134 Members | 929 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,134 developers. It's quick & easy.

DBA command

In a multi-database development (DB2V8.1.4/AIX) environment I want to
enable regular non-DBA database users (i.e. developers) to execute
some DBA commands including update some database configuration
parameters affecting application performance, like DFT_QUERYOPT, sort
heap size, etc, without giving them DBA logins. Is it poosible to
implement that facility as an application (whether client side or
stored procedure) using DB2 Administrative C API, bound by a DBA user,
and then granting execute permissions on the stored routine or package
to a regular users?

Thanks,
-Eugene
Nov 12 '05 #1
  • viewed: 2817
Share:
3 Replies
Eugene,

Have you considered doing this via Unix shell scripts and just
granting execute access to those users?

Chet

eu****@profitlogic.com (Eugene) wrote in message news:<95**************************@posting.google. com>...
In a multi-database development (DB2V8.1.4/AIX) environment I want to
enable regular non-DBA database users (i.e. developers) to execute
some DBA commands including update some database configuration
parameters affecting application performance, like DFT_QUERYOPT, sort
heap size, etc, without giving them DBA logins. Is it poosible to
implement that facility as an application (whether client side or
stored procedure) using DB2 Administrative C API, bound by a DBA user,
and then granting execute permissions on the stored routine or package
to a regular users?

Thanks,
-Eugene

Nov 12 '05 #2
Chet,

We had implemented that kind of short term workaround using unix's
sudo but IT is not happy with that and treats it as a security hole.
So I am being forced from permanently using unix superuser level
faciities (except for the standard DB2 user authentication of course)
and hence trying to find a solution just at DB2 level.

Regards,
-Eugene
ch******@yahoo.com (ChetWest) wrote in message news:<47**************************@posting.google. com>...
Eugene,

Have you considered doing this via Unix shell scripts and just
granting execute access to those users?

Chet

eu****@profitlogic.com (Eugene) wrote in message news:<95**************************@posting.google. com>...
In a multi-database development (DB2V8.1.4/AIX) environment I want to
enable regular non-DBA database users (i.e. developers) to execute
some DBA commands including update some database configuration
parameters affecting application performance, like DFT_QUERYOPT, sort
heap size, etc, without giving them DBA logins. Is it poosible to
implement that facility as an application (whether client side or
stored procedure) using DB2 Administrative C API, bound by a DBA user,
and then granting execute permissions on the stored routine or package
to a regular users?

Thanks,
-Eugene

Nov 12 '05 #3
Ian
Eugene wrote:
Chet,

We had implemented that kind of short term workaround using unix's
sudo but IT is not happy with that and treats it as a security hole.
So I am being forced from permanently using unix superuser level
faciities (except for the standard DB2 user authentication of course)
and hence trying to find a solution just at DB2 level.


I was going to suggest sudo, but I am surprised that your IT
organization sees sudo as a security risk! sudo can control
exactly what config params can be updated, who can update them,
and it will even log who is doing what.

Creating a suid binary is a _much_ larger security risk. The
only difference is that your IT folks may not know what you're
doing.


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by TEK | last post: by
8 posts views Thread by Siemel Naran | last post: by
34 posts views Thread by Roman Mashak | last post: by
13 posts views Thread by Chris Carlen | last post: by
reply views Thread by czerwww | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.