Eugene,

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

Chet

eugene@profitlogic.com (Eugene) wrote in message news:<9573e6b2.0408171056.5721565a@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

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


chetwest@yahoo.com (ChetWest) wrote in message news:<47c93e56.0408180625.22570268@posting.google. com>...
> Eugene,
>
> Have you considered doing this via Unix shell scripts and just
> granting execute access to those users?
>
> Chet
>
> eugene@profitlogic.com (Eugene) wrote in message news:<9573e6b2.0408171056.5721565a@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

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! =-----