permissions
------------- Begin Forwarded Message -------------
Message-Version: 2
From: cbnewsk!att!rmy.emory.edu!informix-list-owner
Date: Tue Oct 15 gmt-0:00 EDT 91
Received: by att.att.com; Tue Oct 15 17:45:50 EDT 1991
Received: from csslc.rmy.emory.edu by
Received: rmy.rmy.emory.edu (5.65/Emory_rmy.3.2.6) via SMTP
Received: id AA24149 ; Tue, 15 Oct 91 17:45:33 -0400
Received: from Gateway.DHL.COM by
Received: rmy.rmy.emory.edu (5.65/Emory_rmy.3.2.6) via SMTP
Received: id AA18860 ; Tue, 15 Oct 91 15:41:57 -0400
Received: from moses by gateway.DHL.COM id aa00724; 15 Oct 91 12:39 PDT
Received: by moses.lhr-sys.ssf-sys.DHL.COM
Received: (5.61/1.8) id AA01009; Tue, 15 Oct 91 20:40:02 +0100
End-of-Header:
Email-Version: 2
Return-Path: informix-list-owner@rmy.emory.edu
Subject: Permissions on views
To: cbnewsk!att!rmy.emory.edu!informix-list@rmy.emory.edu
X-Mailer: ELM [version 2.2 PL15]
Message-Id: <9110151239.aa00724@gateway.DHL.COM>
X-Informix-List-Id: <list.512>
End-of-Protocol:
Content-Type: text
Content-Length: 1883
Nigel Brickenden <brick@bcr.bellcore.com> writes (quoting me)
> >A couple of guys suggested using views for protection. This is
> >okay provided that there's no means of going straight to the
> >base table (i.e., the user can't call isql, etc), but the
> >protection on the base table has to be similar to that on
> >the view. In other words, if the guy can select off the view,
> >he can select off the base table and probably get more info.
>
> This is incorrect. You can have select permission on a view without having
> select permission on the base table(s) that the view is constructed on.
I thought that they were meant to work like paragraph 2, but ...
Run the following script as informix, but substituting your login
(!= informix) for mine.
----8<-------8<-------8<-------8<-------8<-------8<-------8<-------8<---
:
isql - <<-HERE
create database foo;
grant connect to public;
create table blug
(
col1 char(20),
col2 char(20)
);
insert into blug values ("hello", "bye");
insert into blug values ("hello", "theskett");
insert into blug values ("hello", "informix");
** revoke connect from public ***
grant connect to userid
revoke all on blug from public;{ grant select on blug to public; }
create view myview as select * from blug where col2 = user;
grant select on myview to public;
HERE
----8<-------8<-------8<-------8<-------8<-------8<-------8<-------8<---
Now log in as yourself, run isql and do "select * from blug".
Isql comes back with "272: No select permission"
Drop the database, uncomment the grant statement and comment out
the revoke. Run the script again. This time you get one
row returned.
Your thoughts ?
--
Cheers - Tony.
Typical oversight - you are allowing database access and you think that table
permissions are going to save you. restrict database connect priviledes from
public and allow only authorize users. Use table level for restricting access
once they are in.
I am working on a database here at AT&T, and I needed access to another
database. It said I wasn't an authorized user do to a shell script at the
front end, but I looked at sysusers.dat with a binary scanner, ok it was
octal, and noticed that public had connect. I made a default form from the
sysusers table and authorized myself.
Close off the database level, or anyone can enter and scan all the records.
Thanks,
------------------------
James F. Van Valkenburg a.k.a. "van"
AT&T Attmail: !jfv jfv@cbnewsk.att.com
Atlanta, GA. Voice 404-810-7920
===============================================================================
---- Standard Disclaimers included -- Just another grunt at AT&T ----
===============================================================================