vanhattum@pttrnl.nl (02/19/91)
ANTICIPATED PROBLEMS WITH 600 INGRES-END-USERS
At PTT-Research (the research-part of the Dutch mail- and telecom-company),
we are building an Ingres-application with which employees should register
how much time they worked on their projects. Eventually, over 600 employees
should work with this application. We anticipate several problems and
that's why we want to ask you for suggestions.
We are currently working with Ingres 6.2/02 on a VMS 5.4 -platform.
PROBLEM 1: security
To run an Ingres-application one should have Ingres-end-user facilities.
When you have end-user facilities, you can run the application and also
Ingres-tools like isql, qbf and abf. To protect the data you could give
grants for select-queries only. All insert-, delete- and update-queries
could be handled by database-procedures which should be granted as
executable.
A smart wizzkid with end-user facilities could build his/her own
application in abf in which he uses one of the database-procedures. To do
this, he should know how the procedure is called and what parameters he
should use. In a research-laboratory with over 600 employees (more than
half with an university-degree in a computer-related science) there surely
will be several of these very smart wizzkids.
What we want to do is to disable end-users from using the Ingres-tools abf,
qbf, isql, etcetera. The only way to do this - as we know so far - is to
make so-called ACL-lists under VMS (the operating system we are currently
working with) in which we specify who is allowed to run the images of the
Ingres-tools.
QUESTION 1:
Does anyone know other ways to protect the database from updating by end-
users, other than the concept I described above?
PROBLEM 2: maintainability of users-catalog
ingres-users are registered in the system-catalog iiuser of the database
iidbdb. The only proper way to maintain this catalog is the use of the
Ingres-tool accessdb. As you'll probably know this tool is user-friendly as
long as you don't have too much mutations in your user-population.
Updating the users-catalog in any direct way is officially not supported by
ASK/Ingres.
We are building an Ingres-application with which we register what employee
has what VMS- or UNIX-accounts. As eventually all 600 employees will have
to use Ingres-applications, all employees should get an account and should
be registered as an Ingres-end-user.
We would like to register and de-register an employee as Ingres-end-user
automatically when his/her VMS- or UNIX-account is mutated. But when we
want to build such an application, we should update the Ingres system-
catalogs directly.
QUESTION 2:
Does anyone know what problems can arise while updating the users-catalog
directly? And does anyone have experience with building own applications
for register/de-register Ingres-end-users automatically?
PROBLEM 3: distributed applications
When 600 people want to run the same application at almost the same moment,
the performance of running the application on one machine will degenerate
into unacceptable waiting-time.
So we should distribute the application over our network of several VMS-,
ULTRIX-, and UNIX-machines. We don't have any experience with the products
Ingres/Net and Ingres/Star yet.
Because of security, we don't want to distribute the whole Ingres-system
over all the sites; i.e. we want one machine on which the Ingres-server can
run. The self-build applications should run on several sites.
QUESTION 3:
Is it possible to distribute the self-build application over several sites
without distributing Ingres-tools like abf, isql, etcetera? Has anyone
knowledge of companies which tried such a concept before?
Thanks for your help.
ir. E.Th. van Hattum
PTT-Research
department: CFI-AUT
P.O.box 421
2260 AK Leidschendam
The Netherlands
EMAIL: ET_vHattum@pttrnl.nl