Re: Need help to find missing records in INFORMIX tables

->From: spitz@GAN03X (Richard Spitz) ->Subject: Re: Need help to find missing records in INFORMIX tables ->Date: Fri, 4 Jun 1993 08:27:18 GMT ->Reply-To: spitz@ana.med.uni-muenchen.de ->Organization: Institut fuer Anaesthesiologie der Universitaet Muenchen -> ->Thanks to all who suggested that I ->"GRANT SELECT ON table TO [PUBLIC|user]" to overcome the PERFORM ->problem with rows not being displayed. -> ->I know that this is a workaround, but I am reluctant to grant access to ->public, I consider this a security leak, and it is quite tedious to ->enter the grant statement for each DBA user for each and every table. ->I tried to write a short 4GL program using variables for table names, ->but that didn't work, you can't use variables for table names! -> ->I'd prefer that PERFORM worked according to the manuals and accept ->DBA privileges. Is the current performance a bug or a feature? -> ->Regards, Richard ->+----------------------------+-------------------------------------------+ ->| Dr. Richard Spitz | INTERNET: spitz@ana.med.uni-muenchen.de | ->| EDV-Gruppe Anaesthesie | Tel : +49-89-7095-3421 | ->| Klinikum Grosshadern | FAX : +49-89-7095-8886 | ->| Munich, Germany | | ->+----------------------------+-------------------------------------------+ -> Guten morgen, Richard. You have raised some interesting points. First is the distinction between database security and data security. I did not consider granting SELECT to PUBLIC to be a security issue, since I was only thinking of database security at the time. Obviously, in a hospital setting such as yours, data security / privacy is a major issue, and grants to PUBLIC may not be appropriate. Second, I have also found that I4GL does not like to run certain statements with variables in them. My normal solution is to PREPARE such statements from character variables built from strings, variables, etc., and then EXECUTE them. It is a little more tedious, but it works. Third, is the PERFORM behavior a bug or a feature? I guess that comes down to a question of philosophy. Obviously, folks with DBA privileges must be able to get to anything when using bare bones tools like DBACCESS or the Query-language menu in ISQL. However, it is a reasonable point of view to state that in "second level" or higher tools, such as PERFORM, ACE, or 4GL, a DBA user is just a user and therefore has only those privileges that have been GRANTed. This second approach makes it easier for a DBA user to test software without having to maintain two logins, one with DBA access and one without. I have seen too many situations in which the following happens: A script is installed for general use after a systems / DBA person has tested it. As soon as the script is used by an ordinary user, it fails because some part of it depends on the user having some special privilege; i.e., a privilege that the system / DBA person is used to having and which s/he forgets is not available to ordinary users. You state that ACE and PERFORM behave differently in this respect. Appar- ently Informix does not have a consistent philosophy on this topic. Either the two development groups have different philosophies, or no philosophy at all, and it just happened to work that way based on how they programmed the privilege checking. Regards, Alan ___________________________ ______________________| R. Alan Popiel |__________________________ \\ Internet: | Martin Marietta, Tech Ops | / \\ alan@den.mmc.com | P.O. Box 179, M/S 5422 | Std disclaimers apply. / )Voice: | Denver, CO 80201-0179 USA | ( / 303-977-9998 |___________________________| (But you knew that!) \\ /________________________) (____________________________\\