Re: Client/Server and Oracle Security
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.caReceived on Mon Oct 31 1994 - 21:11:39 CET