Date:         Mon, 9 Oct 1995 13:35:13 PDT
Reply-To:     The NOMAD2 Discussion List
Sender:       The NOMAD2 Discussion List
Comments:     CPVMA    TGMRI    10/09/95 13:37:28 INTERNET
From:         "Gary M. Rickman (5"
Subject:      User Survalance

To: NOMAD2L --INTERNET

*** Resending note of 10/09/95 08:52
From: Gary M. Rickman   (510) 842-1826   CP-L4086    GMRI@chevron.com
Subject: User Survalance
We had a similar need for isolating one user's entries from another
users while using a DB2 database.  We solved that by using VIEWs to
separate the data.  The base table had a column where we stored the
userid of the person who made the entry.  The view on top of the
table had a WHERE clause that specified "WHERE colx = USER".  In DB2
(and I assume SQL/DS is the same), "USER" is a keyword that caused
the view to substitute to userid of the current user into the where
clause at runtime.  That prevented everyone from seeing anyone else's
records during retrieval.  Adding the clause, "WITH CHECK OPTION",
causes the WHERE clause to be checked on insert/update as well.  Together
that prevents anyone from doing anything to anyone else's data.  The
Nomad schema should map over the view.  Users should have appropriate
privileges granted on the view and noone should have update privileges
on the base table.

Another possible solution to isolating these two group's data is to
put the data in separate tables.  Create the table twice under
different "CREATOR"s.  Each group can have appropriate privileges on
only their own tables.  In Nomad2, you can use "MODIFY mastername
CREATOR creatorname" to point the schema at the proper table.  Even
if the users figure out how to use the MODIFY command, it won't do
them any good because their userid won't have privileges to access
the other groups table.  SQL/DS will keep the data secure.

>      I have a rather large application that users from two separate
> geographic areas use.  The two areas are competing for the same type
> of work from a series of customers.  I have run into a situation where
> one area is deleting the other areas records and creating their own
> so that the system directs the work their way.  I have put a stop to
> this by checking the user security in the procedures that are used and
> either allow or disallow the action.
>      My situation is that one of the users in the area in question is
> capable of creating procedures that he can give to his users that will
> over ride my changes.  Our environment is VM with Nomad 6.03 and SQL/DS.
>      My question is --- is there a way to have the Schema write info to
> a data audit table if a delete is performed?  I've looked at the Rule
> and uproc statements but these appear to either allow or disallow a
> function, not track a function.  Audit appears to write to a dataset
> and not to a table.  Our users don't access any disks as read/write so
> the only location I could write the audit file to is their 191 disk.
> This would not allow me to view the audit file.  Any ideas?
>                                             Thanks, Daniel J. Yeager
>                                                     Yeagerd@Timken.com
back to index