Daniel John Debrunner wrote:
> Maybe the more general question is: "How do we want permissions to
> behave once all the related work is done, and does that model have any
> discontinuities with the model currently proposed for 10.2?"
This is, as David said, the question that needs to be answered.
This is what I believe is proposed for 10.2
(excluding the owner of the database who can do anything)
CREATE FUNCTION
- allowed within schemas owned by the user
- probably not compatible with future requirement,
would like to restrict access on creating
external functions.
CREATE INDEX
- allowed only by owner of table
- good for now, forwards compatible with the
future where permission to create an index on
a table could be granted explicitly.
CREATE PROCEDURE
- allowed within schemas owned by the user
- probably not compatible with future requirement,
would like to restrict access on creating
external procedures.
CREATE SCHEMA
- only create schema matching user's name
- good for now, forwards compatible with the
future where permission to create any schema
could be granted explicitly.
CREATE SYNONYM
- allowed within schemas owned by the user
- Good, just creates an alias for a table.
No security risk to allowing SYNONYMs, since
user of SYNONYM would require privileges to
underlying table.
CREATE TABLE
- allowed within schemas owned by the user
- probably not compatible with future requirement,
would like to restrict access on creating tables.
CREATE TRIGGER
- allowed within schemas owned by the user
- require TRIGGER privilege on table
- Good, probably completely matches future requirements.
CREATE VIEW
- allowed within schemas owned by the user
- requires access on objects referenced in view
I guess this is ok, seems a little like grant with grant though, if
I have permission to read X, then I can grant that to everyone through a
view. But I guess if I have access to read X, I can distribute it to
others in many ways.
ALTER TABLE
- not sure what is proposed here. Patial mention in specs
for constraints.
- best forward compatibile approach would be to only
allow ALTER to be executed by the table's owner.
Any other DDL?
Thus it seems, to me, that ideally 10.2 should go out with some
restriction on how routines and tables are created.
Dan.
