Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!postgres!larry
From: larry@postgres.uucp (Larry Rowe)
Newsgroups: comp.databases
Subject: Re: More on RTI Security Hole
Message-ID: <3652@zen.berkeley.edu>
Date: Wed, 9-Sep-87 13:58:33 EDT
Article-I.D.: zen.3652
Posted: Wed Sep  9 13:58:33 1987
Date-Received: Fri, 11-Sep-87 04:30:32 EDT
References: <9199@brl-adm.ARPA>
Sender: news@zen.berkeley.edu
Reply-To: larry@postgres.UUCP (Larry Rowe)
Lines: 24
Keywords: Ingres Security Hole exists

In article <9199@brl-adm.ARPA> angel@brl-adm.ARPA (Rick Angelini <angel>) 
writes:
>MORE INVESTIGATION on .....
>
>Yes, there is indeed a hole in the table permissions.  A user may 
>append/delete/modify any system table, without special flags or 
>special permissions.  There exists a flag in the user profile which
>determines whether or not a particular user is permitted to updates
>system tables, but Ingres appears to ignore that flag.  

The security flag controls the system tables managed by the back-end
(e.g., relation, attribute, indexes, protection, tree, and the statistics
tables).  the front-end tables are not protected.  the reason is that the
front-end programs themselves have to update the tables.  ingres would
have to be modified to determine which updates were valid (i.e., legal
updates from front-end packages) and which were invalid (i.e., user-supplied
updates).  it would take some energy to put into the system.  RTI hasn't
done it because there were/are other features deemed more important.

in fact, there have been times that the feature has been used by application
builders to clean-up problems they created and to perform operations not
directly supported by the front-end tools.  nevertheless, it is a hole
that should be fixed someday.
	larry