db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4505) Document that views, triggers, and constraints run with definer's rights rather than invoker's rights
Date Fri, 08 Jan 2010 18:18:54 GMT

    [ 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
>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:,,,,,,,,
>            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.

View raw message