db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Grant -revoke (464) and future backwards compat
Date Mon, 20 Feb 2006 22:33:10 GMT
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.




Mime
View raw message