[
https://issues.apache.org/jira/browse/DERBY-4505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12798113#action_12798113
]
Rick Hillegas commented on DERBY-4505:
--------------------------------------
Hi Kim. Here's what I think:
>The topic on the REVOKE statement says,
>
>"You can revoke privileges for an object if you are the owner of the object or
>the database owner."
>
>Would the statement that "Views, triggers, and constraints operate with the
>permissions of the owner of the view, trigger, or constraint" add anything to
>this statement, or would it be redundant? Perhaps these things are not
>actually objects?
I don't think that the additional sentence would add information. The existing
sentence seems accurate and concise to me.
>I'm also wondering if there is a difference between "privileges" and
>"permissions". Currently, the topic "Using SQL standard authorization" talks
>about privileges in its first sections but then switches to the term
>"permissions" for the subsection on views, triggers, and constraints. Is there
>a real distinction here or should we say "privileges" throughout? Or does
>"privileges" apply to objects and "permissions" to these other things?
The terms "privileges" and "permissions" are synonyms. I can see that switching
back and forth between the two terms confuses readers.
>The GRANT statement topic currently says, "You can grant privileges to
>database objects that you are authorized to grant." This seems a bit circular
>(as well as ungrammatical). Would it make sense to use the same language as
>for REVOKE, that is, "You can grant privileges on an object if you are the
>owner of the object or the database owner"?
I agree that the current statement sounds pretty goofy. I think that your
proposed re-wording is clear, accurate, and better. We may need to revisit this
topic if we ever implement the 'WITH GRANT OPTION" clause, but I wouldn't worry
about that possibility right now. Thanks.
> Document that views, triggers, and constraints run with definer's rights
> rather than invoker's rights
> -----------------------------------------------------------------------------------------------------
>
> Key: DERBY-4505
> URL: https://issues.apache.org/jira/browse/DERBY-4505
> Project: Derby
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 10.2.2.1, 10.2.3.0, 10.3.3.1, 10.3.4.0, 10.4.2.1,
> 10.4.3.0, 10.5.3.1, 10.5.4.0, 10.6.0.0
> Reporter: Rick Hillegas
> Assignee: Kim Haase
>
> Comments like the following can be found in the code, including this
> particular example from
> DDLConstantAction.storeConstraintDependenciesOnPrivileges():
> * Views and triggers and constraints run with definer's privileges.
> This is an important behavior of Derby privileges which deserves to be
> documented. I can find only one glancing reference to this behavior, viz., in
> the Reference Guide section on the REVOKE command. There we learn that:
> "You must use the RESTRICT clause on REVOKE statements for routines. The
> RESTRICT clause specifies that the EXECUTE privilege cannot be revoked if the
> specified routine is used in a view, trigger, or constraint, and the
> privilege is being revoked from the owner of the view, trigger, or
> constraint."
> From that lone statement, a clever reader might deduce that Derby views,
> triggers, and constraints run with definer rather than invoker rights. But
> that is not the clear meaning of that statement in the Reference Guide. To
> draw the necessary conclusion from that statement the reader would have to be
> clever enough to understand the SQL Standard's tricky language around definer
> and invoker rights--and that would be a very clever reader indeed.
> In short, we need to document this behavior explicitly. I consider this hole
> in our documentation to be a serious enough defect that I am marking this
> issue as a Bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
