From: | darcy(at)druid(dot)net (D'Arcy J(dot)M(dot) Cain) |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Priviliges on tables and views |
Date: | 1998-01-13 15:44:32 |
Message-ID: | m0xs8W0-00000XC@druid.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Since PostgreSQL doesn't have column level permissions, I tried to do
something with views like this.
CREATE TABLE account (
uid int, # Unique UID for account
login char8, # User login - must also be unique
cdate date, # Creation date
a_active bool, # true or false
gedit bool, # edit privs for group
bid int, # reference to billing group table
password text, # Encrypted password
gcos text, # Public information
home text, # home directory
shell char8); # which shell
CREATE UNIQUE INDEX account_uid ON account (uid);
CREATE UNIQUE INDEX account_login ON account (login char8_ops);
REVOKE ALL ON account FROM PUBLIC;
CREATE VIEW passwd AS SELECT uid, login, bid, gcos, home, shell
FROM account WHERE a_active = 't';
REVOKE ALL ON passwd FROM PUBLIC;
GRANT SELECT ON passwd TO PUBLIC;
Unfortunately this doesn't work. The VIEW inherits the permissions
from the table it is a view of. It seems to me that allowing a view
to define permissions separately from its parent would be a useful
thing. So, does anyone know if this behaviour is allowed by the
SQL spec and if it is allowed, would this be difficult to do?
--
D'Arcy J.M. Cain <darcy(at){druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
From | Date | Subject | |
---|---|---|---|
Next Message | De Clarke | 1998-01-13 18:55:48 | Re: [HACKERS] access control |
Previous Message | Thomas G. Lockhart | 1998-01-13 15:24:30 | Re: [HACKERS] Re: subselects |