Re: Client/Server and Oracle Security

From: Bruce McCartney <bmccartn_at_dbcorp.ab.ca>
Date: Mon, 31 Oct 1994 20:11:39 GMT
Message-ID: <bmccartn.31.000F31D7_at_dbcorp.ab.ca>


In article <1994Oct28.165023.281_at_seb.se> s26495_at_seb.se (Per Stromsjo) writes:
>Subject: Re: Client/Server and Oracle Security
>From: s26495_at_seb.se (Per Stromsjo)
>Date: 28 Oct 94 16:50:23 CET
 

>In article <bmccartn.24.000CEE68_at_dbcorp.ab.ca>, bmccartn_at_dbcorp.ab.ca (Bruce McCartney) writes:
 

>[ stuff deleted ]
 

>> my company (DBCORP) has a windows based product called secure*db which will
>> let you do this in a couple of ways. the best way is to create 'hidden' id's
>> for the end-user that have all the application privs, and let the end-users
>> base id have 'public' privs. secure*db has features to enable the hidden id
>> from windows or unix programs.
 

>[ stuff deleted ]
 

>I believe the preferrable solution would be to incorporate this func-
>tionality into the RDBMS. More or less like stored modules authorized
>to execute in 'definers rights' in DEC Rdb.
 

>Cheers,
 

>/per

agreed that the preferable route is the rdbms, DB2 also has the concept of a bind plan which gives users the right to execute all the sql in a particular program. the issue for oracle users is that not all (or even most) of the apps out there use server-based pl/sql, or even passwrod protected roles. until that time, for apps writen with dynamic sql, a scheme must be used to deal with the issue...

bruce

Bruce McCartney                                  Voice:  (403)-237-6130 
DBCORP Information Systems Inc.                  Fax:    (403)-237-6135
2060 140 4th Avenue SW                           Cell:   (403)-680-1802
Calgary Alberta, Canada T2P 3N4                  bmccartn_at_dbcorp.ab.ca
Received on Mon Oct 31 1994 - 21:11:39 CET

Original text of this message