Re: Security Question

In Article<3159EC10.76BB_at_netusa1.net>, <rpj_at_netusa1.net> writes:
> Path: duke!news.netins.net!newsrelay.netins.net!imci5!pull-feed.internetmci.com!news.internetMCI.com!newsfeed.internetmci.com!news.netusa1.net!usenet
> From: Bob Jones <rpj_at_netusa1.net>
> Newsgroups: comp.databases.oracle
> Subject: Re: Security Question
> Date: Wed, 27 Mar 1996 20:32:00 -0500
> Organization: NetUSA1 Inc.
> Lines: 50
> Message-ID: <3159EC10.76BB_at_netusa1.net>
> References: <4jade5$o10_at_ixnews2.ix.netcom.com>
> NNTP-Posting-Host: indyi45.netusa1.net
> Mime-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: quoted-printable
> X-Mailer: Mozilla 2.0GoldB1 (WinNT; I)
>
> Look into roles with passwords that you do not tell the users. =
>
> The application can activate the roll and get rights to alter =
>
> the data.
>
> Having everyone log as the same user is generally a poor idea. =
>
> It does not allow for traceability, and troubleshooting is a =
>
> bear when all sessions show up as user DoeJ!
>
>
> -------------------------------
>
>
> Bill Jonnard wrote:
> > =
 

> > How can I prevent a group of users from performing any kind of manual
> > adjustments to the data, while still allowing them to use SQL*Plus to
> > do ad hoc queries? Currently, I have multiple users, but only one
> > Oracle user ID, so once somebody gets into SQL*Plus, I can=92t prevent
> > them from performing manual inserts, etc. which I want to do.
> > =
 

> > If I set up a second Oracle ID that uses synonyms into the main
> > database (and is only granted select privs on all the tables), the
> > user could easily defeat this measure by logging into the "view-only"
> > Oracle ID, and then running the "connect ID/password" command from the
> > SQL prompt to get into the "main" database. Obviously, this isn=92t
> > much of a solution. It would be useful to be able to somehow disable
> > the connect command, and thus prevent someone from switching into one
> > database from another, but I do not know how (or if) this is possible.
> > =
 

> > Similarly, it would appear that even if I were to set up separate
> > Oracle IDs/roles for each specific user, someone could still run the
> > "Connect ID/Password" command, and I=92d be back where I started.
> > Again, I am unaware of any means to restrict a user to using a certain
> > Oracle ID specified at the Operating System level, or how to somehow
> > disallow "write access" to the database while still allowing "read
> > access". (The OS is VMS)
> > =
 

> > Is there any way to let someone use SQL*Plus, but to absolutely
> > prevent them from modifying the data unless they have been given the
> > explicit "GRANT INSERT/DELETE/UPDATE" privs on that table? If anyone
> > could give me a few pointers as to how to best solve these problems,
> > I=92d appreciate it very much. Thanks in advance for any help.

It is also possible to use stored procedures. The stored procedure, assumes the permissions of the creator, not the executor. Thus, you can create the stored procedure judiciously, and then grant execute (at the object level) to certain users.

Under such a method, it is possible that users can be totally blocked from any action on a table but still be able to DML the table under carefully controlled application constraints. Received on Fri Mar 29 1996 - 00:00:00 CET