From: | "Vadim B(dot) Mikheev" <vadim(at)sable(dot)krasnoyarsk(dot)su> |
---|---|
To: | "D'Arcy J(dot)M(dot) Cain" <darcy(at)druid(dot)net> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Priviliges on tables and views |
Date: | 1998-01-14 03:19:50 |
Message-ID: | 34BC2ED6.CCD4604E@sable.krasnoyarsk.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
D'Arcy J.M. Cain wrote:
>
> 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?
This is allowed by SQL and this is very useful thing. Not easy to implement:
views are handled by RULES - after parsing and before planning, - but
permissions are checked by executor (execMain.c:InitPlan()->ExecCheckPerms()).
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 1998-01-14 03:49:13 | Re: [HACKERS] Priviliges on tables and views |
Previous Message | Bruce Momjian | 1998-01-14 03:18:23 | Re: [HACKERS] grant still broken |