Re: Increase Security
Posted in 1995
In article <46k6fg$571@cssun.mathcs.emory.edu>, johnl@informix.com (Jonathan Leffler) wrote: > Cheryl, > > >From: cherylk@spamis.jcdc.doleta.gov > >Date: Tue, 24 Oct 1995 20:00:31 -0500 (CDT) > > >On Tue, 24 Oct 1995, Jonathan Leffler wrote: > >> [...] > >> The fundamental problem with any security system in SQL-based systems is > >> that if UserA needs UPDATE privilege on TableB when using ProgramC, it is > >> nearly impossible to prevent that user from updating TableB via DB-Access > >> or ISQL as well. DBA-privileged stored procedures almost work -- but what > >> happens if the user crashes the program which arranged for the privileges > >> to be granted? Answer -- the privileges stay granted. The only possible > >> exception might be if the database has transactions and the privileges are > >> granted within an uncomitted transaction, but then do the privileges take > >> effect for some other process; I doubt it. I don't have a solution for > >> this problem. > > >That last par from Jonathan is the whole problem with Informix DB > >security (do you hear me Informix?). Hopefully the ROLES permission in > >Informix 7.1 address this. > > You missed my point -- what I said applies to any (ANY) SQL-based system > which uses just SQL privileges. Roles do not affect this. If I can do SET > ROLE using a program which I am supposed to be able to use, I can also do > it using the interactive facility of my choice. And this, too, applies to > any (ANY) SQL-based system in the absence of non-SQL controls. Unless > someone else knows better, of course. You missed his - or someone else's point. Also, what you say does not necessarily hold true for ANY SQL-based system. (Unless ANY-SQL is a trademark of Informix ?). The way database roles and privileges work in Oracle - crashing a program which has raised a password protected role does not affect any other session's privileges. Yes the privileges stay granted - to the role ! The role is not raised in any session unless it is explicitly raised with the correct role password. I am not an advocate of securing access based on client access path, although with Oracle7's role functionality this is possible. The problem comes in keeping the role password secret - and yet still allowing the application to know or obtain it. There are, however, techniques for achieving this. > > Anyway, if you are hoping roles will allow you to control which program, > then, in my unofficial view, you will hope in vain. > > Yours, > Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>