Path: utzoo!attcan!uunet!tiamat!jim
From: jim@tiamat.fsc.com (Jim O'Connor)
Newsgroups: comp.databases
Subject: Re: Restricting access to Informix tables
Summary: not what he wanted
Message-ID: <573@tiamat.fsc.com>
Date: 16 May 89 15:00:40 GMT
References: <1080@investor.UUCP> <1092@altos86.UUCP>
Organization: Filtration Sciences - Chattanooga,TN
Lines: 32

In article <1092@altos86.UUCP>, jon@altos86.UUCP (Jonathan Ma) writes:
> In article <1080@investor.UUCP> news@investor.UUCP ( Bob Peirce) writes:
> >We have a database we want to keep most people from updating or
> >inserting except under controlled circumstances; ie, No from sperform,
> >but YES from a 4GL data entry program.  
> 	You can do the following as root:
> 	% cd $INFORMIXDIR/bin
> 	% chmod 500 sperform

This will only keep the users from being able to USE sperform.  This is not
what the original question asked.  We have run into the same problem, and have
come up with a workable solution by using lots of "noadd" and "noupdate"
attributes in the Perform source for the screens the users will use.

There is still another problem, though.  Users who know how, can still run
"isql" and enter random SQL statements to modify the data in the tables.
You can't keep them from running "isql" since "sperform" is just a shell
script that runs "isql".  I supposed you could make "isql" owned by root and
use a setuid root C program as a replacement for sperform, so users would
only be able to use "isql" when called through "sperform".  This would
make all of the users "root", though, and is probably even worse (considering
that sperform has a shell escape) than the original problem.

Since INformix SQL is a front end - back end product, it would be nice if
there was a way for the back end (the SQL engine) to know which front end
(the sperform, isql, or 4GL application) was running and control access to the
tables according to this data, as well as by user or group ids.
------------- 
James B. O'Connor			jim@tiamat.fsc.com
Filtration Sciences Corporation		615/821-4022 x. 651

*** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***